最近又用node寫了一個小工具，需要常駐進程，經過幾天的觀察，發現內存占用有持續增加的趨勢(雖然不明顯，但還是讓我察覺到了，我真屌)。突然發現，我竟然不知道怎么排查nodejs的內存泄漏，嚇死寶寶了!

花時間看了一下相關資料(google真好，外果仁真屌)，看來這部分也已經有比較完善的方法論+工具了。所以這篇文章記錄一下自己從不懂到入門的經歷~~

我希望這篇文章不僅能提供具體的工具供大家使用，還提供足夠的理論知識來輔助大家思考，當然，也可能是我自己想多了~~哇哈

發現問題

由于沒有太多運維經驗，也不知道啥逆天的工具來幫我一鍵式監控所需要的指標，如果你和我情況一樣，那我們只能手動來造個簡陋的但夠用的監控腳本了。

別告訴我你和我一樣shell也不熟，直接就node吧。少廢話~

先裝上pm2，然后寫一個腳本，來定時打印目標應用的內存使用率，當然，前提是目標應用也都放在pm2中管理。

const exec = require('child_process').exec;  
var Later = require('later');  
var schedule = Later.parse.text('every 5 mins'); // 每5分鐘正點觸發  
Later.setInterval(function(){  
exec('pm2 jlist', { // 打印出pm2中應用的基本狀態信息，輸出是json字符串  
timeout: 2000  
}, (err, data, stderr)=>{  
if (err) {  
console.error(err, err.stack); // an error occurred  
return;  
}  
//將結果寫入日志  
data = JSON.parse(data);  
if(data[0]){ // 這里取0是因為我希望監控的應用在pm2中的順序是第一位  
console.log(data[0].monit.memory/(1024*1024)); // 直接輸出到pm2的log中  
}  
});  
}, schedule); 

然后就等一段時間，就會在對應的log文件中拿到相關的內存數據，然后只需要用電子表格生成一個圖標即可，我推薦使用google drive的spreadsheet：

上面的圖是我收集了大概2天的內存數據繪制成的圖標，可以看出內存使用量成上升趨勢。沒錯，就是泄漏了!!

友情提醒：修復內存泄漏可能會耗時很久，你最好先找一個臨時方案來維持生計，例如定期重啟程序。

搭建環境

本著實戰為主的策略，我們先從搭建內存泄漏監控環境開始。剛開始參考 node-memory-leak-tutorial ，以為會很順利搭建好的，不過碰到了 這個error 。看Issus應該是個很常見的錯誤，按照別人的解決方案，嘗試 切換成 nodejs 6.3.1 版本 進行了測試，確實可以繞過那個錯誤：

// 在項目目錄下  
node-debug leak.js 

然后終端會啟動你的chrome，并停在代碼的斷點位置，深吸一口氣你就可以點擊執行了。

備注：若遇到無法創建快照問題，需要多刷新幾次喲~

其它工具我也順便試了一下：

• node-memwatch
• node-webkit-agent
• node-heapdump

因為它們都需要根據操作系統進行編譯，我的本地環境是 win7 64bit ，這并不是一個理想的nodejs環境，至少我這么認為，否則也不會碰到惡心的“.net framework”問題。我勸大家千萬別學我輕易的就刪除了 .net framework 3.5 這個安裝包，因為這是win7自帶的，刪了以后就裝不上了，而裝更新的4.0+版本的話我這邊很重要的一個軟件就無法運行了(翻墻你懂的)。 在Windows 7系統上安裝.NET Framework 3.5框架 很不容易的!建議可以用上docker來搭建一個專門用來分析用的容器，這里我就不折騰下去了，its your turn~~

nodejs內存分析的理論姿勢

在開始聽我正兒八經胡說八道之前，推薦你先看幾個文檔：

• Memory Terminology
• How to Record Heap Snapshots
• Debugging Memory Leaks in Node.js Applications
• Simple Guide to Finding a JavaScript Memory Leak in Node.js
• Understanding Garbage Collection and hunting Memory Leaks in Node.js
• writing fast memory efficient javascript
• Error Handling in Node.js

一次性看完這些，可能要花很久，如此貼心的我已經幫你看過了，根據我的理解，總結如下：

