深入理解 V8 的垃圾回收原理
JS 语言不像 C/C++，让程序员自己去开辟或者释放内存，而是类似 Java，采用自己的一套垃圾回收算法进行自动的内存管理。作为一名资深前端工程师，需要对 JS 的内存回收机制非常清楚，以便在极端的环境下能够分析出系统性能的瓶颈，另一方面，学习这其中的机制，也对我们深入理解 JS 的闭包特性、以及对内存的高效使用，都有很大的帮助。
垃圾回收机制
V8 的垃圾回收策略基于分代回收机制，该机制又基于世代假说。该假说有两个特点：
- 大部分新生对象倾向于早死
- 不死的对象，会活得更久
基于这个理论，现代垃圾回收算法根据对象的存活时间将内存进行了分代，并对不同分代的内存采用不同的高效算法进行垃圾回收。
V8 的内存分代
在 V8 中，将内存分为了新生代（new space）和老生代（old space）。它们的特点如下：
- 新生代：对象的存活时间较短（新生对象或只经过一次垃圾回收的对象）
- 老生代：对象存活时间较长（经历过一次或多次垃圾回收的对象）
V8 堆的空间等于新生代空间加上老生代空间。我们可以通过 --max-old-space-size 命令设置老生代空间的最大值，--max-new-space-size 命令设置新生代空间的最大值。老生代与新生代的空间大小在程序初始化时设置，一旦生效则不能动态改变。
1 | node --max-old-space-size=2048 test.js // 单位为 MB |
默认设置下，64 位系统的老生代大小为 1400M，32 位系统为 700M。
对于新生代，它由两个 reserved_semispace_size 组成。每个 reserved_semispace_size 的大小在不同位数的机器上大小不同。默认设置下，在 64 位与 32 位的系统下分别为 16MB 和 8MB。
| 类型 / 系统位数 | 64位 | 32位 |
|---|---|---|
| 老生代 | 1400MB | 700MB |
| reserved_semispace_size | 16MB | 8MB |
| 新生代 | 32MB | 16MB |
回收算法
全停顿（Stop The World）
在介绍垃圾回收算法之前，我们先了解一下「全停顿」。垃圾回收算法在执行前，需要将应用逻辑暂停，执行完垃圾回收后再执行应用逻辑，这种行为称为「全停顿」。例如，如果一次 GC 需要 50ms，应用逻辑就会暂停 50ms。
全停顿的目的，是为了解决应用逻辑与垃圾回收器看到的情况不一致的问题。例如，在自助餐厅吃饭，高高兴兴地取完食物回来时，结果发现自己餐具被服务员收走了。这里，服务员就好比垃圾回收器，餐具就像是分配的对象，我们就是应用逻辑。在我们看来，只是将餐具临时放在桌上，但是在服务员看来觉得你已经不需要使用，因此就收走了。你与服务员对于同一个事物看到的情况不一致，导致服务员做了与我们不期望的事情。因此，为避免应用逻辑与垃圾回收器看到的情况不一致，垃圾回收算法在执行时，需要停止应用逻辑。
Scavenge 算法
新生代中的对象主要通过 Scavenge 算法进行垃圾回收。Scavenge 的具体实现，主要采用了 Cheney 算法。
Cheney 算法采用复制的方式进行垃圾回收。它将堆内存一分为二，每一部分空间称为 semispace。这两个空间，只有一个空间处于使用中，另一个则处于闲置状态。使用中的 semispace 称为 「From 空间」，闲置的 semispace 称为 「To 空间」。
过程如下：
- 从 From 空间分配对象，若 semispace 被分配满，则执行 Scavenge 算法进行垃圾回收
- 检查 From 空间的存活对象，若对象存活，则检查对象是否符合晋升条件，若符合条件则晋升到老生代，否则将对象从 From 空间复制到 To 空间
- 若对象不存活，则释放不存活对象的空间
- 完成复制后，将 From 空间与 To 空间进行角色翻转
对象晋升
对象晋升的条件有两个：
- 对象是否经历过 Scavenge 回收。对象从 From 空间复制到 To 空间时，会检查对象的内存地址来判断对象是否已经经过一次 Scavenge 回收。若经历过，则将对象从 From 空间复制到老生代中；若没有经历，则复制到 To 空间。
- To 空间的内存使用占比是否超过限制。当对象从 From 空间复制到 To 空间时，若 To 空间使用超过 25%，则对象直接晋升到老生代中。设置为 25% 比例的原因是，当完成 Scavenge 回收后，To 空间将翻转成 From 空间，继续进行对象内存的分配。若占比过大，将影响后续内存分配。
对象晋升到老生代后，将接受新的垃圾回收算法处理。下图为 Scavenge 算法中，对象晋升流程图。
Scavenge 算法的缺点是，它的算法机制决定了只能利用一半的内存空间。但是新生代中的对象生存周期短、存活对象少，进行对象复制的成本不是很高，因而非常适合这种场景。
Mark-Sweep & Mark-Compact
老生代中的对象有两个特点，第一是存活对象多，第二个存活时间长。若在老生代中使用 Scavenge 算法进行垃圾回收，将会导致复制存活对象的效率不高，且还会浪费一半的空间。因而，V8 在老生代采用 Mark-Sweep 和 Mark-Compact 算法进行垃圾回收。
标记清除（Mark-Sweep）
Mark-Sweep，是标记清除的意思。它主要分为标记和清除两个阶段。
- 标记阶段，它将遍历堆中所有对象，并对存活的对象进行标记
- 清除阶段，对未标记对象的空间进行回收
与 Scavenge 算法不同，Mark-Sweep 不会对内存一分为二，因此不会浪费空间。但是，经历过一次 Mark-Sweep 之后，内存的空间将会变得不连续，这样会对后续内存分配造成影响。例如，当需要分配一个比较大的对象时，没有任何一个碎片内支持分配，这将提前触发一次垃圾回收，尽管这次垃圾回收是没有必要的。
标记压缩（Mark-Compact）
为了解决内存碎片的问题，提高内存的利用率，引入了 Mark-Compact 算法。Mark-Compact 在 Mark-Sweep 算法上进行了改进，标记阶段与 Mark-Sweep 相同，但是对未标记的对象处理方式不同。与 Mark-Sweep 是对未标记的对象立即进行回收，Mark-Compact 则是将存活的对象移动到一边，然后再清理端边界外的内存。
由于 Mark-Compact 需要移动对象，所以执行速度上，比 Mark-Sweep 要慢。所以，V8 主要使用 Mark-Sweep 算法，然后在当空间内存分配不足时，采用 Mark-Compact 算法。
增量标记（Incremental Marking）
在新生代中，由于存活对象少，垃圾回收效率高，全停顿时间短，造成的影响小。但是老生代中，存活对象多，垃圾回收时间长，全停顿造成的影响大。为了减少全停顿的时间，V8 对标记进行了优化，将一次停顿进行的标记过程，分成了很多小步。每执行完一小步就让应用逻辑执行一会儿，这样交替多次后完成标记。如下所示：
1 | GC JS GC JS |
长时间的 GC，会导致应用暂停和无响应，将会导致糟糕的用户体验。从 2011 年起，V8 就将「全暂停」标记换成了增量标记。改进后的标记方式，最大停顿时间减少到原来的 1/6。
延迟清理（lazy sweeping）
- 发生在增量标记之后
- 堆确切地知道有多少空间能被释放
- 延迟清理是被允许的，因此页面的清理可以根据需要进行清理
- 当延迟清理完成后，增量标记将重新开始
总结
了解 GC 原理，有助于我们对 NodeJS 项目进行性能瓶颈定位与调优。文章所描述的算法为 V8 中使用的基础算法，现代 V8 引擎已经对垃圾回收进行了很多改进。例如，在 Chrome 64 和 NodeJS V10 中 V8 启用了「并行标记」技术，将标记时间缩短了 60%~70%。还有「Parallel Scavenger」技术，它将新生代的垃圾回收时间缩短了 20%~50%。
垃圾回收是影响服务性能的因素之一，为了提高服务性能，应尽量减少垃圾回收的次数。
V8 堆内存最大值在 64 位系统上为 1464MB，在 32 位系统上为 732MB。计算公式如下：
1 | V8 堆内存最大保留空间 = 4 * reserved_semispace_size_ + max_old_generation_size_ |