【譯文】Node.js垃圾回收機制-基礎

最近關注了一個國外技術博客RisingStack裏面有不少高質量，且對新手也很friendly的文章。正好最近在學習Node.js的各類實現原理，在這裏斗膽翻譯一篇Node.js垃圾回收機制（原文連接）。

正文

在這篇文章中，你將會學習Node.js的垃圾回收（garbege collection）機制是如何工做的；即在你敲代碼的時候，後臺是怎麼幫你清空內存裏的垃圾的。

1、Node.js應用的內存管理

內存的適當分配，對於全部應用都相當重要。內存管理的任務，就是在程序請求內存的時候動態地爲它們分配內存塊；並在程序再也不須要內存的時候釋放掉。

應用級別的內存管理，有手動管理和自動管理兩種模式。自動管理的機制中，一般都會包含垃圾回收機制。

The following code snippet shows how memory can be allocated in C, using manual memory management:

下面的代碼片斷展現了C語言中內存是如何分配的，這屬於手動管理：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main() {

   char name[20];
   char *description;

   strcpy(name, "RisingStack");

   // memory allocation
   description = malloc( 30 * sizeof(char) );

   if( description == NULL ) {
      fprintf(stderr, "Error - unable to allocate required memory\n");
   } else {
      strcpy( description, "Trace by RisingStack is an APM.");
   }

   printf("Company name = %s\n", name );
   printf("Description: %s\n", description );

   // release memory
   free(description);
}

在手動內存管理機制中，釋放無用內存的任務落在了程序猿身上。這樣可能會給應用帶來嚴重的問題：

1. 內存泄露：可能某些佔用的內存一直沒有被釋放。

2. 當一個對象被刪除（過早釋放）的時候，可能會有指針不指向任何有效的對象，但仍然指向原來的內存。這種指針被稱爲「懸掛指針」。這個時候若是再去使用這段內存，就會產生嚴重的安全問題。

但幸運的是，Node.js是自帶垃圾回收機制的，因此你不須要手動管理內存。

2、垃圾回收機制的概念

垃圾回收，是一種自動管理應用程序所佔內存的機制，簡稱「GC」（方便起見，本文均採用此簡寫）。它的任務，就是回收無用對象（即垃圾）所佔用的內存。它第一次出現，是在1959年的LISP語言中，由John McCarthy發明。

GC判斷一個對象爲垃圾的標準是：是否還有其餘對象引用它。

The way how the GC knows that objects are no longer in use is that no
other object has references to them.

若是沒有GC

下圖展現了沒有垃圾管理機制的時候，內存的狀況。能夠看到有的對象與其他的對象之間，沒有任何引用關係，但他們的內存也不會被回收。

有了GC以後

有了GC以後，沒有引用關係的對象佔用的內存，都會被GC悄然回收。

使用GC的優點

it prevents wild/dangling pointers bugs,
it won't try to free up space that was already freed up,
it will protect you from some types of memory leaks.
Of course, using a garbage collector doesn't solve all of your problems, and it’s not a silver bullet for memory management. Let's take a look at things that you should keep in mind!

• 避免了懸掛指針的出現。

• 它不會嘗試去重複釋放並無被佔用的內存。

• 它會防止某些類型的內存泄露。

固然了，GC並不能解決全部內存相關的問題，它不是解決內存管理問題的萬金油。有些使用GC的注意事項仍是須要開發者牢記：

performance impact - in order to decide what can be freed up, the GC consumes computing power
unpredictable stalls - modern GC implementations try to avoid "stop-the-world" collections

• 對性能的影響：在判斷哪些內存要釋放的時候，GC會佔用CPU資源。

• 不可預測的中斷：儘管如今的GC都會避免「中止一切」的狀況發生，可是仍是不可避免的會出現。

譯註：「中止一切」（stop-the-world）是指當垃圾收集沒有結束前，內存對於外部的請求是不會進行響應的,直到收集完畢應用纔會繼續響應請求。

3、Node.js垃圾回收&內存管理實踐

學代碼就是要寫代碼，下面就用幾段代碼展現本節的主題。首先介紹幾個基本概念：

棧（Stack）

棧中存儲着本地變量、指向堆中對象的指針、定義應用程序控制流的指針。

在下面的例子中，變量a、b都會存儲在棧中。

function add (a, b) {  
  return a + b
}

add(4, 5)

