作者 | 后端Team朱捷峰

整理 | 包包

V8 垃圾回收機制

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

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

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

? 代碼區(qū)：實際正在運行的代碼

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

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

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

memory usage

{

rss: 4935680,

heapTotal: 1826816,

heapUsed: 650472,

external: 49879

}

以上數(shù)值以字節(jié)為單位

? rss：表示 Resident Set 的大小

? heapTotal：表示堆的總大小

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

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

我們知道在 Node.js 的運行時中，JavaScript 是由 V8 編譯成可執(zhí)行的機器碼。運行時的數(shù)據(jù)結(jié)構(gòu)是由 V8 來管理的，我們能做的很有限。通過 JavaScript 我們是沒法做到分配內(nèi)存和釋放內(nèi)存的。

V8 的垃圾回收算法實現(xiàn)還是很復(fù)雜的，感興趣的同學(xué)可以參考：http://newhtml.net/v8-garbage-collection/。但是我們?nèi)匀豢梢园言砗唵纬橄螅喝绻粋€內(nèi)存片段沒有被任何地方引用，我們可以假設(shè)它不再會被用到，那么該內(nèi)存片段可以被釋放。

上圖表示在內(nèi)存中各個對象的引用情況，只有當紅球?qū)ο蟛辉俦蝗魏螌ο笠玫臅r候，它才能被回收。

異常情況

既然 V8 會進行垃圾回收，那我們?yōu)槭裁催€要關(guān)心內(nèi)存情況呢？

理想情況，內(nèi)存占用會保持在一個相對穩(wěn)定的范圍：

實際上，我們?nèi)匀豢赡軙吹絻?nèi)存占用升高的情況：

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

制造內(nèi)存泄漏

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

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

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 在每次調(diào)用 replaceThing() 時會被重寫。問題就在于，someMethod 有閉包作用域作為上下文，這就意味著當調(diào)用 someMethod 時，unused 是可見的。雖然實際上 unused 并沒有被調(diào)用，但是它卻阻止了 V8 垃圾回收機制對 originalThing 進行回收。這就是我們平時所說的“循環(huán)引用”：

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

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

排查問題

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

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

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

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

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

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

第三步，重復(fù)上述過程，檢查內(nèi)存泄漏問題是否解決。

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