关于垃圾回收机制:深入理解Chrome-V8垃圾回收机制

最近，我的项目进入保护期，根本没有什么需要，比拟闲，这让我莫名的有了危机感，每天像是在混日子，感觉这像是在温水煮青蛙，曾经毕业 3 年了，很怕本人到了 5 年教训的时候，能力却和 3 年教训的时候一样，没什么出息。于是开始整顿本人的技术点，刚好查漏补缺，在收藏夹在翻出了一篇文章一名【合格】前端工程师的自检清单，看到了外面的两个问题：

JavaScript中的变量在内存中的具体存储模式是什么？
浏览器的垃圾回收机制，如何防止内存透露？

而后各种查资料，就整顿了这篇文章。

浏览本文之后，你能够理解到：

JavaScript 的内存是怎么治理的？
Chrome 是如何进行垃圾回收的？
Chrome 对垃圾回收进行了哪些优化？

原文地址欢送 star

不论什么程序语言，内存生命周期根本是统一的：

调配你所须要的内存
应用调配到的内存（读、写）
不须要时将其开释偿还

与其余须要手动治理内存的语言不通，在 JavaScript 中，当咱们创立变量（对象，字符串等）的时候，零碎会主动给对象调配对应的内存。

var n = 123; // 给数值变量分配内存
var s = "azerty"; // 给字符串分配内存

var o = {
  a: 1,
  b: null
}; // 给对象及其蕴含的值分配内存

// 给数组及其蕴含的值分配内存（就像对象一样）var a = [1, null, "abra"]; 

function f(a){return a + 2;} // 给函数（可调用的对象）分配内存

// 函数表达式也能调配一个对象
someElement.addEventListener('click', function(){someElement.style.backgroundColor = 'blue';}, false);

当零碎发现这些变量不再被应用的时候，会主动开释（垃圾回收）这些变量的内存，开发者不必过多的关怀内存问题。

尽管这样，咱们开发过程中也须要理解 JavaScript 的内存管理机制，这样能力防止一些不必要的问题，比方上面代码：

{}=={} // false
[]==[] // false
''=='' // true

在 JavaScript 中，数据类型分为两类，简略类型和援用类型，对于简略类型，内存是保留在栈（stack）空间中，简单数据类型，内存是保留在堆（heap）空间中。

根本类型：这些类型在内存中别离占有固定大小的空间，他们的值保留在栈空间，咱们通过按值来拜访的
援用类型：援用类型，值大小不固定，栈内存中寄存地址指向堆内存中的对象。是按援用拜访的。

而对于栈的内存空间，只保留简略数据类型的内存，由操作系统主动调配和主动开释。而堆空间中的内存，因为大小不固定，零碎无奈无奈进行主动开释，这个时候就须要 JS 引擎来手动的开释这些内存。

在 Chrome 中，v8 被限度了内存的应用（64 位约 1.4G/1464MB，32 位约 0.7G/732MB），为什么要限度呢？

表层起因是，V8 最后为浏览器而设计，不太可能遇到用大量内存的场景
深层起因是，V8 的垃圾回收机制的限度（如果清理大量的内存垃圾是很耗时间，这样回引起 JavaScript 线程暂停执行的工夫，那么性能和利用直线降落）

后面说到栈内的内存，操作系统会主动进行内存调配和内存开释，而堆中的内存，由 JS 引擎（如 Chrome 的 V8）手动进行开释，当咱们代码的依照正确的写法时，会使得 JS 引擎的垃圾回收机制无奈正确的对内存进行开释（内存泄露），从而使得浏览器占用的内存一直减少，进而导致 JavaScript 和利用、操作系统性能降落。

在 JavaScript 中，其实绝大多数的对象存活周期都很短，大部分在通过一次的垃圾回收之后，内存就会被开释掉，而少部分的对象存活周期将会很长，始终是沉闷的对象，不须要被回收。为了进步回收效率，V8 将堆分为两类 新生代 和老生代，新生代中寄存的是生存工夫短的对象，老生代中寄存的生存工夫久的对象。

新生区通常只反对 1～8M 的容量，而老生区反对的容量就大很多了。对于这两块区域，V8 别离应用两个不同的垃圾回收器，以便更高效地施行垃圾回收。

副垃圾回收器 – Scavenge：次要负责新生代的垃圾回收。
主垃圾回收器 – Mark-Sweep & Mark-Compact：次要负责老生代的垃圾回收。

在 JavaScript 中，任何对象的申明调配到的内存，将会先被搁置在新生代中，而因为大部分对象在内存中存活的周期很短，所以须要一个效率十分高的算法。在新生代中，次要应用 Scavenge 算法进行垃圾回收，Scavenge算法是一个典型的就义空间换取工夫的复制算法，在占用空间不大的场景上十分实用。

