Node.js記憶體洩漏實用指南 – Arbaz Siddiqui

記憶體管理
記憶體管理是一種將記憶體從計算機記憶體分配給應用程式，然後在不再使用時將其釋放回計算機的方法。記憶體管理有多種方式，這取決於您使用的程式語言。以下是幾種記憶體管理方式：

• 手動記憶體管理：在這種記憶體管理模式中，程式設計師負責分配和釋放記憶體。預設情況下，該語言不會為您提供任何自動化工具。雖然它為您提供了極大的靈活性，但也增加了開銷。C並C++使用這種方法來管理記憶體，並提供類似方法malloc並free與機器記憶體協調。
• 垃圾收集：垃圾收集的語言為您提供了開箱即用的記憶體管理功能。程式設計師不必擔心釋放記憶體，因為內建的垃圾收集器將為您完成此任務。對於開發人員來說，它的工作方式以及何時觸發釋放未使用的記憶體將是一個黑匣子。像大多數現代程式語言Javascript，JVM based languages (Java, Scala, Kotlin)，Golang，Python，Ruby等都是垃圾回收的語言。
• 所有權：在這種記憶體管理方法中，每個變數必須具有其所有者，並且一旦所有者超出範圍，該變數中的值就會被丟棄，從而釋放記憶體。Rust使用這種記憶體管理方法。

Javascript中的垃圾收集
如上一節所述，javascript是一種垃圾收集語言，因此，名為Garbage Collector的引擎會定期執行，並檢查您的應用程式程式碼仍可以訪問分配的記憶體，即哪些變數您仍然具有引用。如果發現應用程式未引用某些記憶體，它將釋放它。上述方法有兩種主要演算法。首先 是：JS的標記和清除演算法Mark and Sweep；另外一種是Python和PHP使用的Reference counting。

標記和清除演算法首先建立一個根列表，這些根是環境中的全域性變數（window瀏覽器中的物件），然後從根到葉節點遍歷樹並標記它遇到的所有物件。堆中未被標記物件佔用的所有記憶體都標記為空閒。

Node應用中的記憶體洩漏
現在，我們對記憶體洩漏和垃圾回收有了足夠的瞭解，可以深入到實際應用中。在本節中，我們將編寫一個有洩漏的node伺服器，嘗試使用其他工具識別該洩漏，然後最終對其進行修復。
為了演示起見，我構建了一個其中包含洩漏路由的Express伺服器。我們將使用此API伺服器進行除錯。

const express = require('express')

const app = express();
const port = 3000;

const leaks = [];

app.get('/bloatMyServer', (req, res) => {
    const redundantObj = {
        memory: "leaked",
        joke: "meta"
    };

    [...Array(10000)].map(i => leaks.push(redundantObj));

    res.status(200).send({size: leaks.length})
});

app.listen(port, () => console.log(`Example app listening on port ${port}!`));

堆轉儲
要了解什麼是堆轉儲，我們首先需要了解什麼是堆。用最簡單的術語來說，堆是所有東西扔到那裡的地方，它一直呆在那裡，直到GC刪除了應該是垃圾的東西。堆轉儲是您當前堆的快照。它將包含堆中當前存在的所有內部和使用者定義的變數及分配。
因此，如果我們能夠以某種方式比較新伺服器的堆轉儲與執行時間較長的ated腫伺服器的堆轉儲，那麼我們應該能夠透過檢視差異來識別未被GC拾取的物件。
但是首先讓我們看一下如何進行堆轉儲。我們將使用一個npm庫heapdump，它允許我們以程式設計方式獲取伺服器的heapdump。要安裝，請執行以下操作：

npm i heapdump

const express = require('express');
const heapdump = require("heapdump");

const app = express();
const port = 3000;

const leaks = [];

app.get('/bloatMyServer', (req, res) => {
    const redundantObj = {
        memory: "leaked",
        joke: "meta"
    };

    [...Array(10000)].map(i => leaks.push(redundantObj));

    res.status(200).send({size: leaks.length})
});

app.get('/heapdump', (req, res) => {
    heapdump.writeSnapshot(`heapDump-${Date.now()}.heapsnapshot`, (err, filename) => {
        console.log("Heap dump of a bloated server written to", filename);

        res.status(200).send({msg: "successfully took a heap dump"})
    });
});

app.listen(port, () => {
    heapdump.writeSnapshot(`heapDumpAtServerStart.heapsnapshot`, (err, filename) => {
        console.log("Heap dump of a fresh server written to", filename);
    });
});

如果您在kube叢集中執行應用程式，則將無法使用所需的高消耗Pod。為此，您可以使用埠轉發來命中群集中的該特定容器。另外，由於您將無法訪問檔案系統來下載這些大型轉儲，因此您可以將這些大型轉儲上傳到雲（s3）。

識別洩漏
因此，現在我們的伺服器已部署並且已經執行了好幾天。它受到許多請求的攻擊（在我們的例子中只有一個），並且我們注意到伺服器的記憶體消耗已經激增（可以使用Express Status Monitor，Clinic，Prometheus等監視工具來實現）。現在，我們將進行API呼叫以進行堆轉儲。該堆轉儲將包含GC無法收集的所有物件。

curl --location --request GET 'http://localhost:3000/heapdump'

載入完兩個快照後，將perspective改為Comparison，然後單擊長時間執行的伺服器的快照

我們可以透過Constructor 瀏覽GC未掃描的所有物件。它們中的大多數將是NodeJS使用的內部引用，一個巧妙的技巧是透過Alloc. Size對它們進行排序，以檢查我們擁有的最繁重的記憶體分配。如果我們進行擴充套件array，然後進行擴充套件，(object elements)我們將能夠看到leaks其中包含瘋狂數量的物件的陣列，而該陣列沒有被GC拾取。

現在，我們可以將指向leaks陣列的原因歸結為高記憶體消耗的原因。

解決洩漏
現在我們知道陣列leaks會引起麻煩，我們可以檢視程式碼並很容易地對其進行除錯，因為陣列不在請求週期的範圍內，因此永遠不會刪除其引用。我們可以透過以下操作輕鬆修復它：

app.get('/bloatMyServer', (req, res) => {
    const redundantObj = {
        memory: "leaked",
        joke: "meta"
    };
const leaks = [];

    [...Array(10000)].map(i => leaks.push(redundantObj));

    res.status(200).send({size: leaks.length})
});

結論
記憶體洩漏勢必會在垃圾收集語言（如javascript）中發生。修復記憶體洩漏很容易，儘管識別它們確實是很痛苦的。在本文中，我們瞭解了記憶體管理的基礎知識以及如何透過各種語言完成記憶體管理。我們模擬了一個真實的場景，並嘗試除錯其記憶體洩漏並最終對其進行了修復。