堆（Heap）

堆專門用於存儲「引用類型」的對象，例如字符串或對象。

下例中的Car對象就是保存在堆中的。

function Car (opts) {  
  this.name = opts.name
}

const LightningMcQueen = new Car({name: 'Lightning McQueen'})

執行以後，內存看上去會是這個樣子：

新建更多的Car對象的話，內存會變成這樣：

function Car (opts) {  
  this.name = opts.name
}

const LightningMcQueen = new Car({name: 'Lightning McQueen'})  
const SallyCarrera = new Car({name: 'Sally Carrera'})  
const Mater = new Car({name: 'Mater'})

若是這個時候執行垃圾回收，那麼什麼都不會發生，由於根對象（root）對每一個對象都有引用。

那如今把上述例子再複雜化一點，給Car對象添加點「部件」。

function Engine (power) {  
  this.power = power
}

function Car (opts) {  
  this.name = opts.name
  this.engine = new Engine(opts.power)
}

let LightningMcQueen = new Car({name: 'Lightning McQueen', power: 900})  
let SallyCarrera = new Car({name: 'Sally Carrera', power: 500})  
let Mater = new Car({name: 'Mater', power: 100})

What would happen, if we no longer use Mater, but redefine it and assign some other value, like Mater = undefined?

如今，若是咱們不想再使用Mater這個實例，把他賦一個別的值，好比Mater = undefined。這時會發生什麼？

能夠看到Mater失去了root對他的引用。那麼，在下次垃圾回收執行的時候，它的內存就會被釋放。

好了，如今咱們都理解了GC的基本原理和執行方式，來看看V8引擎中的GC是如何實現的吧！

垃圾回收方法

在咱們以前的一篇文章中，咱們介紹過Node.js的垃圾回收方法是如何工做的，我強烈建議閱讀此文章。

這篇文章的要點以下：

1. 新生代空間 & 老生代空間

堆中存在兩個「段」（segment），新生代空間（New Space）和老生代空間（Old Space）。新的內存分配都發生在新建空間中，它只有1-8MBs左右大，但垃圾回收卻很迅速和頻繁。這裏存儲的對象稱爲「新生代」（Young Generation）。

老生代空間中，存儲着那些新生代空間中未被回收，晉升至此的對象。它們被稱爲「老生代」（Old Generation）。這裏內存分配很是頻繁，但垃圾回收的成本卻很高，所以執行地不那麼頻繁。

2. 新生代

一般只有20%左右的新生代會晉升爲老生代。老生代空間只有在快被耗盡的時候，纔會執行垃圾回收。V8引擎採用了兩種回收算法來實現：Scavenge 和 Mark-Sweep 。

Scavenge回收算法運算速度很快，用於新生代；慢一些的Mark-Sweep算法用於老生代。

4、現實案例The Meteor Case-Study

2013年，Meteor的做者們發佈了一個他們遇到的內存泄露的例子。出問題的代碼段以下：

var theThing = null  
var replaceThing = function () {  
  var originalThing = theThing
  var unused = function () {
    if (originalThing)
      console.log("hi")
  }
  theThing = {
    longStr: new Array(1000000).join('*'),
    someMethod: function () {
      console.log(someMessage)
    }
  };
};
setInterval(replaceThing, 1000)

Well, the typical way that closures are implemented is that every
function object has a link to a dictionary-style object representing
its lexical scope. If both functions defined inside replaceThing
actually used originalThing, it would be important that they both get
the same object, even if originalThing gets assigned to over and over,
so both functions share the same lexical environment. Now, Chrome's V8
JavaScript engine is apparently smart enough to keep variables out of
the lexical environment if they aren't used by any closures - from the
Meteor blog.

一般來講，實現閉包的方式爲：每一個函數對象都連接到一個字典式的對象，此對象表現其詞法做用域。若是replaceThing中兩個函數都使用了變量originalThing，那麼即使originalThing被屢次賦值，也必須保證這兩個函數獲得的永遠是同一個對象，才能保證兩個函數共享一個詞法做用域。那麼問題來了，Chrome的V8
JavaScript引擎只有在一個變量沒有被用在任何閉包中的時候，纔會將其隔離在詞法環境以外。 - Meteor blog.

更多相關閱讀

Finding a memory leak in Node.js
JavaScript Garbage Collection Improvements - Orinoco
memorymanagement.org