深入理解Node.js垃圾回收與內存管理

使用JavaScript進行前端開發時幾乎完全不需要關心內存管理問題，對於前端編程來說，V8限制的內存幾乎不會出現用完的情況，但是由於後端程序往往進行的操作更加複雜，並且長期運行在服務器不重啓，如果不關注內存管理，導致內存泄漏，就算1TB，也會很快用盡。
Node.js構建於V8引擎之上，因此本文首先講解V8引擎的內存管理機制，瞭解底層原理後，再講解Node開發中的內存管理與優化。

一、V8的內存管理機制

1.1 內存管理模型

Node程序運行中，此進程佔用的所有內存稱爲常駐內存（Resident Set）。

• 常駐內存由以下部分組成：
  1. 代碼區（Code Segment）：存放即將執行的代碼片段
  2. 棧（Stack）：存放局部變量
  3. 堆（Heap）：存放對象、閉包上下文

  4. 堆外內存：不通過V8分配，也不受V8管理。Buffer對象的數據就存放於此。

     
     
     V8內存模型

除堆外內存，其餘部分均由V8管理。

• 棧（Stack）的分配與回收非常直接，當程序離開某作用域後，其棧指針下移（回退），整個作用域的局部變量都會出棧，內存收回。
• 最複雜的部分是堆（Heap）的管理，V8使用垃圾回收機制進行堆的內存管理，也是開發中可能造成內存泄漏的部分，是程序員的關注點，也是本文的探討點。

通過process.memoryUsage()可以查看此Node進程的內存使用狀況：

內存使用狀況

rss是Resident Set Size的縮寫，爲常駐內存的總大小，heapTotal是V8爲堆分配的總大小，heapUsed是已使用的堆大小。可以看到，rss是大於heapTotal的，因爲rss包括且不限於堆。

1.2 堆內存限制

默認情況下，V8爲堆分配的內存不超過1.4G：64位系統1.4G，32位則僅分配0.7G。也就是說，如果你想使用Node程序讀一個2G的文件到內存，在默認的V8配置下，是無法實現的。不過我們可以通過Node的啓動命令更改V8爲堆設置的內存上限：

//更改老年代堆內存
--max-old-space-size=3000 // 單位爲MB
// 更改新生代堆內存
--max-new-space-size=1024 // 單位爲KB

堆的內存上限在啓動時就已經決定，無法動態更改，想要更改，唯一的方法是關閉進程，使用新的配置重新啓動。

1.3 V8的垃圾回收機制

垃圾回收機制演變至今，已經出現了數種垃圾回收算法，各有千秋，適用於不同場景，沒有一種垃圾回收算法能夠效率最優於所有場景。因此研發者們按照存活時間長短，將對象分類，爲每一類特定的對象，制定其最適合的垃圾回收算法，以提高垃圾回收總效率。

• 1.3.1 V8的內存分代

  • V8將堆中的對象分爲兩類：
    1. 新生代：年輕的新對象，未經歷垃圾回收或僅經歷過一次
    2. 老年代：存活時間長的老對象，經歷過一次或更多次垃圾回收的對象
  
  默認情況下，V8爲老年代分配的空間，大概是新生代的40多倍。
  新對象都會被分配到新生代中，當新生代空間不足以分配新對象時，將觸發新生代的垃圾回收。

• 1.3.2 新生代的垃圾回收
  新生代中的對象主要通過Scavenge算法進行垃圾回收，這是一種採用複製的方式實現內存回收的算法。
  Scavenge算法將新生代的總空間一分爲二，只使用其中一個，另一個處於閒置，等待垃圾回收時使用。使用中的那塊空間稱爲From，閒置的空間稱爲To。
  

  From與To各佔一半
  
  當新生代觸發垃圾回收時，V8將From空間中所有應該存活下來的對象依次複製到To空間。
  • 有兩種情況不會將對象複製到To空間，而是晉升至老年代：
    1. 對象此前已經經歷過一次新生代垃圾回收，這次依舊應該存活，則晉升至老年代。
    2. To空間已經使用了25%，則將此對象直接晉升至老年代。
  
  From空間所有應該存活的對象都複製完成後，原本的From空間將被釋放，成爲閒置空間，原本To空間則成爲使用中空間，兩個空間進行角色翻轉。
  爲何To空間使用超過25%時，就需要直接將對象複製到老年代呢？因爲To空間完成垃圾回收後將會翻轉爲From空間，新的對象分配都在此處進行，如果沒有足夠的空閒空間，將會影響程序的新對象分配。
  因爲Scavenge只複製活着的對象，而根據統計學指導，新生代中大多數對象壽命都不長，長期存活對象少，則需要複製的對象相對來說很少，因此總體來說，新生代使用Scavenge算法的效率非常高。且由於Scavenge是依次連續複製，所以To空間永遠不會存在內存碎片。
  不過由於Scavenge會將空間對半劃分，所以此算法的空間利用率較低。