Scavange 算法将新生代堆分为两局部，别离叫 from-space 和to-space，工作形式也很简略，就是将 from-space 中存活的流动对象复制到 to-space 中，并将这些对象的内存有序的排列起来，而后将 from-space 中的非流动对象的内存进行开释，实现之后，将 from space 和to space 进行调换，这样能够使得新生代中的这两块区域能够反复利用。

简略的形容就是：

标记流动对象和非流动对象
复制 from space 的流动对象到 to space 并对其进行排序
开释 from space 中的非流动对象的内存
将 from space 和 to space 角色调换

那么，垃圾回收器是怎么晓得哪些对象是流动对象和非流动对象的呢？

有一个概念叫对象的可达性，示意从初始的根对象（window，global）的指针开始，这个根指针对象被称为根集（root set），从这个根集向下搜寻其子节点，被搜寻到的子节点阐明该节点的援用对象可达，并为其留下标记，而后递归这个搜寻的过程，直到所有子节点都被遍历完结，那么没有被标记的对象节点，阐明该对象没有被任何中央援用，能够证实这是一个须要被开释内存的对象，能够被垃圾回收器回收。

新生代中的对象什么时候变成老生代的对象呢？

在新生代中，还进一步进行了细分，分为 nursery 子代和 intermediate 子代两个区域，一个对象第一次分配内存时会被调配到新生代中的 nursery 子代，如果进过下一次垃圾回收这个对象还存在新生代中，这时候咱们挪动到 intermediate 子代，再通过下一次垃圾回收，如果这个对象还在新生代中，副垃圾回收器会将该对象挪动到老生代中，这个挪动的过程被称为降职。

新生代空间中的对象满足肯定条件后，降职到老生代空间中，在老生代空间中的对象都曾经至多经验过一次或者屡次的回收所以它们的存活概率会更大，如果这个时候再应用 scavenge 算法的话，会呈现两个问题：

scavenge 为复制算法，反复复制流动对象会使得效率低下
scavenge 是就义空间来换取工夫效率的算法，而老生代反对的容量交大，会呈现空间资源节约问题

所以在老生代空间中采纳了 Mark-Sweep（标记革除）和 Mark-Compact（标记整顿）算法。

Mark-Sweep 解决时分为两阶段，标记阶段和清理阶段，看起来与 Scavenge 相似，不同的是，Scavenge 算法是复制流动对象，而因为在老生代中流动对象占大多数，所以 Mark-Sweep 在标记了流动对象和非流动对象之后，间接把非流动对象革除。

标记阶段：对老生代进行第一次扫描，标记流动对象
清理阶段：对老生代进行第二次扫描，革除未被标记的对象，即清理非流动对象

看似所有 perfect，然而还遗留一个问题，被革除的对象遍布于各内存地址，产生很多内存碎片。

因为 Mark-Sweep 实现之后，老生代的内存中产生了很多内存碎片，若不清理这些内存碎片，如果呈现须要调配一个大对象的时候，这时所有的碎片空间都齐全无奈实现调配，就会提前触发垃圾回收，而这次回收其实不是必要的。

为了解决内存碎片问题，Mark-Compact 被提出，它是在是在 Mark-Sweep 的根底演出进而来的，相比 Mark-Sweep，Mark-Compact 增加了流动对象整顿阶段，将所有的流动对象往一端挪动，挪动实现后，间接清理掉边界外的内存。

因为垃圾回收是在 JS 引擎中进行的，而 Mark-Compact 算法在执行过程中须要挪动对象，而当流动对象较多的时候，它的执行速度不可能很快，为了防止 JavaScript 应用逻辑和垃圾回收器的内存资源竞争导致的不一致性问题，垃圾回收器会将 JavaScript 利用暂停，这个过程，被称为 全进展（stop-the-world）。

在新生代中，因为空间小、存活对象较少、Scavenge 算法执行效率较快，所以全进展的影响并不大。而老生代中就不一样，如果老生代中的流动对象较多，垃圾回收器就会暂停主线程较长的工夫，使得页面变得卡顿。

orinoco 为 V8 的垃圾回收器的我的项目代号，为了晋升用户体验，解决全进展问题，它利用了增量标记、懒性清理、并发、并行来升高主线程挂起的工夫。

为了升高全堆垃圾回收的进展工夫，增量标记将本来的标记全堆对象拆分为一个一个工作，让其穿插在 JavaScript 应用逻辑之间执行，它容许堆的标记时的 5~10ms 的进展。增量标记在堆的大小达到肯定的阈值时启用，启用之后每当一定量的内存调配后，脚本的执行就会进展并进行一次增量标记。

