天下事有难易乎?为之,则难者亦易矣;不为,则易者亦难矣。

从 JDK 8 到 JDK 17,GC 性能大幅提升!!

itzoo 566次浏览 0个评论

点击“终码一生”,关注,置顶公众号

每日技术干货,第一时间送达!



JDK17 发布已经几个月了,其中不仅包含很多新语言功能,而且与旧版 JDK 相比,性能提升也非常明显。与之前 LTS 版本的 JDK 8 和 JDK 11 相比,JDK17 的性能提升尤为明显。此次性能的提升大部分来自 JVM 的新功能和优化,在本文中我们就来重点谈一谈垃圾收集的改进。


最近,我发表过一个演讲,重点介绍了自 JDK 8 以来 G1 中的新特性,本文将在此基础之上进一步扩展,以涵盖 Parallel GC 和 ZGC取得的进步。此外,我们还有第四个受支持的收集器:Serial GC,但没有包含在此次的比较之内。Serial 是一个稳定的收集器,开销很低,但本文涉及的基准测试需要高性能的 GC 才能正常工作。


 

1

服务于不同的目标

 

有时,选择使用哪个垃圾收集器并非一目了然。重要的是需要明白,为了做出正确的选择,首先你需要搞清楚你的主要目标是什么。常见的目标包括优化吞吐量、延迟和/或资源占用情况。最佳解决方案当然是针对上述所有目标进行优化,并在每种情况下获得最佳性能。收集器力求从各个方面进行优化,但它们必须根据不同的目标做出不同的权衡。


下面,快速介绍一下不同优化的含义:


  • 吞吐量:降低 GC 对可在指定时间内完成的事务总数的影响。

  • 延迟:降低 GC 对单个事务的影响。

  • 资源占用情况:降低GC 使用的额外资源。


不同的权衡并不意味着无法从所有方面优化收集器。在优化收集器时,很大一部分工作是确保尽可能有效地进行权衡。还有一种全面改进的好方法是,重新评估旧的设计决策,并提出更好的解决方案。另外,关注公号“终码一生”,回复关键词“资料”,获取视频教程和最新的面试资料


 

2

自 JDK 8 以来的进步

 

自 JDK 8 以来取得的进步,我们能够看到所有收集器在各个方面都有或多或少的改进。为了更好地展示 GC 的进步,下面的比较将使用标准化分数来比较各个收集器。在此次比较中,我使用了SPECjbb® 20151,堆大小设置为16GB。这是一个众所周知且非常稳定的基准测试,它的关注点不仅限于 GC 的性能,因此结果可以展示出整个 Java 平台的进步。这个基准测试有几种不同的模式,可以同时生成吞吐量指标和延迟指标。延迟指标是衡量响应时间限制下的吞吐量。


对于暂停时间比较,我在固定负载下运行了一个小时的基准测试。也就是说,所有收集器都承担了相同级别的负载。


最后请注意, ZGC 是 JDK 11(从 JDK15 正式投入使用)中引入的,因此我们只有两个 ZGC 数据点,而 G1 和 Parallel 有三个数据点。


图片

 

3

吞吐量



通过以上吞吐量指标,我们可以看到与旧版本相比,所有收集器都有了明显的进步,其中 ZGC 的提升最大。在此次测试中,G1 和 Parallel 的原始吞吐量更好,但增大了堆空间后,ZGC 弥补了这一差距。另外,关注公号“终码一生”,回复关键词“资料”,获取视频教程和最新的面试资料


当谈到这个指标时,我们应该注意,我们测量的不仅仅是 GC 的性能。Java 平台的其他部分,例如 JIT 编译器,对这些提升也有一定的帮助。


延迟



延迟的提升效果更明显。我们可以看到为缩短 GC 暂停时间所做的努力都得到了回报。当谈到这个指标时,我们应该明白实际上很多提升都是因为 GC 的改进。


对于这个指标,G1 的进步最大。从延迟的角度来看,ZGC 也有了很大的改进。该图中并没有展示出提升最大的部分,因为该基准测试测量的是应用程序的延迟。ZGC 能够将暂停时间降到最低,我们看到其他因素也影响到了延迟的测试结果。如果我们深入研究暂停时间的改进,就会发现 ZGC 发挥了重要的作用。



我们来看看原始数据(因为标准化的暂停时间有点奇怪),我们可以看到JDK 17 中的 ZGC 远低于目标:亚毫秒级的暂停时间。G1 的目标是在延迟和吞吐量之间保持平衡,远低于其默认的目标:200 毫秒的暂停时间。该图表还包括额外的一栏,用于快速显示不同收集器如何处理可扩展性。ZGC 的设计会保证暂停时间不随堆的大小而改变,我们可以清楚地看到当堆扩大到 128GB 时的情况。从暂停时间的角度来看,G1比Parallel 更善于处理更大的堆,因为它能够保证暂停时间满足特定目标。


 

4

资源占用



该图比较了三个不同收集器原生内存的使用峰值。由于从这个角度来看 Parallel 和 ZGC 都非常稳定,因此我们应该看一看原始数字。我们可以看到 G1 在这方面确实有所改进,主要原因是所有功能和增强功能都提高了记忆集管理的效率 。


即使其他收集器的开销并没有减少,但我们仍然应该记住,它们在其他方面有也有所改进,因此不必使用额外的内存。另外,关注公号“终码一生”,回复关键词“资料”,获取视频教程和最新的面试资料



5

升级


无论使用哪种收集器,与旧版本相比,JDK 17 的整体性能都有很大的提升。如果你正仍在使用 JDK 8 并计划升级,那么现在就可以重新评估打算使用的 GC。在 JDK 8 中,Parallel是默认设置,但在 JDK 9 中改为了 G1。从那以后,G1 的改进速度就超过了 Parallel,但在有些情况下可能 Parallel 仍然是最佳选择。而 ZGC(从 JDK 15 开始正式使用)的加入,成为了第三种高性能替代方案。


参考链接:kstefanj.github.io/2021/11/24/gc-progress-8-17.html


PS:防止找不到本篇文章,可以收藏点赞,方便翻阅查找哦。


往期推荐



SQL语句中 left join 后用 on 还是 where,区别大了!

桌面版 Linux 为什么干不过 Windows?Linus 现身说法..

面试官:toString()、String.valueOf、String 强转,有啥区别?

IntelliJ IDEA 2021.3 最终版正式发布,还是那么香!(末尾有惊喜)

每日开源 | 一款基于 SpringBoot+Vue 开发的分布式网盘系统

JetBrains:推出“新一代 IDE ”!VS Code 对手来了



ITZOO版权所有丨如未注明 , 均为原创丨转载请注明来自IT乐园 ->从 JDK 8 到 JDK 17,GC 性能大幅提升!!
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址