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

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

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

在您的既有IT基础设施上按需构建人工智能更高效>>>  

之前我们报导过 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% 的吞吐量,对于大量计算的任务不合适。
顶部