• 1.3.3 老年代的垃圾回收
  在老年代中的對象，至少都已經歷過一次甚至更多次垃圾回收，相對於新生代中的對象，它們有更大的概率繼續存活，只有相對少數的對象面臨死亡，且由於老年代的堆內存是新生代的幾十倍，其中生活着大量對象，因此如果使用Scavenge算法回收老年代，將會面臨大量的存活對象需要複製的情況，將老年代空間對半劃分，也會浪費相當大的空間，效率低下。因此老年代垃圾回收主要採用標記清除(Mark-Sweep)和標記整理(Mark-Compact)。
  這兩種方式並非互相替代關係，而是配合關係，在不同情況下，選擇不同方式，交替配合以提高回收效率。
  新生代中死亡對象佔多數，因此採用Scavenge算法只處理存活對象，提高效率。老年代中存活對象佔多數，於是採用標記清除算法只處理死亡對象，提高效率。
  當老年代的垃圾回收被觸發時，V8會將需要存活對象打上標記，然後將沒有標記的對象，也就是需要死亡的對象，全部擦除，一次標記清除式回收就完成了：
  

  灰色爲存活對象，白色爲清除後的閒置空間
  
  一切看起來都完美了，可是隨着程序的繼續運行，卻會出現一個問題：被清除的對象遍佈各個內存地址，空間有大有小，其閒置空間不連續，產生了很多內存碎片。當需要將一個足夠大的對象晉升至老年代時，無法找到一個足夠大的連續空間安置這個對象。
  爲了解決這種空間碎片的問題，就出現了標記整理算法。它是在標記清除的基礎上演變而來，當清理了死亡對象後，它會將所有存活對象往一端移動，使其內存空間緊挨，另一端就成爲了連續內存：
  
  
  雖然標記整理算法可以避免空間碎片，但是卻需要依次移動對象，效率比標記清除算法更低，因此大多數情況下V8會使用標記清理算法，當空間碎片不足以安放新晉升對象時，纔會觸發標記整理算法。

• 1.3.4 增量標記（Incremental Marking）
  早期V8在垃圾回收階段，採用全停頓（stop the world），也就是垃圾回收時程序運行會被暫停。這在JavaScript還僅被用於瀏覽器端開發時，並沒有什麼明顯的缺點，前端開發使用的內存少，大多數時候僅觸發新生代垃圾回收，速度快，卡頓幾乎感覺不到。但是對於Node程序，使用內存更多，在老年代垃圾回收時，全停頓很容易帶來明顯的程序遲滯，標記階段很容易就會超過100ms，因此V8引入了增量標記，將標記階段分爲若干小步驟，每個步驟控制在5ms內，每運行一段時間標記動作，就讓JavaScript程序執行一會兒，如此交替，明顯地提高了程序流暢性，一定程度上避免了長時間卡頓。

二、Node開發中的內存管理與優化

2.1 手動變量銷燬

當任一作用域存活於作用域棧（作用域鏈）時，其中的變量都不會被銷燬，其引用的數據也會一直被變量關聯，得不到GC。有的作用域存活時間非常長（越是棧底，存活時間越長，最長的是全局作用域），但是其中的某些變量也許在某一時刻後就沒有用處了，因此建議手動設置爲null，斷開引用鏈接，使得V8可以及時GC釋放內存。
注意，不使用var聲明的變量，都會成爲全局對象的屬性。前端開發中全局對象爲window，Node中全局對象爲global，如果global中有屬性已經沒有用處了，一定要設置爲null，因爲全局作用域只有等到程序停止運行，纔會銷燬。
Node中，當一個模塊被引入，這個模塊就會被緩存在內存中，提高下次被引用的速度。也就是說，一般情況下，整個Node程序中對同一個模塊的引用，都是同一個實例（instance），這個實例一直存活在內存中。所以，如果任意模塊中有變量已經不再需要，最好手動設置爲null，不然會白白佔用內存，成爲“活着的死對象”。

2.2 慎用閉包

• 2.2.1 V8的閉包實現
  先來看一段例子：

function outer(){
    var x = 1; // 真正的局部變量：outer執行完後立即死亡
    var y = 2; // 上下文變量：閉包死亡後纔會死亡
    // 返回一個閉包
    return function(){
      console.log(y); // 使用了外層函數的變量 y
    }
}
var inner = outer(); // 通過inner變量持有閉包

