《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 占小狼 「占小狼」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

JDK 16已经发布,和往常一样,每个新发行版都具有许多新功能,增强功能和错误修复,其中 ZGC获得了46个增强功能和25个错误修复,最厉害的是把GC最大暂停时间控制在了1ms之内,牛逼!

图片

记得JDK11中第一次发布了ZGC,把GC最大展厅时间控制在了10ms之内,当时觉得不可思议,现在居然可以控制在1ms了。

图片

通过压测数据可以看出,相对比JDK15的ZGC,在16版本中,平均GC暂停时间约为0.05毫秒(50微秒),最大暂停时间约为0.5毫秒(500微秒),具有O(1) 暂停时间。换句话说,它们以几乎恒定的时间执行,并且不会随堆,活动集或根集大小(或与此相关的任何其他内容)的增加而增加。

那么,是怎么做到的?

在JDK 16之前,ZGC的暂停时间仍然根据gc root的大小进行缩放。更准确地说,仍然需要在“stop the world”阶段扫描线程堆栈,这意味着,如果Java应用具有大量线程,则暂停时间将增加,如果这些线程具有深层调用堆栈,则暂停时间将增加更多。

从JDK 16开始,线程堆栈的扫描和Java服务线程并发进行,这个过程不需要“stop the world”,具体怎么实现?想象一下,为了实现在Java线程运行期间,还能够被扫描到堆栈信息,这里就需要做些魔法,这个黑科技就是“Stack Watermark Barrier”。

简短来说,这是一种机制,可以防止Java线程在返回栈帧时而无需先检查这样做是否安全,而是直接放到 safe-point 安全点检查中,也可以看成是栈帧的load barrier,保证Java线程在返回栈帧之前采取某种操作,把栈帧带到一个安全状态(好让GC线程来扫描)。每个Java线程有一个或多个 stack watermarks,这些stack watermarks会告诉barrier,在堆栈中还可以安全执行多少次(无需任何特殊操作),如果执行的栈位置超过watermark,就会执行到一条slow path,并把一个或者多个栈帧放到安全状态。关键是,现在的实现不需要等所有Java线程都进入到safepoint安全点,再统一扫描了,在耗时方面也大大减少了。

过程有点复杂,文字看起来干巴巴,下次有图文了,再佛系分享,着急的同学可以先看下面这个JEP

JEP 376:ZGC:并行线程堆栈处理 http://openjdk.java.net/jeps/376

文章目录