ZGC 概述

Z Garbage Collector，也稱為ZGC，在 jdk 11 中引入的一種可擴(kuò)展的低延遲垃圾收集器，在 jdk 15 中發(fā)布穩(wěn)定版。在旨在滿足以下目標(biāo)：

• < 1ms 最大暫停時(shí)間(jdk < 16 是 10ms，jdk >=16 是 <1ms )。
• 暫停時(shí)間不會(huì)隨著堆、live-set 或 root-set 的大小而增加。
• 適用內(nèi)存大小從 8MB 到16TB 的堆。

ZGC 具有以下特征：

• 并發(fā)
• 基于 region
• 壓縮
• NUMA 感知
• 使用彩色指針
• 使用負(fù)載屏障

ZGC 的核心是一個(gè)并發(fā)垃圾收集器，這意味著所有繁重的工作都在Java 線程繼續(xù)執(zhí)行的同時(shí)完成。這極大地限制了垃圾收集對應(yīng)用程序響應(yīng)時(shí)間的影響。

ZGC 特征

ZGC 收集器是一款基于 Region 內(nèi)存布局的，(暫時(shí)) 不設(shè)分代的，使用了讀屏障、染色指針和內(nèi)存多重映射等技術(shù)來實(shí)現(xiàn)可并發(fā)的標(biāo)記-整理算法的，以低延遲為首要目標(biāo)的一款垃圾收集器。

內(nèi)存布局

ZGC 沒有分代的概念

ZGC 的內(nèi)存布局說起。與 Shenandoah 和 G1一樣，ZGC 也采用基于 Region 的堆內(nèi)存布局，但與它們不同的是 ， ZGC 的 Region 具 有 動(dòng) 態(tài) 性 (動(dòng)態(tài)創(chuàng)建和銷毀 ， 以及動(dòng)態(tài)的區(qū)域容量大小)。在 x64硬件平臺(tái)下 ， ZGC 的 Region 可以具有大、中、小三類容量(如下圖所示):

• 小型 Region (Small Region )：容量固定為 2M， 存放小于 256K 的對象。
• 中型 Region (Medium Region)：容量固定為 32M，放置大于等于256K但小于4M的對象。
• 大型 Region (Large Region): 容量不固定，可以動(dòng)態(tài)變化，但必須為2MB 的整數(shù)倍，用于放置 4MB或以上的大對象。

NUMA-aware

NUMA 對應(yīng)的有 NMA 、UMA 即 Uniform Memory Access Architecture， NUMA 就是 Non Uniform Memory Access Architecture. UMA 表示內(nèi)存只有一塊，所有的 CUU 都要去訪問這些內(nèi)存，那么會(huì)存在競爭問題(競爭內(nèi)存總線訪問權(quán))，有競爭就要去加鎖，有鎖效率就會(huì)受到影響，而且 CPU 核心數(shù)越多，競爭就越激烈。NUMA 的話每個(gè) CPU 對應(yīng)有一個(gè)內(nèi)存塊，且這塊內(nèi)存在主板上離這個(gè) CPU 是最近的，每個(gè) CPU 優(yōu)先訪問這塊內(nèi)存，那效率就自然提高了。

服務(wù)器的 NUMA 架構(gòu)在中大型系統(tǒng)上非常流行，也就是高性能的解決方案，尤其在系統(tǒng)延遲方面表現(xiàn)非常優(yōu)秀，ZGC 是能自動(dòng)感知 NUMA 架構(gòu)并且充分利用 NUMA 架構(gòu)的特征。

染色指針(Colored Pointer)

Colored Pointer， 即染色指針，如圖所示， ZGC 的核心設(shè)計(jì)之一。以前的垃圾收集器的 GC 信息都保存在對象頭中，而 ZGC 的 GC 信息保存在指針中(直接把標(biāo)記信息記錄在對象的引用指針上)。

每個(gè)對象有一個(gè)64位指針，這64位被分為：

• 18位：預(yù)留給以后使用。
• 1位：Finalizable標(biāo)識，此位與并發(fā)引用處理有關(guān)，它表示這個(gè)對象只能通過finalizer才能訪問(finalizer:object基類的一個(gè)空方法，如果被重寫則會(huì)在GC之前調(diào)用該方法，該方法會(huì)且只會(huì)被調(diào)用一次)。
• 1位：Remapped 標(biāo)識，設(shè)置此位的值后，對象未指向relocation set中(relocation set表示需要GC的Region集合)。
• 1位：Marked1標(biāo)識。
• 1位：Marked0標(biāo)識，和上面的Marked1都是標(biāo)記對象用于輔助GC。
• 42位：對象的地址(所以它可以支持2^42=4T內(nèi)存)：