有不少開發者認爲，如果閉包被引用，那麼閉包的外部函數也不會被釋放，其中的所有變量都不會被銷燬，比如我通過inner變量持有了閉包，此時outer中的 x、y 均活在內存中，不會被銷燬。事實真是這樣嗎？
答案是：在V8的實現中，當outer執行完畢，x 立即死亡，僅有 y 存活。
V8是這麼做的：
當程序進入一個函數時，將會爲這個函數創建一個上下文（Context），初始狀態這個Context是空的，當讀到這個函數（outer）中的閉包聲明時，將會把此閉包（inner）中使用的外部變量，加入Context。在上面的例子中，由於inner函數使用了變量 y ，因此會將 y 加入Context。outer內部所有的閉包，都會持有這個Context。

每一個閉包都會引用其外部函數的Context，以此訪問需要讀取的外部變量。被閉包捕捉，加入Context中的變量，我們稱爲Context變量，分配在堆。而真正的 局部變量（local variable）是 x ，保存在棧，當outer執行完畢後，其信息出棧，變量 x 自然銷燬，而Context被閉包引用，如果有任何一個閉包存活，Context都將存活，y 將不會被銷燬。
舉一反三，再來看一個更復雜的例子：

function outer () { 
    var x; // 真正的局部變量
    var y; // context variable, 被inner1使用
    var z; // context variable, 被inner2使用
    function inner1 () { 
      use(y); 
    } 
    function inner2 () { 
      use(z); 
    } 
    function inner3 () { 
      /* 雖然函數體爲空，但是作爲閉包，依舊引用outer的Context */
    } 
    return [inner1, inner2, inner3];
}

x、y、z 三個變量何時死亡？
x 在outer執行完後立即死亡， y、z 需要等到inner1、inner2、inner3三個閉包都死亡後，纔會死亡。
x 未被任何閉包使用，因此是一個真正的局部變量，保存在棧，函數執行完即被出棧死亡。由於 y、z 兩個變量分別被inner1、inner2使用，則它們會被加入outer的Context。所有閉包都會引用外部函數的Context，即使inner3爲空，不使用任何外部函數的變量，也會引用Context，所以需要等到三個閉包都死亡後，y、z 纔會死亡。

因此：如果較大的對象成爲了Context變量，建議嚴格控制引用此Context的閉包生命週期以及閉包數量，或在不需要時，設置爲null，以免引起較多內存的長期佔用。

• 2.2.2 避免深層閉包嵌套

function outer() { 
    var x = HUGE; // 超大對象
    function inner() { 
      var y = GIANT; // 大對象
      use(x); // x 需要使用，需要成爲Context變量
      function innerF() { 
        use(y); // y 需要使用，需要成爲Context變量
      } 
      function innerG() { 
        /* 空函數體 */
      } 
      return innerG; 
    } 
    return inner();
}
var o = outer(); // HUGE and GIANT 均得不到釋放

變量 o 持有的是innerG閉包，innerG持有着inner的Context，且內部閉包的Context會持有外部閉包的Context，產生Context鏈。

上下文鏈

爲了減輕GC壓力，建議避免過深嵌套函數/閉包，或及早手動斷開Context變量所引用的大對象。

2.3 大內存使用

• 2.3.1 使用stream
  當我們需要操作大文件，應該利用Node提供的stream以及其管道方法，防止一次性讀入過多數據，佔用堆空間，增大堆內存壓力。

• 2.3.2 使用Buffer
  Buffer是操作二進制數據的對象，不論是字符串還是圖片，底層都是二進制數據，因此Buffer可以適用於任何類型的文件操作。
  Buffer對象本身屬於普通對象，保存在堆，由V8管理，但是其儲存的數據，則是保存在堆外內存，是有C++申請分配的，因此不受V8管理，也不需要被V8垃圾回收，一定程度上節省了V8資源，也不必在意堆內存限制。
  

參考資料：

• 《深入理解Java虛擬機》（第二版）
• 《深入淺出Node.js》 樸靈
• http://apmblog.dynatrace.com/2015/11/04/understanding-garbage-collection-and-hunting-memory-leaks-in-node-js/
• http://info.meteor.com/blog/an-interesting-kind-of-javascript-memory-leak
• http://stackoverflow.com/questions/6602864/stack-and-heap-in-v8-javascript
• http://stackoverflow.com/questions/5326300/garbage-collection-with-node-js/5328761#5328761
• http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html
• http://stackoverflow.com/questions/5368048/how-are-closures-and-scopes-represented-at-run-time-in-javascript
• http://stackoverflow.com/questions/8665781/about-closure-lexicalenvironment-and-gc

轉載鏈接：https://www.jianshu.com/p/4129a3fce7bb