JDK 11 将引入低延迟 GC,大幅度缩短 GC 暂停时长 - 开源中国社区
JDK 11 将引入低延迟 GC,大幅度缩短 GC 暂停时长
h4cd 2018年07月10日

JDK 11 将引入低延迟 GC,大幅度缩短 GC 暂停时长

h4cd h4cd 发布于2018年07月10日 收藏 10

之前我们报导过 JDK 11 进入特性冻结阶段,今天来看看 JEP 333 为了大幅减少 GC 暂停时间的可伸缩低延迟垃圾回收器 ZGC(Scalable Low-Latency Garbage Collector )。


GC 一直以来是 Java 的主要优势之一,但是,当垃圾回收暂停时间过长时,会对应用程序的响应时间产生负面影响,而现代系统中可用的内存量不断增长,用户和应用开发人员希望 JVM 能够以高效的方式充分利用此内存,并且不要有过长的 GC 暂停时间。此次将新增的 ZGC 功能,能够消除或大幅缩短 GC 暂停的时间。

ZGC 有以下几个目标:

  • GC 暂停时间不应超过 10 ms

  • 处理堆的大小范围从相对较小(几百 M)到非常大(几 T)不等

  • 与使用 G1 相比,应用程序吞吐量减少不超过 15%

  • 为未来的 GC 功能和优化利用有色指针(colored pointers)和加载屏障(load barriers)奠定基础

  • 初始支持平台:Linux/x64

ZGC 是一个并发的、单代的、基于区域的、NUMA 感知的压缩收集器,Stop-the-world 阶段仅限于根扫描,因此 GC 暂停时间不会随堆或活动集(live set)的变大而增加。

ZGC 的核心设计原则/选择是将加载屏障与有色对象指针(colored oops)结合使用,这使得 ZGC 能够在 Java 应用程序线程运行时执行并发操作,例如对象重定向。从 Java 线程的角度来看,在 Java 对象中加载引用字段的行为受到加载屏障的影响。除了对象地址之外,colored oops 还包含加载屏障使用的信息,以确定在允许 Java 线程使用指针之前是否需要采取某些操作。例如,对象有可能已经被重定向,那么加载屏障将对此进行检测并采取适当的操作。

JEP 333 还展示了 ZGC 的性能等详细信息,访问 http://openjdk.java.net/jeps/333 查看。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:JDK 11 将引入低延迟 GC,大幅度缩短 GC 暂停时长
分享
评论(19)
精彩评论
11
通常一个项目要么重计算,要么重存储, 堆大小也可能差异巨大, 总有某些性能是关键, 而其它方面性能不重要的地方,
因此不能单纯说某个GC延迟高, 或者说某个GC吞吐量低就是缺陷,
无论是完全STW的Serial, 还是CMS, G1, ZGC, 都有各自的优缺点和适用领域, 它们不是竞争和替代的关系.
JVM有这些选择总是好的, 而其它语言的VM极少有这么多GC方案的选择, 也就没法跟JVM上的语言去竞争适用领域的广泛.
2
有了这种GC,那么客户端Java的优势就来了,服务器端不需要这种吞吐量低的GC
2

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?
哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991
2

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。
哪些地方需要进步?
1

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991

引用来自“snowfog”的评论

哎呦,这是哪年的事了,有些人总喜欢过去的东西.停留在以前,怪语言不好

引用来自“久永”的评论

说的就好像该“刮目相看”似的,而且还阴阳怪气的,不会好好说话吗?

引用来自“snowfog”的评论

学如逆水行舟,不进则退,IT行业日新月异,你还停留在6年前,别说话了好吗.

引用来自“久永”的评论

《论一个钢筋的自我修养》,请问,你从那里得出了我说的 mono 一直停留在六年前?请问,你不屑别人的进步,你自己进步了吗?六年前的 GC 水平,这两年 java 进步多少吗?
知道为啥 java 进步慢吗?就是因为一粉顶十黑,三式自信。
有缺点不能提,迷之自信,请问如何进步?
1. 你比较过现在.NET或者MONO GC 和Java的差距吗?
2. 看过6年前的帖子就说.NET或者MONO比Java好,有比过现在是什么情况吗?难道我提出此疑问就是迷之自信?难道我就认为了.NET比Java垃圾?
3. 我说你的帖子太老,你应该拿一篇最新的帖子来打我脸而不是跟我在这说一些废话.你难道不应该比较一下Java11的GC 和.NET,MONO的区别再说话?
4. 我没捧谁,也没黑谁,我只是讽刺了一下你的帖子太老(这难道不是应该的?毕竟你贴的这个帖子是6年前的,而且那个项目已经6年没动过了,最近的修改也是两年前的samples,这个项目太可怕了,统统就两个commit,我不知道怎么描述).好吧我只是说一下我看到现象与不理解,没说这个项目不好,省得你又说我杠精(好像你那个钢筋是错的,我这里提出一下疑问).
5. 对于二楼的疑问,你给出的答案是六年前,却没去看看新特性再去比比区别到底在哪,也没给出一个很好的链接.
6. 好吧,有太多需要说的了,就到这吧,发现你这人一点也不严谨.
7. 不想回了.
最新评论
0

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991
现在是8102年了,2012年已经是上古时期了。
0