為什么會(huì)有兩個(gè) mark 標(biāo)記?

每一個(gè)GC周期開始時(shí)，會(huì)交換使用的標(biāo)記位，使上次GC周期中修正的已標(biāo)記狀態(tài)失效，所有引用都變成未標(biāo)記。GC周期1：使用mark0, 則周期結(jié)束所有引用mark標(biāo)記都會(huì)成為 01。GC周期2：使用mark1, 與周期1相同，所有的mark標(biāo)記都會(huì)成為 10。

ZGC不能做指針壓縮?

指針壓縮指的是壓縮為32位，尋址位數(shù)不能超過35，也就是JVM內(nèi)存最大為32G(2^35=32GB)，這里的尋址位數(shù)已經(jīng)達(dá)到了42位。

顏色指針的三大優(yōu)勢 ?

1. 在一個(gè)Region中的所有存活對象都被移走后(復(fù)制走后)，這個(gè)Region就可以被立即釋放掉，因?yàn)樗€有轉(zhuǎn)發(fā)表記錄著原始地址和新地址，這樣的話，理論上，只要還有一個(gè)Region對象空閑，ZGC就能完成垃圾收集。
2. 顏色指針有指針的“自愈”(Self-Healing)能力，這樣子就減少了寫屏障(例如三色標(biāo)記中的增量更新或原始快照)，只需要一個(gè)讀屏障就可以解決問題，減少了內(nèi)存屏障的使用數(shù)量。
3. 顏色指針有著極大的擴(kuò)展性，因?yàn)檫€有18位未使用，這樣更有利于后續(xù)功能的擴(kuò)展。

多重映射尋址

不同的虛擬機(jī)內(nèi)存到物理內(nèi)存的轉(zhuǎn)換關(guān)系可以在硬件層面，操作系統(tǒng)層面或者軟件層面來實(shí)現(xiàn)。在 Linux 平臺(tái)上 ZGC 采用了多重映射(Mult-Mapping)將多個(gè)不同的虛擬內(nèi)存地址映射到同一個(gè)物理內(nèi)存地址上，著是一種多對一映射，一位著 ZGC 在虛擬內(nèi)中看到的地址空間要比時(shí)機(jī)的堆內(nèi)存容量來得更大。把染色指針中的標(biāo)志位看作是地址分段符，那只要將這些不同的地址分段符都映射到同一個(gè)福利內(nèi)空間，經(jīng)過多重映射轉(zhuǎn)換后，就可以直接使用染色指針進(jìn)行尋址了，如下圖所示：

多重映射技術(shù)確實(shí)可能帶來一些諸如復(fù)制大對象時(shí)會(huì)更容易這樣額外的好處，但是從源頭上來說，ZGC 的多重映射只是采用染色指針的衍生品，并不是為了專門的為實(shí)現(xiàn)其他某種特征需求而做的。

讀屏障

ZGC采用的讀屏障的方式來修正指針引用，由于ZGC采用的是復(fù)制整理的方式進(jìn)行GC，很有可能在對象的位置改變之后指針位置尚未更新時(shí)程序調(diào)用了該對象，那么此時(shí)在程序需要并行的獲取該對象的引用時(shí)，ZGC就會(huì)對該對象的指針進(jìn)行讀取，判斷Remapped標(biāo)識，如果標(biāo)識為該對象位于本次需要清理的region區(qū)中，該對象則會(huì)有內(nèi)存地址變化，會(huì)在指針中將新的引用地址替換原有對象的引用地址，然后再進(jìn)行返回。

如此，使用讀屏障便解決了并發(fā)GC的對象讀取問題。

Object o = obj.fieldA;    // Loading an object reference from heap
<load barrier needed here>
Object p = o;             // No barrier, not a load from heap
o.doSomething();          // No barrier, not a load from heap
int i = obj.fieldB;       // No barrier, not an object reference

LoadBarriers的存在，所以會(huì)導(dǎo)致配置ZGC的應(yīng)用的吞吐量會(huì)變低。官方的測試數(shù)據(jù)是需要多出額外4%的開銷：

ZGC 工作過程

ZGC 的運(yùn)作過程主要可以分為以下四個(gè)階段：

ZGC 處理過程.png

并發(fā)標(biāo)記(Concurrent Mark)：與G1、Shenandoah一樣，并發(fā)標(biāo)記是遍歷對象圖做可達(dá)性分析的 階段，前后也要經(jīng)過類似于G1、Shenandoah的初始標(biāo)記、最終標(biāo)記(盡管ZGC中的名字不叫這些)的短暫停頓，而且這些停頓階段所做的事情在目標(biāo)上也是相類似的。與G1、Shenandoah不同的是，ZGC的標(biāo)記是在指針上而不是在對象上進(jìn)行的，標(biāo)記階段會(huì)更新染色指針中的Marked 0、Marked 1標(biāo)志位。

