作者：京东科技 康志兴

1 前言

随着 Java 的进化过程，涌现出各种不同的垃圾回收器，从串行执行到并行执行，从高吞吐到低延迟，终极目标就是让开发人员专注于程序的代码书写而无需关注内存管理。

JDK 早期出现的垃圾回收器通常单独作用于不同分代，到后期出现的 G1 开始，才可以进行全区域收集。

关于垃圾回收器的基础知识请翻看前一篇：从原理聊 JVM（一）：染色标记和垃圾回收算法

2 串行收集器（Serial）

比较老的收集器，单线程，所收集时必须暂停应用的工作线程，直到收集结束。但和其他收集器的单线程相比更加简单、高效。

作用于新生代的收集器叫Serial，采用标记复制算法；作用于年老代的收集器叫Serial Old，采用标记整理算法。

3 并行收集器（Parallel）

多条垃圾收集线程并行工作，在多核 CPU 下效率更高，但应用线程仍然处于等待状态。

并行收集器也分为ParNew和Parallel Old。可以理解为它们就是 Serial 和 Serial Old 的多线程并行版本，甚至部分代码进行了复用。

ParNew 较为流行的原因是因为除了 Serial 只有它能和 CMS 搭配使用。但自 JDK9 开始，由于更先进的 G1 的出现，官方直接取消了单独指定 ParNew 的参数-XX：+UseParNewGC，使其并入了 CMS 收集器，成为它专门处理新生代的组成部分。

而 Parallel Old 则搭配新生代收集器 ParallelScavenge 成为名副其实的“吞吐量优先”的搭配组合。

4 ParallelScavenge

ParallelScavenge 收集器是面向新生代的垃圾回收器，它和 ParNew 其实非常类似，使用标记复制算法并行收集。区别在于二者关注点不同，ParalletScavenge 的目标是达到一个可控制的吞吐量（Throughput），更高的吞吐量意味着最大限度的使用处理器的资源来缩短整体的垃圾回收时间。ParalletScavenge 有两个重要参数：

•-XX：MaxGCPauseMillis

收集器将尽力保证内存回收花费的时间不超过用户设定值。但这是以牺牲吞吐量为代价的，要求用更短的时间来完成垃圾收集，那么系统就需要降低新生代大小，新生代变小了自然垃圾回收会更加频繁，每次垃圾回收都有很多必要工作（比如等待所有线程到达安全点），那么更频繁的垃圾回收就导致了整体吞吐量的降低。

•-XX：GCTimeRatioGCTimeRatio

是垃圾收集时间占总时间的比率，换句话说：其表示运行用户代码时间是 GC 运行时间的 X 倍。比如默认为 99，则垃圾收集时间占比应该 1/(1+99)。这个数越低，运行用户代码时间占比越低。

ParallelScavenge 收集器还可以通过参数(-XX：+UseAdaptiveSizePolicy)来激活自适应调节策略。激活后，就不需要人工指定新生代的大小（Xmn）、Eden 与 Survivor 区的比例（XX：SurvivorRatio）、晋升年老代对象大小（XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

5 CMS 收集器（Concurrent Mark Sweep）

CMS 收集器是缩短暂停应用时间（Low Pause）为目标而设计的，最开始 CMS 仅仅是年老代收集器，后来将 ParNew 并入作为其年轻代收集器。

相较上述收集器，CMS 是第一个无需全程 STW 而允许部分阶段并发执行的收集器。

垃圾回收实际上主要是两个阶段：识别垃圾和回收垃圾，CMS 在这两个阶段分别做了努力来降低停顿：

•识别垃圾

CMS 将标记过程打散，并将主要的染色标记过程和用户线程同步进行，并通过增量更新方式解决了引用切换带来的漏标的问题。

•垃圾回收

CMS 采用清除算法，相比复制和整理，清除算法由于仅处理死亡对象所以不需要任何停顿。

CMS 运行步骤

具体来说，CMS 整个过程分为 4 个步骤：

1. 初始标记（Initial Mark）[STW]

初始标记只是标记一下 GC Roots 能直接关联到的对象，速度很快。

2. 并发标记（Concurrent Marking）

并发标记阶段是标记可回收对象。

3. 重新标记（Remark）[STW]

重新标记阶段则是为了修正并发标记期间因用户程序继续运作导致标记产生变动的那一部分对象的标记记录，这个阶段暂停时间比初始标记阶段稍长一点，但远比并发标记时间短。

CMS 用增量更新来做并发标记，也就是说并发标记过程中，如果某个已经标记为存活的对象增加了对非存活对象的引用，那么将其标记为灰色，然后在重新标记阶段将这一部分对象重新扫描。

4. 并发清除（Concurrent Sweep）

清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

优点

由于整个过程中消耗最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，CMS 收集器内存回收与用户一起并发执行的，大大减少了暂停时间。

