本文从几种JVM垃圾回收方式及原理出发，研究了在 SPEC jbb2015基准测试中不同垃圾回收方式对于JVM 性能的影响，并通过最终测试数据对比，给出了不同应用场景下如何选择垃圾回收策略的方法。
目录
4 垃圾回收器性能比较
4.1 测试结果
5 结语
4 垃圾回收器性能比较
最大性能指标 Max-jOPS 是系统最大每秒钟处理的 Java 操作数，可以看做在业务响应不失败的情况下，服务器的极限吞吐量，反映的是系统极限 Java 应用性能。关键性能指标 Critical-jOPS 是系统在 5 个关键 SLA（服务水平协议）10ms， 25ms，50ms，75ms 和 100ms 响应时间下平均每秒 Java 操作数。
4.1 测试结果
测试环境选择使用四路服务器，配置 4 颗 Intel Xeon Platinum 8180 CPU，物理内存大小为 1536G，操作系统为 Red Hat Enterprise Linux 7.6，使用 JDK 版本为 Oracle Java SE 13.0.2。
在此环境下分别使用：
1、-XX:+UseSerialGC（串行回收器）
2、-XX:+UseParallelOldGC（并行回收器）
3、-XX:+ UseConcMarkSweepGC（CMS 回收器）
4、- XX:+UseG1GC（G1 回收器 ）
5、-XX:+UseZGC（ZGC）
运行 SPEC jbb2015 测试，并使用参数 -XX:+PrintGCDetails、-Xlog:gc. log 输出垃圾回收详细日志。
图 1 反映了几种垃圾回收器在 SPEC jbb2015 基准测试中的性能表现，可以看出在极限性能指标 Max-jOPS 上，并行回收器 ParallelOldGC 表现最好，这是由于 Max-jOPS 代表系统极限吞吐量 而并行回收器在所有垃圾回收器中最侧重于吞吐量，因此这一指标明显优于其他垃圾回收器。而在关键性能指标上，ZGC 的表现最好，证明在一些有特定响应时间要求的业务场景下，其综合性能最好。ZGC 由于低停顿时间的特性，每次垃圾回收停顿时间不会超 过 10ms，这要远远低于其他垃圾回收方式（见图 2）。一般来说，停顿时间的减少但带来的影响必然是吞吐量的降低，ZGC 垃圾回收处理工作都在与应用线程并发执行，同时也会不可避免地占用很多 CPU 并发工作导致吞吐量降低。但如果同时考虑低响应时间与吞吐量情况下，ZGC 吞吐量降低的程度在可接受的范围之内，但同时其停顿时间减少了一个量级，因此其综合性能表现更好。
图 2 展示了几种垃圾回收方式的平均停顿时间。
其中 ZGC 的停顿时间最短，看到 ZGC 虽然目标定位在停顿时间不超过 10ms，但在实际测试时 ZGC 平均停顿时间约为 2ms，要远远低于 10 毫秒的目标。串行回收器的停顿时间最长，几乎达到秒级，这是由于串行回收器回收时只有单线程，因此停顿的时间要远远高于其他垃圾回收器，因此在实际业务模型中性能很差。而并行回收器、G1 回收器平均停顿时间相差不大，都在 100ms 上下，CMS 回收器则平均在 200ms 左右。
5 结语
本文简述了几种常用的 JVM 垃圾回收方式及其原理，并利用业内权威的 Java 应用性能测试工具 SPEC jbb2015 测试了几种垃圾回收方式的实际性能。因为 SPEC jbb2015 测试模型则具有广泛 的代表性，所以对基于此项测试对垃圾回收的研究有助于开发者在实际应用中合理地对性能进行调优并解决性能问题。
根据SPECjbb2015测试结果来看，当侧重于追求最大吞吐量，如基于Java的后台计算型应用、事务处理时，并行垃圾回收器 ParallelOldGC 表现更好。如追求低停顿时间，快速响应如互联网应用、web 前端等时 ZGC 优势明显，或者也可以使用 G1 垃圾回收器配 合 -XX:MaxGCPauseMillis 参数来限制最大垃圾回收停顿时间。且 ZGC 所支持的超大内存也非常适合需要大量内存的应用程序，比如大数据应用程序。但由于实际业务性能考量标准不同，还需结合每种垃圾回收方式自身特点，合理进行选择。