引用来自“爽歪歪ES”的评论

有了这种GC,那么客户端Java的优势就来了,服务器端不需要这种吞吐量低的GC
没错,这种低延时gc比较适合客户端,不需要关心吞吐量,只需要关心响应速度
0

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991

引用来自“snowfog”的评论

哎呦,这是哪年的事了,有些人总喜欢过去的东西.停留在以前,怪语言不好

引用来自“久永”的评论

说的就好像该“刮目相看”似的,而且还阴阳怪气的,不会好好说话吗?

引用来自“snowfog”的评论

学如逆水行舟,不进则退,IT行业日新月异,你还停留在6年前,别说话了好吗.

引用来自“久永”的评论

《论一个钢筋的自我修养》,请问,你从那里得出了我说的 mono 一直停留在六年前?请问,你不屑别人的进步,你自己进步了吗?六年前的 GC 水平,这两年 java 进步多少吗?
知道为啥 java 进步慢吗?就是因为一粉顶十黑,三式自信。
有缺点不能提,迷之自信,请问如何进步?

引用来自“snowfog”的评论

1. 你比较过现在.NET或者MONO GC 和Java的差距吗?
2. 看过6年前的帖子就说.NET或者MONO比Java好,有比过现在是什么情况吗?难道我提出此疑问就是迷之自信?难道我就认为了.NET比Java垃圾?
3. 我说你的帖子太老,你应该拿一篇最新的帖子来打我脸而不是跟我在这说一些废话.你难道不应该比较一下Java11的GC 和.NET,MONO的区别再说话?
4. 我没捧谁,也没黑谁,我只是讽刺了一下你的帖子太老(这难道不是应该的?毕竟你贴的这个帖子是6年前的,而且那个项目已经6年没动过了,最近的修改也是两年前的samples,这个项目太可怕了,统统就两个commit,我不知道怎么描述).好吧我只是说一下我看到现象与不理解,没说这个项目不好,省得你又说我杠精(好像你那个钢筋是错的,我这里提出一下疑问).
5. 对于二楼的疑问,你给出的答案是六年前,却没去看看新特性再去比比区别到底在哪,也没给出一个很好的链接.
6. 好吧,有太多需要说的了,就到这吧,发现你这人一点也不严谨.
7. 不想回了.
如果6年前有比较数据,那么在没有新数据的情况下,这个不就是最值得信任数据吗?
还有,如果你说我的数据有错,那么不该你拿出最新数据打我脸吗?
为什么争论的是两个人,跑腿的只有我一个呢?
你朔到现在,除了我跑腿,你为自己的观点,跑过腿,出过数据吗?
到现在也只是一个“观点”吧?难道你自己的观点也要对方辩友帮你找论据?
还有,你反驳我,不该你找论据吗?类似“反驳一张嘴,说理跑断腿”?
1

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991

引用来自“snowfog”的评论

哎呦,这是哪年的事了,有些人总喜欢过去的东西.停留在以前,怪语言不好

引用来自“久永”的评论

说的就好像该“刮目相看”似的,而且还阴阳怪气的,不会好好说话吗?

引用来自“snowfog”的评论

学如逆水行舟,不进则退,IT行业日新月异,你还停留在6年前,别说话了好吗.

引用来自“久永”的评论