缺点

1. 处理器资源敏感

垃圾回收的线程能够与用户线程同时执行，这样虽然不会导致 STW，但是由于分摊了处理器的计算资源从而导致应用程序变慢，降低了总吞吐量。

2. 内存敏感

当垃圾回收和用户线程在同步运行时产生的垃圾，由于已经过了标记阶段所以不会标记后清除，这部分垃圾只能等到下一次 GC 时才会被清除，这就是浮动垃圾问题。

而且由于垃圾回收和用户线程同步运行，所以不能等堆满了再 GC，而是需要预留一部分内存来保证 GC 过程中用户线程仍有可用内存。为了降低 GC 频率，只能等垃圾攒多一点再触发 GC，那么 GC 时可供用户线程使用的内存就不多了。

如果 GC 尚未结束用户线程分配内存失败，这个情况叫做“并发失败”，这时虚拟机会降级使用 Serial Old 来重新进行一次高吞吐的年老代收集，这样停顿时间就长了。

线上环境应根据实际情况来调整触发 GC 的内存使用阈值，该参数为：-XX：CMSInitiatingOccupancyFraction。

3. CMS 基于标记清除算法，所以内存碎片过多后，会频繁触发 Full GC，且不可避免。CMS 会在若干次触发后进行一次内存碎片的合并整理，内存整理过程涉及存活对象的移动，（在 Shenandoah 和 ZGC 出现前）无法并发。

6 G1 收集器（Garbage First）

G1 收集器相比上述垃圾回收器有了里程碑式的创新，它将堆内存划分多个大小相等的独立区域（Region），并且能建立“停顿时间模型”，使暂停时间可控，并尽量将-XX：MaxGCPauseMillis（默认 200ms）作为停顿目标。根据 Oracle 官网的描述，G1 是一个“软实时”的收集器，只是尽量保证在目标停顿时间内完成垃圾收集工作，但不能确保一定：

It is important to note that G1 is not a real-time collector. It meets the set pause time target with high probability but not absolute certainty.

能预测的原因是它能避免对整个堆进行全区收集，而是将整个堆分为若干个小的区域（Region），每个 Region 是单次垃圾回收的最小单元。在系统运行过程中，G1 跟踪各个 Region 里的垃圾堆积价值大小（所获得空间大小以及回收所需时间），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region，从而保证了再有限时间内获得更高的收集效率。这也是 Garbage First 名称的由来。

G1 的分代模型

G1 也分为年轻代和年老代，但不是固定划分，而是每个 Region 根据运行情况动态划分。

G1 还有一个特殊的区域叫 Humongous，G1 将超过了一个 Region 容量一半的大对象，都存放在 Humongous 区域中，如果对象超过了 Region 大小，则存放在 N 个连续的 Humongous Region 中。G1 的大多数行为都把 Humongous Region 作为老年代的一部分来进行看待。

TAMS（Top at mark start）

为了保证垃圾回收过程中的同时 Region 也能够被使用，G1 为每一个 Region 设计了两个名为 TAMS 的指针，分别是 Previous TAMS（PTAMS）、Next TAMS（NTAMS）。在并发标记阶段开始前，TAMS 指针指向 Region 内占用内存的边界。在并发标记阶段中，G1 默认指针之上的对象为存活对象不去进行标记，而对象分配时，用户线程直接在指针之上分配。这就保证了扫描行为和对象分配互不干扰。

G1 如何判定 Region 的“价值”

G1 运行期间会收集每个 Region 的价值信息，比如回收耗时、记忆集的脏卡数量等，通过计算得出每个 Region 回收的性价比。G1 的停顿预测模型就是通过这些信息，找出在用户预期时间内获得更高回收收益的 Region 组合。

Remembered Sets

G1 堆中的每一个 Region 都有一份Rememberd Set，也叫RSet，它的作用就是为每一个 Region 记录哪些 Region 对其含有引用。

RSet 的更新需要线程同步处理，由于对象引用变更非常频繁，如果同步写卡表消耗非常大，所以通常会把更新信息存入队列中再异步更新 RSet，这个队列就叫Dirty Card Queue。

G1 的垃圾回收过程

当 Eden 中无法分配对象时，触发 Young GC。

当年老代占比到达 45%时，等待下一次 Young GC 时进行并发标记。

并发标记结束后马上执行 Mixed GC。

当 Mixed GC 对内存的清理速度赶不上分配新对象的速度时触发 Full GC，G1 的 Full GC 将使用单线程（JDK11 后改为多线程）执行标记整理算法，所以耗时巨大。

G1 的 Young GC

触发时机

当 JVM 无法在 Eden 区分配对象时。

回收范围

Eden 区和 Survivor 区

运行过程（所有阶段均 STW）

1. 根扫描

