ZGC：jdk11試驗性質的低延遲垃圾回收器

刷文章看到了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