并發(fā)預(yù)備重分配(Concurrent Prepare for Relocate)：這個(gè)階段需要根據(jù)特定的查詢條件統(tǒng)計(jì)得出本次收集過程要清理哪些Region，將這些Region組成重分配集(Relocation Set)。重分配集與G1收集器的回收集(Collection Set)還是有區(qū)別的，ZGC劃分Region的目的并非為了像G1那樣做收益優(yōu)先的增量回收。相反，ZGC每次回收都會(huì)掃描所有的Region，用范圍更大的掃描成本換取省去G1中記憶集的維護(hù)成本。因此，ZGC的重分配集只是決定了里面的存活對象會(huì)被重新復(fù)制到其他的Region中，里面 的Region會(huì)被釋放，而并不能說回收行為就只是針對這個(gè)集合里面的Region進(jìn)行，因?yàn)闃?biāo)記過程是針對全堆的。此外，在JDK 12的ZGC中開始支持的類卸載以及弱引用的處理，也是在這個(gè)階段中完成的。

并發(fā)重分配(Concurrent Relocate)：重分配是ZGC執(zhí)行過程中的核心階段，這個(gè)過程要把重分配集中的存活對象復(fù)制到新的Region上，并為重分配集中的每個(gè)Region維護(hù)一個(gè)轉(zhuǎn)發(fā)表(Forward Table)，記錄從舊對象到新對象的轉(zhuǎn)向關(guān)系。得益于染色指針的支持，ZGC收集器能僅從引用上就明確得知一個(gè)對象是否處于重分配集之中，如果用戶線程此時(shí)并發(fā)訪問了位于重分配集中的對象，這次訪問將會(huì)被預(yù)置的內(nèi)存屏障所截獲，然后立即根據(jù)Region上的轉(zhuǎn)發(fā)表記錄將訪問轉(zhuǎn)發(fā)到新復(fù)制的對象上，并同時(shí)修正更新該引用的值，使其直接指向新對象，ZGC將這種行為稱為指針的“自愈”(Self-Healing)能力。

這樣做的好處是只有第一次訪問舊對象會(huì)陷入轉(zhuǎn)發(fā)，也就是只慢一次，對比 Shenandoah 的 Brooks 轉(zhuǎn)發(fā)指針，那是每次對象訪問都必須付出的固定開銷，簡單地說就是每 次都慢，因此 ZGC 對用戶程序的運(yùn)行時(shí)負(fù)載要 Shenandoah 來得更低一些。還有另外一個(gè)直接的好處是由于染色指針的存在，一旦重分配集中某個(gè) Region 的存活對象都復(fù)制完畢后，這個(gè) Region 就可以立即釋放用于新對象的分配(但是轉(zhuǎn)發(fā)表還得留著不能釋放掉)，哪怕堆中還有很多指向這個(gè)對象的未更新指針也沒有關(guān)系，這些舊指針一旦被使用，它們都是可以自愈的。

并發(fā)重映射(Concurrent Remap)：重映射所做的就是修正整個(gè)堆中指向重分配集中舊對象的所有引用，這一點(diǎn)從目標(biāo)角度看是與 Shenandoah 并發(fā)引用更新階段一樣的，但是 ZGC 的并發(fā)重映射并不是一個(gè)必須要“迫切”去完成的任務(wù)，因?yàn)榍懊嬲f過，即使是舊引用，它也是可以自愈的，最多只是第一次使用時(shí)多一次轉(zhuǎn)發(fā)和修正操作。重映射清理這些舊引用的主要目的是為了不變慢(還有清理結(jié)束后可以釋放轉(zhuǎn)發(fā)表這樣的附帶收益)，所以說這并不是很“迫切”。因此，ZGC 很巧妙地把并發(fā)重映射階段要做的工作，合并到了下一次垃圾收集循環(huán)中的并發(fā)標(biāo)記階段里去完成，反正它們都是要遍歷所有對象的，這樣合并就節(jié)省了一次遍歷對象的開銷。一旦所有指針都被修正之后，原來記錄新舊對象關(guān)系的轉(zhuǎn)發(fā)表就可以釋放掉了。

ZGC 核心參數(shù)

ZGC 觸發(fā)時(shí)機(jī)

ZGC 中的幾種觸發(fā)GC場景：

