总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《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

文章目录