小研究 - JVM 垃圾回收方式性能研究（二）

本文从几种JVM垃圾回收方式及原理出发，研究了在 SPEC jbb2015基准测试中不同垃圾回收方式对于JVM 性能的影响，并通过最终测试数据对比，给出了不同应用场景下如何选择垃圾回收策略的方法。

目录

3 几种垃圾回收器

3.1 串行回收器

3.2 并行回收器

3.3 CMS回收器

3.4 G1回收器

3.5 Z回收器

4 垃圾回收器性能比较

---

3 几种垃圾回收器

垃圾收集算法可以看作 Java 虚拟机内存回收的抽象策略，而垃圾收集器则是其内存回收的具体实现。Java 虚拟机中，垃圾回收器不只一种，在不同的应用场景下如何选择性能最佳的垃圾回收器 是需要有清楚认识的，下面介绍几种常见的垃圾回收器。

3.1 串行回收器

串行回收器是一种单线程垃圾回收器，在进行每次垃圾回收时，只有一个线程工作，Java 应用程序中的其他所有线程暂停，等待垃圾回收完成（“Stop-The-World”过程）。在实时性要求高的应用 场景下，往往会造成用户体验不佳。串行回收器在新生代中使用复制算法，老年代中使用标记压缩法。

3.2 并行回收器

并行回收器在串行回收器的基础上做了改进，它使用多个线程同时进行垃圾回收，可以有效减少垃圾回收所需的时间。新生代中使用复制算法，老年代使用标记压缩算法。并行回收器关注系统的吞吐量，可以通过 -XX:MaxGCPauseMills 和 -XX:GCTimeRatio 控制的垃圾回收最大停顿时间和吞吐量。但须指出的是，减少一次收集的最大停顿时间，就会同时减少系统吞吐量，增大系统吞吐量又可能会同时增加一次垃圾回收的最大停顿时间。

3.3 CMS回收器

CMS回收器使用标记清除算法，利用多线程并行回收，侧重于系统停顿时间。CMS工作时首先经过初始标记与并发标记来标记出需要回收的对象、通过预清理做清理前的准备及控制停顿时间、再经过重新标记修正并发标记的数据、最后进行并发清除，以及并发重置为下次回收做准备 。

3.4 G1回收器

G1 回收器可以视为 CMS 回收器的替代品，它使用了独特的分区算法，相比于之前介绍的垃圾回收器将堆内存划分为固定内存大小的年轻代、老代和永久代（JDK1.8 后被元空间取代），G1 回收器将堆分割成一组大小相等的区域，每个区域是一个连续的虚拟内存范围，某些区域被功能与年轻代老年代相同，但是它们没有固定的大小，这为内存使用提供了更大的灵活性。在进行垃圾回收时， G1 回收器可以只选择部分区域，且部分垃圾回收工作能与 Java 应 用程序并行，提高回收效率的同时相应降低停顿时间。G1 回收器虽然也使用标记清除法，但与 CMS 不同的是 G1 可以有效复制移动对象，消除了潜在的内存碎片问题。此外，G1 还允许用户自行设定所需的暂停时间。

3.5 Z回收器

ZGC 是从 JDK11 中引入的一种新的支持弹性伸缩的低延迟垃圾收集器，主要实现了三大目标：停顿时间不超过 10ms、停顿时间不随堆或实时设置的大小而增加、支持从 8MB 到 16TB 的堆内存。ZGC的一个核心设计原则是使用读屏障（load barrier）和着色指针 （colored pointer）。在 Java 中加载对象的行为会受到读屏障的影响，而着色指针具有供读屏障使用的信息，它使 ZGC 能够查找、标记、定位和重新映射对象，这有助于降低垃圾回收的开销并极大降低停顿时间，且对吞吐量影响最大不超过 15%。作为一个并发的垃圾收集器，ZGC 所有的工作都是在 Java 应用程序线程执行时完成的，这极大地减少了垃圾回收对应用程序响应时间的影响。而且 Z 回收器现在还处于持续开发阶段，后续的开发目标是达到垃圾回收停顿时间不超过 1ms。

4 垃圾回收器性能比较

SPEC jbb2015 测试模拟了一个典型的商业应用的三层架构环境 中的中间层工作，包含商业逻辑、对象操作等，目的是衡量服务器 Java 应用之性能。模型建立在一个全球型连锁超市的 IT 基础架构 之上，通过线上线下购物、库存管理、供应链管理、用户购买行为的数据挖掘等业务来评估整个系统的吞吐量及响应时间随着整个系统业务量不断增加时的性能表现。SPECjbb2015 支持多种测试运行配置、支持虚拟化以及云环境，使用户能够全面分析和解决可能 存在于包括硬件、操作系统、JVM 和应用程序层的性能瓶颈问题。

SPEC jbb2015 测试结果包含主要包含两个测试指标 Max-jOPS 和 Critical-jOPS。最大性能指标 Max-jOPS 是系统最大每秒钟处理的 Java 操作数，可以看做在业务响应不失败的情况下，服务器 的极限吞吐量，反映的是系统极限 Java 应用性能。关键性能指标 Critical-jOPS 是系统在 5 个关键 SLA（服务水平协议）10ms， 25ms，50ms，75ms 和 100ms 响应时间下平均每秒 Java 操作数。选择这些点是为了保证不同行业使用的响应时间目标的合理分布，可以看做衡量的是在响应时间有限的情况下的系统吞吐量。