增量标记只是对流动对象和非流动对象进行标记，惰性清理用来真正的清理开释内存。当增量标记实现后，如果以后的可用内存足以让咱们疾速的执行代码，其实咱们是没必要立刻清理内存的，能够将清理的过程提早一下，让 JavaScript 逻辑代码先执行，也无需一次性清理完所有非流动对象内存，垃圾回收器会按需逐个进行清理，直到所有的页都清理结束。

增量标记与惰性清理的呈现，使得主线程的最大进展工夫缩小了 80%，让用户与浏览器交互过程变得晦涩了许多，从实现机制上，因为每个小的增量标价之间执行了 JavaScript 代码，堆中的对象指针可能产生了变动，须要应用 写屏障 技术来记录这些援用关系的变动，所以也裸露进去增量标记的毛病：

并没有缩小主线程的总暂停的工夫，甚至会稍微减少
因为写屏障（Write-barrier）机制的老本，增量标记可能会升高应用程序的吞吐量

并发式 GC 容许在在垃圾回收的同时不须要将主线程挂起，两者能够同时进行，只有在个别时候须要短暂停下来让垃圾回收器做一些非凡的操作。然而这种形式也要面对增量回收的问题，就是在垃圾回收过程中，因为 JavaScript 代码在执行，堆中的对象的援用关系随时可能会变动，所以也要进行 写屏障 操作。

并行式 GC 容许主线程和辅助线程同时执行同样的 GC 工作，这样能够让辅助线程来分担主线程的 GC 工作，使得垃圾回收所消耗的工夫等于总工夫除以参加的线程数量（加上一些同步开销）。

2011 年，V8 利用了增量标记机制。直至 2018 年，Chrome64 和 Node.js V10 启动并发标记（Concurrent），同时在并发的根底上增加并行（Parallel）技术，使得垃圾回收工夫大幅度缩短。

V8 在新生代垃圾回收中，应用并行（parallel）机制，在整顿排序阶段，也就是将流动对象从 from-to 复制到 space-to 的时候，启用多个辅助线程，并行的进行整顿。因为多个线程竞争一个新生代的堆的内存资源，可能呈现有某个流动对象被多个线程进行复制操作的问题，为了解决这个问题，V8 在第一个线程对流动对象进行复制并且复制实现后，都必须去保护复制这个流动对象后的指针转发地址，以便于其余帮助线程能够找到该流动对象后能够判断该流动对象是否已被复制。

V8 在老生代垃圾回收中，如果堆中的内存大小超过某个阈值之后，会启用并发（Concurrent）标记工作。每个辅助线程都会去追踪每个标记到的对象的指针以及对这个对象的援用，而在 JavaScript 代码执行时候，并发标记也在后盾的辅助过程中进行，当堆中的某个对象指针被 JavaScript 代码批改的时候，写入屏障（write barriers）技术会在辅助线程在进行并发标记的时候进行追踪。

当并发标记实现或者动态分配的内存达到极限的时候，主线程会执行最终的疾速标记步骤，这个时候主线程会挂起，主线程会再一次的扫描根集以确保所有的对象都实现了标记，因为辅助线程曾经标记过流动对象，主线程的本次扫描只是进行 check 操作，确认实现之后，某些辅助线程会进行清理内存操作，某些辅助过程会进行内存整理操作，因为都是并发的，并不会影响主线程 JavaScript 代码的执行。

其实，大部分 JavaScript 开发人员并不需要思考垃圾回收，然而理解一些垃圾回收的外部原理，能够帮忙你理解内存的应用状况，依据内存应用察看是否存在内存泄露，而避免内存泄露，是晋升利用性能的一个重要动作。

NodeJs internals: V8 & garbage collector
「译」Orinoco: V8 的垃圾回收器
Trash talk: the Orinoco garbage collector
Chrome 浏览器垃圾回收机制与内存透露剖析
JavaScript 中的堆栈以及垃圾回收机制
超具体的 node/v8/js 垃圾回收机制
垃圾回收技术
4 类 JavaScript 内存透露及如何防止
内存治理
Nodejs 中的内存治理和 V8 垃圾回收机制

关于垃圾回收机制:深入理解Chrome-V8垃圾回收机制

JavaScript 的内存治理

为什么须要垃圾回收

Chrome 垃圾回收算法

新生代垃圾回收器 – Scavenge

老生代垃圾回收 – Mark-Sweep & Mark-Compact

Mark-Sweep

Mark-Compact

全进展 Stop-The-World

优化 Orinoco

增量标记 – Incremental marking

懒性清理 – Lazy sweeping

并发 – Concurrent

并行 – Parallel

V8 以后垃圾回收机制

副垃圾回收器

主垃圾回收器

完结

参考文献