JDK 16优化ZGC 控制stw时间不超过10毫秒

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安全点，再统一扫描了，在耗时方面也大大减少了。

过程有点复杂，文字看起来干巴巴，下次有图文了，再佛系分享