• 定時(shí)觸發(fā)：默認(rèn)為不使用，可以通過 ZCollectionInterval 參數(shù)配置。GC 日志中的關(guān)鍵字 “Timer”。
• 預(yù)熱觸發(fā)：最多三次，在堆內(nèi)存空間達(dá)到 10%、20%、30% 時(shí)機(jī)觸發(fā)、主要是通過 GC 的時(shí)間、為其他的 GC 觸發(fā)準(zhǔn)備。GC日志關(guān)鍵字 “Warmup”。
• 分配速率：基于正態(tài)分布統(tǒng)計(jì)，計(jì)算內(nèi)存 99% 可能的最大分配速率，以及此速率下內(nèi)存將要耗盡的時(shí)間點(diǎn)，在耗盡之前觸發(fā) GC (耗盡時(shí)間，一次 GC 最大持續(xù)時(shí)間-一次 GC 檢測周期時(shí)間)。GC日志關(guān)鍵字 “Allocation Rate”。
• 主動(dòng)觸發(fā)：(默認(rèn)開啟，可以通過 ZProactictive 參數(shù)配置)距上一次 GC 堆內(nèi)存增長 10%，超過 5 分鐘時(shí)，對比上次 GC的間隔時(shí)間限(一次 GC 最大持續(xù)時(shí)間)，超過則觸發(fā)。GC 日志關(guān)鍵字 “Proactive”。
• 元數(shù)據(jù)分配觸發(fā)：元數(shù)據(jù)區(qū)不足導(dǎo)致，GC 日志關(guān)鍵中是 “Metadata GC Threshold”
• 直接觸發(fā)：代碼中顯示調(diào)用 System.gc() 觸發(fā)，GC 日志關(guān)鍵字是 “System.gc()”。
• 阻塞內(nèi)存分配請求觸發(fā)：垃圾對象來不及揮手，占滿整個(gè)堆空間，導(dǎo)致部分線程阻塞，GC 日志關(guān)鍵字是 “Allocation Stall”。

ZGC 日志分析

我們將對下面的一個(gè)簡單的程序做一個(gè) ZGC LOG 做一個(gè)分析，下面是具體的代碼和分析。

示例代碼

下面是一段簡單的代碼：

/**
 * VM Args：-XX:+UseZGC -Xmx8m -Xlog:gc*
 */
public class HeapOOM {

    public static void main(String[] args) {
        List<byte[]> list = new ArrayList<>();
        while (true) {
            list.add(new byte[2048]);
        }
    }
}

GC 日志分析

GC 日志如下(運(yùn)行環(huán)境 JDK 17)，舉個(gè)例子： GC 日志中每一行都標(biāo)注了對 GC 過程中的信息，關(guān)鍵信息如下：

• Start：開始GC，并標(biāo)明的GC觸發(fā)的原因。上圖中觸發(fā)原因是自適應(yīng)算法。
• Phase-Pause Mark Start：初始標(biāo)記，會(huì)STW。
• Phase-Pause Mark End：再次標(biāo)記，會(huì)STW。
• Phase-Pause Relocate Start：初始轉(zhuǎn)移，會(huì)STW。

Heap信息：記錄了GC過程中Mark、Relocate前后的堆大小變化狀況。High和Low記錄了其中的最大值和最小值，我們一般關(guān)注High中Used的值，如果達(dá)到100%，在GC過程中一定存在內(nèi)存分配不足的情況，需要調(diào)整GC的觸發(fā)時(shí)機(jī)，更早或者更快地進(jìn)行GC。

GC信息統(tǒng)計(jì)：可以定時(shí)的打印垃圾收集信息，觀察10秒內(nèi)、10分鐘內(nèi)、10個(gè)小時(shí)內(nèi)，從啟動(dòng)到現(xiàn)在的所有統(tǒng)計(jì)信息。利用這些統(tǒng)計(jì)信息，可以排查定位一些異常點(diǎn)。

ZGC 總結(jié)

本文主要是從概念上描述了 ZGC 的特征和工作過程。

目前大多數(shù)互聯(lián)網(wǎng)公司還是使用 jdk 8、jdk 11 主流使用的還是 ParNew + CMS 組合或者 G1。

對于我們一線 Java 開發(fā)者應(yīng)該具備新技術(shù)的學(xué)習(xí)熱情和關(guān)注度，才能在激烈的社會(huì)競爭中保持優(yōu)勢。

參考資料

• 深入理解 JVM 虛擬機(jī)第三版 周志明。
• https://wiki.openjdk.java.net/display/zgc/Main。
• http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2018.pdf。
• https://tech.meituan.com/2020/08/06/new-zgc-practice-in-meituan.html。