作者 | 后端Team朱捷峰

整理 | 包包

V8 垃圾回收機制

事實上，我們平時在寫 Node.js 的時候很少去關心內存問題，那是因為 Node.js 對 Google V8 進行封裝，底層的垃圾收回機制都交給 V8 處理。大部分時候，是不會有內存問題的。相對于 C/C++ 這類需要自己管理內存的語言，Node.js 有更加平滑的學習曲線，這也是 Node.js 最大的優勢之一。但是也總有意外情況，可能導致 Node.js 進程內存泄漏。

那么如何避免我們的 Node.js 程序出現內存泄漏的情況呢？我們先來了解下 V8 內存管理機制。

一個進程通常是通過在內存中分配空間來體現的，這個空間我們稱之為 Resident Set（常駐空間）。V8 將內存分為了以下幾塊：

? 代碼區：實際正在運行的代碼

? 棧區：包含了所有的值類型（數字、布爾值等）、指向存儲在堆區的對象指針、定義程序控制流的指針

? 堆區：專門用來存儲引用類型的內存區域，比如對象、字符串和閉包

在 Node.js 中，我們可以通過調用process.memoryUsage() 方法來來查詢內存使用情況。該函數返回值如下：

memory usage

{

rss: 4935680,

heapTotal: 1826816,

heapUsed: 650472,

external: 49879

}

以上數值以字節為單位

? rss：表示 Resident Set 的大小

? heapTotal：表示堆的總大小

? heapUsed：表示堆的實際使用大小

? external：表示 V8 管理的綁定到 JavaScript 對象的 C++ 對象的大小

我們知道在 Node.js 的運行時中，JavaScript 是由 V8 編譯成可執行的機器碼。運行時的數據結構是由 V8 來管理的，我們能做的很有限。通過 JavaScript 我們是沒法做到分配內存和釋放內存的。

V8 的垃圾回收算法實現還是很復雜的，感興趣的同學可以參考：http://newhtml.net/v8-garbage-collection/。但是我們仍然可以把原理簡單抽象：如果一個內存片段沒有被任何地方引用，我們可以假設它不再會被用到，那么該內存片段可以被釋放。

上圖表示在內存中各個對象的引用情況，只有當紅球對象不再被任何對象引用的時候，它才能被回收。

異常情況

既然 V8 會進行垃圾回收，那我們為什么還要關心內存情況呢？

理想情況，內存占用會保持在一個相對穩定的范圍：

實際上，我們仍然可能會看到內存占用升高的情況：

V8 垃圾回收機制盡可能地回收和釋放內存，但是每次執行垃圾回收以后，內存占用仍然持續上升，這明顯就是內存泄漏了。

制造內存泄漏

有一些很明顯的情況會導致內存泄漏：1、比如將每位訪客的 IP 記錄在 global 上存儲數組上；2、再比如著名的“ 沃爾瑪內存泄漏事件”，它是由 Node.js 核心代碼中一個遺漏的聲明引發的血案，工程師們花了好幾個星期去排查并最終得以解決。

在這篇文章里，我們就不一一列舉所有可能產生問題的錯誤情況。我們來看一下一個難以排查的情況，代碼很簡單，你可以自己運行調試：

memory leak demo

const express = require('express');

const app = express();

const port = 3000;

let theThing = null;

const replaceThing = function () {

let originalThing = theThing;

let unused = function () {

if (originalThing)

console.log("hi");

};

theThing = {

longStr: new Array(1000000).join('*'),

someMethod: function () {

console.log(someMessage);

}

};

};

app.get('/leak', (req, res) => {

replaceThing();

let memoryInfo = JSON.stringify(process.memoryUsage());

console.log(memoryInfo);

res.send(memoryInfo);

})

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

初看的話，這段代碼沒啥問題。我們可以想象 theThing 在每次調用 replaceThing() 時會被重寫。問題就在于，someMethod 有閉包作用域作為上下文，這就意味著當調用 someMethod 時，unused 是可見的。雖然實際上 unused 并沒有被調用，但是它卻阻止了 V8 垃圾回收機制對 originalThing 進行回收。這就是我們平時所說的“循環引用”：

既然找到問題所在，那么如何解決呢？答案很簡單，我們只要切斷循環引用就可以了，這里我們只需要在 replaceThing 這個方法最后加入 theThing = null。

針對這個問題，我們還可以通過 ESLint 的 no-unused-vars 規則來避免定義了但是未使用的變量，這樣可以減少循環引用的可能性。

排查問題

理解了垃圾回收的原理，那么我們平常在碼代碼的時候也要注意避免循環引用的情況出現。但是就像上面這種情況，有時候就是防不勝防。那么遇到問題的時候，我們應該如何排查呢？

推薦一下我寫的一個小工具 heapsnapshot.js ，可以獲取生成堆的快照信息，如下圖：

然后利用 Chrome 開發者工具，Memory 來做具體分析：

請選擇相鄰的3個堆快照文件，導入 Memory 分析工具中，如下圖：

第一步，先選擇 Profiles 中的第二個文件，然后篩選 Objects 選項選擇“Objects allocated between 1539255057342 and 1539255076968 ”，然后在 Constructor 中進行具體的分析 。

第二步，同理對第二個和第三個文件進行對比分析。找到兩次分析都出現過的元素，重點排查，定位到具體的問題代碼，再做修改。

第三步，重復上述過程，檢查內存泄漏問題是否解決。

以上只是對 Node.js 內存問題的一個初步探討，感興趣的話推薦大家去看下 V8 垃圾回收的原理。平常我們在編碼的時候也要注意盡量避免產生循環引用，但是如果遇到了也不要擔心，可以通過上面的步驟排查解決。