《论一个钢筋的自我修养》,请问,你从那里得出了我说的 mono 一直停留在六年前?请问,你不屑别人的进步,你自己进步了吗?六年前的 GC 水平,这两年 java 进步多少吗?
知道为啥 java 进步慢吗?就是因为一粉顶十黑,三式自信。
有缺点不能提,迷之自信,请问如何进步?
1. 你比较过现在.NET或者MONO GC 和Java的差距吗?
2. 看过6年前的帖子就说.NET或者MONO比Java好,有比过现在是什么情况吗?难道我提出此疑问就是迷之自信?难道我就认为了.NET比Java垃圾?
3. 我说你的帖子太老,你应该拿一篇最新的帖子来打我脸而不是跟我在这说一些废话.你难道不应该比较一下Java11的GC 和.NET,MONO的区别再说话?
4. 我没捧谁,也没黑谁,我只是讽刺了一下你的帖子太老(这难道不是应该的?毕竟你贴的这个帖子是6年前的,而且那个项目已经6年没动过了,最近的修改也是两年前的samples,这个项目太可怕了,统统就两个commit,我不知道怎么描述).好吧我只是说一下我看到现象与不理解,没说这个项目不好,省得你又说我杠精(好像你那个钢筋是错的,我这里提出一下疑问).
5. 对于二楼的疑问,你给出的答案是六年前,却没去看看新特性再去比比区别到底在哪,也没给出一个很好的链接.
6. 好吧,有太多需要说的了,就到这吧,发现你这人一点也不严谨.
7. 不想回了.
0

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991

引用来自“snowfog”的评论

哎呦,这是哪年的事了,有些人总喜欢过去的东西.停留在以前,怪语言不好

引用来自“久永”的评论

说的就好像该“刮目相看”似的,而且还阴阳怪气的,不会好好说话吗?

引用来自“snowfog”的评论

学如逆水行舟,不进则退,IT行业日新月异,你还停留在6年前,别说话了好吗.
《论一个钢筋的自我修养》,请问,你从那里得出了我说的 mono 一直停留在六年前?请问,你不屑别人的进步,你自己进步了吗?六年前的 GC 水平,这两年 java 进步多少吗?
知道为啥 java 进步慢吗?就是因为一粉顶十黑,三式自信。
有缺点不能提,迷之自信,请问如何进步?
0

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991

引用来自“snowfog”的评论

哎呦,这是哪年的事了,有些人总喜欢过去的东西.停留在以前,怪语言不好

引用来自“久永”的评论

说的就好像该“刮目相看”似的,而且还阴阳怪气的,不会好好说话吗?
学如逆水行舟,不进则退,IT行业日新月异,你还停留在6年前,别说话了好吗.
0

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991

引用来自“snowfog”的评论

哎呦,这是哪年的事了,有些人总喜欢过去的东西.停留在以前,怪语言不好
说的就好像该“刮目相看”似的,而且还阴阳怪气的,不会好好说话吗?
0

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?

引用来自“久永”的评论

哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991
哎呦,这是哪年的事了,有些人总喜欢过去的东西.停留在以前,怪语言不好
2
有了这种GC,那么客户端Java的优势就来了,服务器端不需要这种吞吐量低的GC
2

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。

引用来自“兮风古道”的评论

哪些地方需要进步?
哪些地方需要进步,我没水平指出来,但是差距又少,以我这个水平还能知道:
https://github.com/xamarin/XobotOS
帮你搜到了中文版本的介绍,你看看垃圾收集器的差距:
http://www.iteye.com/news/24991
0
没有银弹
2

引用来自“久永”的评论

相比 .Net 或者 mono 的收集器,还有很多有待进步。
哪些地方需要进步?
1

引用来自“young7”的评论

吞吐量和降低延迟时间是一对矛盾体,不能同时拥有,只能取舍。选择高吞吐还是低延迟要看场景要求
需要低延迟的时候,还是有点效果的
11
通常一个项目要么重计算,要么重存储, 堆大小也可能差异巨大, 总有某些性能是关键, 而其它方面性能不重要的地方,
因此不能单纯说某个GC延迟高, 或者说某个GC吞吐量低就是缺陷,
无论是完全STW的Serial, 还是CMS, G1, ZGC, 都有各自的优缺点和适用领域, 它们不是竞争和替代的关系.
JVM有这些选择总是好的, 而其它语言的VM极少有这么多GC方案的选择, 也就没法跟JVM上的语言去竞争适用领域的广泛.
0
:cold_sweat: 负载不大的应用表示用默认的ps反而更好使…
0
红帽开发的Shenandoah,和ZGC是竞争关系吧!
1
吞吐量和降低延迟时间是一对矛盾体,不能同时拥有,只能取舍。选择高吞吐还是低延迟要看场景要求
0
相比 .Net 或者 mono 的收集器,还有很多有待进步。
1
本来 G1 已经可以通过调节参数适应批量计算和实时响应的任务,但是对于实时响应方面做得还不够好,引出了 ZGC 方案。这个对于桌面软件和追求响应速度的服务帮助比较大。
不过因此降低大概 15% 的吞吐量,对于大量计算的任务不合适。
顶部