目录
假设代码中有一个对象 jerry ，这个对象从创建到被销毁，刚好走完了整个生命周期，通常会是这样一个过程：
1、这个对象被分配到了 new space；
2、随着程序的运行，new space 塞满了，gc 开始清理 new space 里的死对象，jerry 因为还处于活跃状态，所以没被清理出去；
3、gc 清理了两遍 new space，发现 jerry 依然还活跃着，就把 jerry 移动到了 old space；
4、随着程序的运行，old space 也塞满了，gc 开始清理 old space，这时候发现 jerry 已经没有被引用了，就把 jerry 给清理出去了。
说明：
第二步里，清理 new space 的过程叫做 Scavenge，这个过程采用了空间换时间的做法，
用到了上面图中的 inactive new space，过程如下：
当活跃区满了之后，交换活跃区和非活跃区，交换后活跃区变空了；
将非活跃区的两次清理都没清理出去的对象移动到 old space；
将还没清理够两次的但是活跃状态的对象移动到活跃区。
第四步里，清理 old space 的过程叫做 Mark-sweep ，这块占用内存很大，所以没有使用 Scavenge，
这个回收过程包含了若干次标记过程和清理过程：
标记从根（root）可达的对象为黑色；
遍历黑色对象的邻接对象，直到所有对象都标记为黑色；
循环标记若干次；
清理掉非黑色的对象。
简单来说，Mark-sweep 就是把从根节点无法获取到的对象清理掉了。
JavaScript使用垃圾回收机制来自动管理内存。
垃圾回收是一把双刃剑，其好处是可以大幅简化程序的内存管理代码，降低程序员的负担，减少因 长时间运转而带来的内存泄露问题。
但使用了垃圾回收即意味着程序员将无法掌控内存。
ECMAScript没有暴露任何垃圾回收器的接口。我们无法强迫其进 行垃圾回收，更无法干预内存管理
在浏览器中，Chrome V8引擎实例的生命周期不会很长（谁没事一个页面开着几天几个月不关），而且运行在用户的机器上。 如果不幸发生内存泄露等问题，仅仅会 影响到一个终端用户。 且无论这个V8实例占用了多少内存，最终在关闭页面时内存都会被释放，几乎没有太多管理的必要（当然并不代表一些大型Web应用不需 要管理内存）。 但如果使用Node作为服务器，就需要关注内存问题了，一旦内存发生泄漏，久而久之整个服务将会瘫痪（服务器不会频繁的重启）。
Chrome限制了所能使用的内存极限（64位为1.4GB，32位为1.0GB），这也就意味着将无法直接操作一些大内存对象。
Chrome之所以限制了内存的大小，表面上的原因是V8最初是作为浏览器的JavaScript引擎而设计，不太可能遇到大量内存的场景， 而深层次的原因 则是由于V8的垃圾回收机制的限制。 由于V8需要保证JavaScript应用逻辑与垃圾回收器所看到的不一样，V8在执行垃圾回收时会阻塞 JavaScript应用逻辑， 直到垃圾回收结束再重新执行JavaScript应用逻辑，这种行为被称为“全停顿”（stop-the-world）。 若V8的堆内存为1.5GB，V8做一次小的垃圾回收需要50ms以上，做一次非增量式的垃圾回收甚至要1秒以上。 这样浏览器将在1s内失去对用户的响 应，造成假死现象。如果有动画效果的话，动画的展现也将显著受到影响。
V8的堆其实并不只是由老生代和新生代两部分构成，可以将堆分为几个不同的区域：
* 新生代内存区：大多数的对象被分配在这里，这个区域很小但是垃圾回特别频繁
* 老生代指针区：属于老生代，这里包含了大多数可能存在指向其他对象的指针的对象，大多数从新生代晋升的对象会被移动到这里
* 老生代数据区：属于老生代，这里只保存原始数据对象，这些对象没有指向其他对象的指针
* 大对象区：这里存放体积超越其他区大小的对象，每个对象有自己的内存，垃圾回收其不会移动大对象
* 代码区：代码对象，也就是包含JIT之后指令的对象，会被分配在这里。唯一拥有执行权限的内存区
* Cell区、属性Cell区、Map区：存放Cell、属性Cell和Map，每个区域都是存放相同大小的元素，结构简单
每个区域都是由一组内存页构成，内存页是V8申请内存的最小单位，除了大对象区的内存页较大以外， 其他区的内存页都是1MB大小，而且按照1MB对 齐。 内存页除了存储的对象，还有一个包含元数据和标识信息的页头，以及一个用于标记哪些对象是活跃对象的位图区。 另外每个内存页还有一个单独分配在另外内 存区的槽缓冲区，里面放着一组对象，这些对象可能指向其他存储在该页的对象。 垃圾回收器只会针对新生代内存区、老生代指针区以及老生代数据区进行垃圾回收
如何确定哪些内存需要回收，哪些内存不需要回收，这是垃圾回收期需要解决的最基本问题。
我们可以这样假定，一个对象为活对象当且仅当它被一个根对象 或另一个活对象指向。根对象永远是活对象，它是被浏览器或V8所引用的对象。
垃圾回收器需要面临一个问题，它需要判断哪些是数据，哪些是指针。由于很多垃圾回收算法会将对象在内存中移动（紧凑，减少内存碎片），所以经常需要进行指针的改写。
目前主要有三种方法来识别指针：
- 保守法： 将所有堆上对齐的字都认为是指针，那么有些数据就会被误认为是指针。 于是某些实际是数字的假指针，会背误认为指向活跃对象， 导致内存泄露（假指针指向的对象可能是死对象，但依旧有指针指向——这个假指针指向它）同时我们不能移动任何内存区域。
- 编译器提示法： 如果是静态语言，编译器能够告诉我们每个类当中指针的具体位置， 而一旦我们知道对象时哪个类实例化得到的，就能知道对象中所有指针。 这是JVM实现垃圾回收的方式，但这种方式并不适合JS这样的动态语言
- 标记指针法： 这种方法需要在每个字末位预留一位来标记这个字段是指针还是数据。 这种方法需要编译器支持，但实现简单，而且性能不错。 V8采用的是这种方式。V8将所有数据以32bit字宽来存储，其中最低一位保持为0，而指针的最低两位为01
自动垃圾回收算法的演变过程中出现了很多算法，但是由于不同对象的生存周期不同，没有一种算法适用于所有的情况。 所以V8采用了一种分代回收的策 略，将内存分为两个生代：新生代和老生代。 新生代的对象为存活时间较短的对象，老生代中的对象为存活时间较长或常驻内存的对象。 分别对新生代和老生代使用 不同的垃圾回收算法来提升垃圾回收的效率。 对象起初都会被分配到新生代，当新生代中的对象满足某些条件（后面会有介绍）时，会被移动到老生代（晋升）
默认情况下，64位环境下的V8引擎的新生代内存大小32MB、老生代内存大小为1400MB，而32位则减半，分别为16MB和700MB。 V8内存的最大保留空间分别为1464MB（64位）和732MB（32位）。 具体的计算公式是4*reserved_semispace_space_ + max_old_generation_size_， 新生代由两块reserved_semispace_space_组成，每块16MB（64位）或8MB（32位）
大多数的对象被分配在这里，这个区域很小但是垃圾回特别频繁。 在新生代分配内存非常容易，我们只需要保存一个指向内存区的指针，不断根据新对象的大小进行递增即可。 当该指针到达了新生代内存区的末尾，就会有一次清理（仅仅是清理新生代）
新生代使用Scavenge算法进行回收。在Scavenge算法的实现中，主要采用了Cheney算法。
具体的执行过程大致是这样：
首先将From空间中所有能从根对象到达的对象复制到To区，
然后维护两个To区的指针scanPtr和allocationPtr，分别指向即将 扫描的活跃对象和即将为新对象分配内存的地方，开始循环。
循环的每一轮会查找当前scanPtr所指向的对象，确定对象内部的每个指针指向哪里。
如果指向 老生代我们就不必考虑它了。
如果指向From区，我们就需要把这个所指向的对象从From区复制到To区，具体复制的位置就是allocationPtr 所指向的位置。
复制完成后将scanPtr所指对象内的指针修改为新复制对象存放的地址，并移动allocationPtr。
如果一个对象内部的所有指针 都被处理完，scanPtr就会向前移动，进入下一个循环。
若scanPtr和allocationPtr相遇，则说明所有的对象都已被复制完，From 区剩下的都可以被视为垃圾，可以进行清理了。
举个栗子(以及凑篇幅)，如果有类似如下的引用情况：
+----- A对象
|
根对象----+----- B对象 ------ E对象
|
+----- C对象 ----+---- F对象
|
+---- G对象 ----- H对象
D对象
在执行Scavenge之前，From区长这幅模样
+---+---+---+---+---+---+---+---+--------+
| A | B | C | D | E | F | G | H | |
+---+---+---+---+---+---+---+---+--------+
那么首先将根对象能到达的ABC对象复制到To区，于是乎To区就变成了这个样子：
allocationPtr
↓
+---+---+---+----------------------------+
| A | B | C | |
+---+---+---+----------------------------+
↑
scanPtr
接下来进入循环，扫描scanPtr所指的A对象，发现其没有指针，于是乎scanPtr移动，变成如下这样
allocationPtr
↓
+---+---+---+----------------------------+
| A | B | C | |
+---+---+---+----------------------------+
↑
scanPtr
接下来扫描B对象，发现其有指向E对象的指针，且E对象在From区，那么我们需要将E对象复制到allocationPtr所指的地方并移动allocationPtr指针：
allocationPtr
↓
+---+---+---+---+------------------------+
| A | B | C | E | |
+---+---+---+---+------------------------+
↑
scanPtr
B对象里所有指针都已被复制完，所以移动scanPtr：
allocationPtr
↓
+---+---+---+---+------------------------+
| A | B | C | E | |
+---+---+---+---+------------------------+
↑
scanPtr
接下来扫描C对象，C对象中有两个指针，分别指向F对象和G对象，且都在From区，先复制F对象到To区：
allocationPtr
↓
+---+---+---+---+---+--------------------+
| A | B | C | E | F | |
+---+---+---+---+---+--------------------+
↑
scanPtr
然后复制G对象到To区
allocationPtr
↓
+---+---+---+---+---+---+----------------+
| A | B | C | E | F | G | |
+---+---+---+---+---+---+----------------+
↑
scanPtr
这样C对象内部的指针已经复制完成了，移动scanPtr：
allocationPtr
↓
+---+---+---+---+---+---+----------------+
| A | B | C | E | F | G | |
+---+---+---+---+---+---+----------------+
↑
scanPtr
逐个扫描E，F对象，发现其中都没有指针，移动scanPtr：
allocationPtr
↓
+---+---+---+---+---+---+----------------+
| A | B | C | E | F | G | |
+---+---+---+---+---+---+----------------+
↑
scanPtr
扫描G对象，发现其中有一个指向H对象的指针，且H对象在From区，复制H对象到To区，并移动allocationPtr：
allocationPtr
↓
+---+---+---+---+---+---+---+------------+
| A | B | C | E | F | G | H | |
+---+---+---+---+---+---+---+------------+
↑
scanPtr
完成后由于G对象没有其他指针，且H对象没有指针移动scanPtr：
allocationPtr
↓
+---+---+---+---+---+---+---+------------+
| A | B | C | E | F | G | H | |
+---+---+---+---+---+---+---+------------+
↑
scanPtr
此时scanPtr和allocationPtr重合，说明复制结束
可以对比一下From区和To区在复制完成后的结果：
//From区
+---+---+---+---+---+---+---+---+--------+
| A | B | C | D | E | F | G | H | |
+---+---+---+---+---+---+---+---+--------+
//To区
+---+---+---+---+---+---+---+------------+
| A | B | C | E | F | G | H | |
+---+---+---+---+---+---+---+------------+
D对象没有被复制，它将被作为垃圾进行回收
如果新生代中的一个对象只有一个指向它的指针，而这个指针在老生代中， 我们如何判断这个新生代的对象是否存活？ 为了解决这个问题，需要建立一个列表用来记录所有老生代对象指向新生代对象的情况。 每当有老生代对象指向新生代对象的时候，我们就记录下来
当一个对象经过多次新生代的清理依旧幸存，这说明它的生存周期较长，也就会被移动到老生代，这称为对象的晋升。具体移动的标准有两种：
- 对象从From空间复制到To空间时，会检查它的内存地址来判断这个对象是否已经经历过一个新生代的清理，如果是，则复制到老生代中，否则复制到To空间中
- 对象从From空间复制到To空间时，如果To空间已经被使用了超过25%，那么这个对象直接被复制到老生代
老生代所保存的对象大多数是生存周期很长的甚至是常驻内存的对象，而且老生代占用的内存较多
老生代占用内存较多（64位为1.4GB，32位为700MB），如果使用Scavenge算法， 浪费一半空间不说，复制如此大块的内存消耗时间将 会相当长。所以Scavenge算法显然不适合。 V8在老生代中的垃圾回收策略采用 Mark-Sweep和Mark-Compact 相结合
标记清除分为标记和清除两个阶段。 在标记阶段需要遍历堆中的所有对象，并标记那些活着的对象，然后进入清除阶段。 在清除阶段总，只清除没有被标记的对象。 由于标记清除只清除死亡对象，而死亡对象在老生代中占用的比例很小，所以效率较高
标记清除有一个问题就是进行一次标记清楚后，内存空间往往是不连续的，会出现很多的内存碎片。 如果后续需要分配一个需要内存空间较多的对象时，如果所有的内存碎片都不够用，将会使得V8无法完成这次分配，提前触发垃圾回收。
标记整理正是为了解决标记清除所带来的内存碎片的问题。 标记整理在标记清除的基础进行修改，将其的清除阶段变为紧缩极端。 在整理的过程中，将活着的 对象向内存区的一段移动，移动完成后直接清理掉边界外的内存。 紧缩过程涉及对象的移动，所以效率并不是太好，但是能保证不会生成内存碎片。
标记清除和标记整理都分为两个阶段：标记阶段、清除或紧缩阶段
在标记阶段，所有堆上的活跃对象都会被标记。 每个内存页有一个用来标记对象的位图，位图中的每一位对应内存页中的一个字。 这个位图需要占据一定的空 间（32位下为3.1%，64位为1.6%）。 另外有两位用来标记对象的状态，这个状态一共有三种（所以要两位）——白，灰，黑：
- 如果一个对象为白对象，它还没未被垃圾回收器发现
- 如果一个对象为灰对象，它已经被垃圾回收器发现，但其邻接对象尚未全部处理
- 如果一个对象为黑对象，说明他步进被垃圾回收器发现，其邻接对象也全部被处理完毕了
Chrome V8的老生代使用标记清除和标记整理结合的方式，主要采用标记清除算法，如果空间不足以分配从新生代晋升过来的对象时，才使用标记整理
参考文章：