将所有 Eden 区中的 GC Root 和 RSet 记录的外部引用作为扫描存活对象的入口。

2. 更新 RSet

通过 Dirty Card Queue 中的 card 更新 RSet，保证 RSet 能准确反应老年代对该 Region 是否存在引用。

3. 处理 RSet

将 Eden 区中被 RSet 指向的对象标记为存活对象。

4. 对象复制

判断存活对象的年龄，如果未达到“阈值”，则复制到一个 Surviver 区中，否则复制到 Old 区中。如果 Surviver 空间不够，则将部分对象直接复制到 Old 区中。

5. 处理引用

处理软引用、弱引用、虚引用等，最终清空全部 Eden 区。这时清理过的内存空间没有内存碎片。

G1 的 Mixed GC

触发时机

年老代占用空间超过整个堆的 45%（可通过参数-XX:InitiatingHeapOccupancyPercent进行设置）

事实上，并不会立刻触发，而且等待下一次 Young GC，同步进行初始标记步骤。

回收范围

被并发标记过的 Region，这些 Region 是 G1 通过价值测算动态选中的。

运行过程

1. 初始标记（Initial Marking）[STW]

标记 GC Roots 直接关联的对象，并修改 TAMS 指针的值。值得注意的是，这一阶段并不单独执行，而是在 Minor GC 时同步完成。所以实际上这个阶段没有额外停顿。

2. 并发标记（Concurrent Marking）

与用户线程并发执行，顺着 GC Root 递归标记。标记完成后，重新扫描 SATB 记录的有引用变动的对象。如果这时发现空的 Region 则直接将其清空。

3. 重新标记（Remark）[STW]

由于并发标记是并发执行，并发标记结束后，仍然存在少量的引用变动的对象，所以在这个阶段可以 STW 来处理这部分遗留的对象。并且开始计算所有 Region 的活跃度。

4. 清理（Clean Up）[STW]

根据用户期望的停顿时间来制定回收计划，选择全部是非存活对象的 Old 区和回收收益较高的 Region 加入回收集。清空记忆集。重置已经被清理的空的 Region（这一步是非 STW 的）。

5. 拷贝（Coping）[STW]

将回收集其中的存活对象复制到空的 Region 中，最后清空这些旧的 Region。

这个阶段的算法和 Young GC 完全一致，但默认分 8 次执行完成（可由参数-XX:G1MixedGCCountTarget 设置）。所以每次清理的回收集包括 Eden 区、Survivor 区和八分之一的 Old 区。低存活度（垃圾多）的 Region 清理的较快，所以会被 G1 优先回收。

混合回收并不一定要进行 8 次。有一个阈值-XX :G1HeapWastePercent(默认值为 10%)，意思是允许整个堆内存中有 10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于 10%，则不再进行混合回收。

优点

G1 相比较之前的垃圾回收器最大的变化是通过化整为零的思路，将堆分为若干个小的 Region 来减少 GC 的范围，从而达到“低延迟”的目的。

并且 G1 的垃圾回收过程采用标记复制的算法，避免了空间碎片化的问题。

缺点

1.内存占用较高，由于 G1 分区比 CMS 更多，每个 Region 都需要建立卡表。其中新生代对象变动频繁，又加大了卡表维护的成本。

2.G1 不仅需要通过写前屏障来更新卡表，还需要写后屏障来跟踪并发时的指针变化以实现快照搜索算法（SATB）。这样虽然相比增量更新算法能够减少并发标记和重新标记阶段的消耗，但是用户程序运行时的计算负载就高了。

3.G1 和 CMS 同样具有“并发回收”的能力，所以垃圾回收的速度如果跟不上用户创建新对象的速度，那么就会触发一个 Full GC 来获取更多内存。通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

最佳实践

1.不要设置年轻代大小年轻代大小应当由 G1 自行控制，设置为固定值将覆盖暂停时间目标

2.暂停时间目标不要过于严苛 G1 为了 Young GC 能够缩短时间需要减少 Eden 区的个数，那么 Young GC 就会更加频繁。Mixed GC 想要达到停顿目标就需要减少回收的垃圾数量，如果回收速度低于新对象分配速度将引起 Full GC。

3.CMS 和 G1 的选择目前在小内存应用上 CMS 的表现大概率仍然要会优于 G1，而在大内存应用上 G1 则大多能发挥其优势，这个优劣势的 Java 堆容量平衡点通常在 6GB 至 8GB 之间。

7 总结

在 GC 的选择上，同样是“没有银弹”，不同的收集器有着各自的特点和适用场景，即使是 Epsilon 也会在特定场合下发挥作用。我们应针对不同的业务特征和系统情况选择最合适的垃圾回收器，而不是一味求新。

参考：

1.《深入理解 Java 虚拟机》 by 周志明

2.Getting Started with the G1 Garbage Collector