ZGC：jdk11试验性质的低延迟垃圾回收器

2019独角兽企业重金招聘Python工程师标准>>>

刷文章看到了ZGC的介绍，感觉很牛逼啊，大概又看了看文档，做下记录

指标

先看指标，128G的堆，复合模式下的性能，看GC停顿时间

ZGC
                avg: 1.091ms (+/-0.215ms)
    95th percentile: 1.380ms
    99th percentile: 1.512ms
  99.9th percentile: 1.663ms
 99.99th percentile: 1.681ms
                max: 1.681ms

G1
                avg: 156.806ms (+/-71.126ms)
    95th percentile: 316.672ms
    99th percentile: 428.095ms
  99.9th percentile: 543.846ms
 99.99th percentile: 543.846ms
                max: 543.846ms

吓人不，使用ZGC竟然可以稳定在2ms以内！

描述

看看为啥ZGC能这么快

At a glance, ZGC is a concurrent, single-generation, region-based, NUMA-aware, compacting collector. Stop-the-world phases are limited to root scanning, so GC pause times do not increase with the size of the heap or the live set.

前一句都是使用的技术，后一句是主要内容，stw仅限在根扫描的过程中，所以GC停顿时间并不随着堆的增大而上升。

回忆CMS回收的几个阶段

1. 初始标记，此阶段也是从GC ROOT进行可达性分析，stw
2. 并发标记，上一阶段标记的对象触发，所有可达的对象标记，由于是并发所以不会stw
3. 重标记，上一阶段由于是并发，在标记过程中会产生新对象，所以这次重新标记所有可达对象，stw
4. 并发清理

而ZGC通过技术手段把stw的情况控制在仅有一次，就是第一次的初始标记才会发生，这样也就不难理解为什么GC停顿时间不随着堆增大而上升了，再大我也是通过并发的时间去回收了

还有一点需要关注就是停顿时间的减少会不会造成吞吐量的上升？原文解释

• No more than 15% application throughput reduction compared to using G1

和G1相比，减少的吞吐量不会超过15%

关键技术

具体使用的什么手段做到只做一次根扫描就能实现垃圾回收呢

1. 有色指针（Colored Pointers）
2. 加载屏障（Load Barrier）

最主要的应该是这两个技术，可惜都没看懂，都开始整汇编代码了，要不然就是16TB的地址空间，超出我的理解范围了，以后再研究这两种技术吧，暂时先记录下

地址原文：http://openjdk.java.net/jeps/333

PPT：http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf

 

转载于:https://my.oschina.net/u/943305/blog/1838871