• javascript的v8內存管理和java jvm類似，都有新生代(To-Space and From-Space)，老年代等;
• 排查內存泄漏需要分析內存快照，可以使用已有的工具以devtool的profile面板或代碼的方式創建snapshot;
• 創建的快照文件可以導入devtool的profile進行分析;
• 快照生成的最佳實踐是：先保證程序已經預熱，然后進行快照1(先觸發GC)，然后對程序進行一些交互(例如：對于web服務即http請求)，再次創建快照2，如此循環來生成多個版本的快照;
• 合理的利用devtool的profile提供的功能，正確的選擇視圖;
• 理解profie中的字段含義：
• 對象上的黃色標識表示的是javascript直接引用，紅色表示間接依賴引用，不太需要關注的是無底色對象，其代表被其它資源引用(如：natvie code);
• profile會根據對象的構造方法對對象進行分組歸類，每個組對應的“Shallow Size”表示的是該組對象的直接內存占用大小(例如：該類對象自身的原始類型數據的內存占用)，對應的“Retained Size”表示的是該組對象依賴的其它對象而造成的內存占用總數(等于自身的Shallow Size + 依賴對象的Shallow Size [ + 依賴對象的依賴對象的Shallow Size [ + 遞歸下去]]);
• 由于性能原因，profile中不會顯示對象的整型類型的屬性，但是它們并沒有丟失，僅僅是工具沒有顯示出來而已。
• 應該警惕“distance”比較大或比較小的對象，總之和其它同類型對象的distance不一樣就意味著可能有問題;
• 盡量不要用匿名函數，函數有名字會讓分析更容易，其實更推薦的是使用OOP，這樣會最容易定位需要追蹤的變量，畢竟都是構造器創建出來的嘛;
• 閉包(匿名函數，定時器等)創建的上下文引用很容易造成不易察覺的內存泄漏;
• console的相關函數(log, error等)在實際分析中發現其引用的變量無法釋放，可以參考 #1741 ，所以你可以在測試代碼中替換掉console的相關函數(這樣你就不需要改動被測代碼邏輯了);
• 對象上的事件監聽器的閉包最容易造成泄漏，即便是使用once，也可能一次都沒有觸發而導致該回調函數無限期引用數據。

ok，一大堆姿勢足夠你花很久時間閱讀了。不過并不是說你看了這些內容，就可以輕松戰勝困難了。還有一個環節我們沒有討論： 若你的項目足夠復雜(大)，那要怎么搭建項目的測試環境呢?

這里我認為，大概需要按照下面的步驟來做：

1. 將完整的項目拆解成獨立的不同塊，并為每個拆解后的小模塊寫測試代碼
2. 針對定時器相關的邏輯，最好改成手動觸發，或利用測試庫(sinonjs)模擬時間片段
3. 初期可以先盡可能排除依賴的第三方庫，最后酌情去測試它們(如果你懷疑是它們的問題的話)
4. 低級別異常偽造(例如socket，file等)要靠偽造對應方法(不推薦使用sinonjs.stubs，因為它保存每次調用時的參數數據，影響你觀察，不妨試試 mockery )
5. 最終還是有必要放在線上環境實測一段時間來觀測問題是否真的修復了

我們主要來說一下第5條，其意味著你要在線上環境以debug的形式啟動程序，并想辦法導出快照到本地來分析。下面來看看怎么做：

首先，你給線上環境中安裝 v8-profiler 庫，它用來提供創建快照的功能。

然后，看一下下面的這段樣板代碼，其意義在于在你的項目中加載 v8-profiler 庫，并提供一個對外指令用來通知它創建快照文件。

var fs = require('fs');  
var profiler = require('v8-profiler');  
// ---------------  
// 測試目標  
functionLeakingClass(){}  
var leaks = [];  
setInterval(function(){  
for(var i = 0; i < 100; i++){  
leaks.push(new LeakingClass);  
}  
console.error('Leaks: %d', leaks.length);  
}, 1000);  
// ---------------  
// 指令服務  
var koa = require('koa');  
var route = require('koa-route');  
var service = koa();  
var snapshotNum = 1; // 用于為生成的快照進行編號  
service.use(route.get('/snapshot', function*(){  
var response = this;  
var snapshot = profiler.takeSnapshot();  
snapshot.export(function(error, result){  
fs.writeFileSync((snapshotNum++) + '.heapsnapshot', result);  
snapshot.delete();  
response.body = 'done';  
});  
}));  
service.listen(2333, '127.0.0.1'); // 推薦綁定內網ip，不要允許外網訪問該服務 

每次請求 http://127.0.0.1:2333/snapshot ，你都會在項目根目錄生成一個快照文件，然后把它下載到本地磁盤就可以在chrome里隨時進行分析了。

總結

在實際排查過程中，發現最難測試的還是依賴的第三方庫的泄漏問題。畢竟你無法理解它們的實現。但不可能所有邏輯都自己來完成，所以面對各種各樣的第三方類庫，還是建議選擇盡可能權威的，主流的。剩下那些很小的功能模塊，就只能花時間研讀其實現代碼了。

如果你的業務采用了生產消費者模式， 你的測試腳本一定要保證任務的生產和消費的速率保持同速率(或者干脆確保消費者處理完一批次的任務耗時一定要大于批次創建的間隔時間) ，不然由于任務得不到處理，必然會產生任務積累，看起來就好像有內存泄漏一樣，但其實這種情況其實是合理的，只是說明你的消費者太少了而已。

另外，一定要最大頻度的，盡可能長時間的運行測試代碼，才能明顯的暴露出問題，例如：

setInterval(functionmemoryleakBlock(){  
// 待測試的代碼塊  
}, 100); 

注意在上面 memoryleakBlock 中避免引用全局變量喲，這樣你運行一夜，第二天上班來看結果(如果它還跑著的話)。