JDK 21：GC 不断改进，性能更上一层楼

随着 2023 年秋季发布的 JDK 21，现在有一个新的 LTS 版本可以进行基准测试并生成一些 GC 性能图表。JDK 21 和自 JDK 17 以来的其他版本提供了一系列值得注意的功能，如虚拟线程、用于switch 的模式匹配和分代 ZGC。让我们看看它的表现如何。

简介

当在不同的 JDK 版本之间进行性能比较时，很难确定哪些功能带来了某种性能提升。但很容易看出，自 JDK 8 以来，整个 Java 平台在性能上已经显著提升。在这篇文章中，我使用 SPECjbb® 20151 来展示性能的提升。这是一个众所周知的标准基准测试，非常适合展示对GC的改进。这主要是因为该基准测试提供了两个得分：

• max-jOPS ：原始吞吐量
• critical-jOPS ：在延迟约束下的吞吐量

GC 的改进将同时提高这两个得分，但对于受延迟约束的得分的改进更加与 GC 的改变密切相关。基本上，较短的暂停将获得更好的得分。对于原始吞吐量得分来说，JIT 和 Java 平台的其他部分的改进也起到了作用。

在基准测试时没有进行太多调优，但我设置了一个固定的堆大小为 16 GB，并启用了大页，并确保在运行基准测试之前将它们分页。我希望结果能够反映出即插即用的行为，但是像这样的配置可以获得公平一致的结果。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 视频教程：https://doc.iocoder.cn/video/

选择 GC

Oracle 支持 4 种不同的 GC，它们都有不同的用途。在这篇文章中，我不包括 Serial GC，因为它不适用于我使用的基准测试。Serial GC 的主要重点是低开销，主要适用于内存和 CPU 资源有限的用例。在这次比较中，我们将重点介绍以下 GC：

• G1 ：自JDK 9起的默认收集器，注重延迟和吞吐量之间的平衡
• Parallel ：以吞吐量为导向的收集器，可能会出现较长的最坏情况延迟
• Z ：超低延迟的替代方案，完全并发，暂停时间在毫秒级别以下

使用哪种 GC 取决于应用程序最关注的方面。每种 GC 都有最佳的替代方案，并且没有一种 GC 可以在所有用例中都表现最佳。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud
• 视频教程：https://doc.iocoder.cn/video/

进展

如果回顾 JDK 8 以来的进展，G1 和 Parallel 的改进在各个方面都是相当惊人的。这两个收集器在各个方面都有所改进。它们的暂停时间更短，使用的内存更少，吞吐量比以往任何时候都要好。ZGC 的时间没有那么长，并且在这篇文章中，我主要关注通过使 ZGC 成为分代收集器带来的改进。

本文中的图表分别比较了不同的收集器。主要原因是根据堆大小的配置，结果对于某个收集器更有利。通过这样做，我们可以关注所有 GC 的巨大进步，而不是试图给出最佳的 GC。

比较包括 JDK 8、JDK 17 和 JDK 21 的 G1 和 Parallel。对于 ZGC，我选择的三个数据点是 JDK 17、JDK 21 和 JDK 21 中的分代 ZGC。由于 JDK 17 是 ZGC 完全支持的第一个 LTS 版本，所以回顾更早的版本并没有太多意义。

吞吐量

就原始吞吐量性能而言，与 JDK 17 相比，自 JDK 17 以来的改进并不是很大，但仍有轻微增加。但是，在下面的图表中，有两件事情真正值得关注。首先，JDK 8 和最新 JDK 之间的显著差异对于G1和Parallel来说。从性能的角度来看，离开 JDK 8 从来没有比现在更有益。

第二个值得注意的是使用分代 ZGC 时看到了有 10% 的提升。ZGC 中的新分代支持使其能够更高效地回收内存，不需要考虑整个堆的每个 GC。其效果是在执行 GC 工作时消耗的 CPU 资源更少，这些资源可以用于应用程序，从而提高其性能。

延迟

对于延迟得分，情况基本上是一样的。G1 和 Parallel 在 JDK 8 和 JDK 17 之间取得了巨大的进展，但最佳结果仍然是在 JDK 21。值得注意的是，在 JDK 8 和 JDK 17 之间进行了超过 7 年的创新，而在 JDK 17 和 21 之间，只有两年。相比之下，较短的时间及 GC 的成熟，使得在这样大型基准测试中很看到显著的进展。

将分代引入 ZGC 仍然可以看到在分代 ZGC 和传统模式之间的显著差异，这非常好。值得注意的是，大部分的改进来自于吞吐量得分的提高。这两种 ZGC 模式之间的暂停时间差异不大，它们都远低于 1 毫秒。然而，当考虑最坏情况的延迟时，与传统模式相比，分代 ZGC 相比之下显得更好一些。

对于 G1 和 Parallel，暂停时间并没有发生大的变化。我们在G1上花费了更多时间，在这里，通过查看更高百分位的暂停，我们可以看到我们已经成功地减少了几毫秒的时间。

内存开销

最后一个图表比较了在固定负载下运行基准测试时的峰值本机内存开销。就这个角度来看，Parallel 非常稳定，我们没有花费任何时间来进一步优化它。另一方面，对于 G1，我们在过去的十年中已经成功地消除了许多低效性，并且在 JDK 20 中，我们将 G1 改为只需要一个标记位图而不是两个。由此节省下来的资源是显著的，在这个基准测试中，G1 现在是最节省内存的收集器。

对于分代 ZGC，我们可以清楚地看到为了在这个基准测试中获得更好的延迟和吞吐量而做出的权衡。代价是更高的本机内存消耗。为了有效地实现分代支持，我们需要跟踪从老年代到新生代的指针。这称为记忆集，并且它们占用内存。在处理多个代时，我们还需要一些其他元数据所需的内存。尽管如此，在大多数情况下，与传统 ZGC 相比，使用分代 ZGC 时总体内存消耗更低，因为它不需要处理给定工作负载所需的堆的大小。因此，额外的本机内存使用通常可以通过使用较小的堆来节省，并且仍然可以获得更好的整体性能。

升级并尝试分代 ZGC

就像上面看到的那样，与 JDK 8 相比，JDK 21 的性能显著提高。因此，如果你还在使用 JDK 8，应该开始考虑升级。在升级时，同时重新评估要使用的 GC 也是一个很好的时机。如果迁移到 JDK 21，我强烈建议尝试使用分代 ZGC。在 JDK 21 中， ZGC 有分代版本和传统模式都可用，要使用分代版本，需要指定下面两个选项：

-XX:+UseZGC -XX:+ZGenerational