背景
纵观自 JDK8 以来取得的进步，我们发现所有收集器或多或少在各个方面都有改进。为了更好地显示进度，下面的比较使用标准化分数单独比较收集器，而不是查看原始分数。我一直在使用具有 16 GB 堆来比较收集器。这是一个众所周知且稳定的基准测试，不仅关注 GC 性能，因此结果也将显示整个 Java 平台的进步。基准测试有几种不同的模式，它会生成吞吐量指标和延迟指标。延迟指标衡量响应时间约束下的吞吐量。
JVM中GC的变化
- JDK9: 设置G1为JVM默认垃圾收集器
- JDK10：并行全垃圾回收器 G1，通过并行Full GC, 改善G1的延迟。目前对G1的full GC的实现采用了单线程-清除-压缩算法。JDK10开始使用并行化-清除-压缩算法。
- JDK11：推出ZGC新一代垃圾回收器（实验性）,目标是GC暂停时间不会超过10ms，既能处理几百兆的小堆，也能处理几个T的大堆。
- JDK14 ：删除CMS垃圾回收器;弃用 ParallelScavenge + SerialOld GC 的垃圾回收算法组合;将 zgc 垃圾回收器移植到 macOS 和 windows 平台
- JDk 15 : ZGC (JEP 377) 和Shenandoah (JEP 379) 不再是实验性功能。默认的 GC 仍然是G1。
- JDK16：增强ZGC，ZGC获得了 46个增强功能 和25个错误修复，控制stw时间不超过10毫秒
测试
为了比较暂停时间，固定负载下运行了一个小时的基准测试。这样一来，无论最终分数如何，所有GC都处于同一水平。
在查看得分表之前的最后一个注意事项。ZGC 是在 JDK 11 中引入的（从 JDK 15 开始就可以生产）所以我们只有两个数据点用于 ZGC，而 G1 和 Parallel 有三个。
吞吐量
查看吞吐量指标，我们发现与旧版本相比，所有收集器都有显着改进。ZGC是这方面进步最大的。G1 和 Parallel 在此设置中仍然具有更好的原始吞吐量，但扩大堆，ZGC 缩小了这一差距。
当谈到这个指标时，我们还应该记住，我们不仅仅是在衡量 GC 性能。Java 平台的其他部分，例如 JIT 编译器，也有助于这些改进。
延时
从延迟的角度来看，结果改善得更多。在这里，我们可以看到缩短 GC 暂停时间所付出的努力所带来的所有好处。当谈到这个指标时，很多改进实际上可以归因于 GC 中的改进。
暂停时间
在考虑这个指标时，G1 显示出最好的进步。ZGC 在延迟方面也有很大改进。最令人印象深刻的部分未在此图表中显示，因为基准测试正在测量应用程序延迟。ZGC 在保持短暂停方面做得非常好，以至于我们开始看到影响延迟分数的其他因素。相反，如果我们看看暂停时间是如何改进的，我们就会发现ZGC 正在进行一些非凡的工作。
在这里，我们查看原始数字（因为规范化暂停时间有点奇怪），正如我们所见，JDK 17 中的 ZGC 远低于其亚毫秒暂停时间的目标。G1 的目标是在延迟和吞吐量之间保持平衡，远低于其 200 毫秒的默认暂停时间目标。该图表还包括一个额外的条形图，用于快速显示不同的收集器如何处理可扩展性。ZGC 被设计成暂停时间不随堆大小变化，我们清楚地看到当堆扩大到 128 GB 时就是这种情况。从暂停时间的角度来看，G1 比 Parallel 更好地处理更大的堆，因为它具有保持暂停时间目标的逻辑。
内存资源
此图表比较了三种不同收集器的本机内存峰值开销。由于从这个角度来看 Parallel 和 ZGC 都相当稳定，因此在这里查看原始数据也更有意义。我们可以看到G1在这方面确实有所改进，主要原因是所有功能和增强功能都使记忆集管理更加高效。
即使其他收集器没有减少它们的开销，我们仍然应该记住它们在其他方面有所改进，而无需使用额外的内存。
总结
是时候升级了，无论您使用哪种收集器，与旧版本相比，JDK 17的整体性能都要好得多。如果您仍在使用 JDK 8 并计划升级，现在可能是重新评估使用哪个 GC的好时机。在JDK8中， Parallel是默认设置，但在 JDK 9 中已更改为 G1。从那时起，G1 的改进速度高于并行，但仍有一些用例认为并行是最佳选择。随着 ZGC 的引入（从 JDK 15 开始就可以生产），还有第三个高性能的替代方案可以放入等式中。
参考链接：
https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html#fn:spec