NodeJs-垃圾回收与内存管理

使用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变量持有闭包

答案是：在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，以免引起较多内存的长期占用。 有不少开发者认为，如果闭包被引用，那么闭包的外部函数也不会被释放，其中的所有变量都不会被销毁，比如我通过inner变量持有了闭包，此时outer中的 x、y 均活在内存中，不会被销毁。事实真是这样吗？

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变量所引用的大对象。

function outer() {

var x = HUGE; // 超大对象

2.3 大内存使用

• 2.3.1 使用stream 当我们需要操作大文件，应该利用Node提供的stream以及其管道方法，防止一次性读入过多数据，占用堆空间，增大堆内存压力。
• 2.3.2 使用Buffer Buffer是操作二进制数据的对象，不论是字符串还是图片，底层都是二进制数据，因此Buffer可以适用于任何类型的文件操作。 Buffer对象本身属于普通对象，保存在堆，由V8管理，但是其储存的数据，则是保存在堆外内存，是有C++申请分配的，因此不受V8管理，也不需要被V8垃圾回收，一定程度上节省了V8资源，也不必在意堆内存限制。