Java長期支持版本Java11發(fā)布時(shí)推出了ZGC, 之后的Java12 -16均有ZGC的一些更新。然而Java17的新特性已經(jīng)敲定，確定沒有關(guān)于ZGC的相關(guān)更新，也從另一方面說明了至Java17 ZGC已經(jīng)比較穩(wěn)定，可以作為比較穩(wěn)定的GC垃圾回收器。相信未來ZGC必定會(huì)成為主流的Java垃圾回收期，那么盤一盤ZGC就是必然的了。

1 ZGC從何而來，有什么好處

1.1 ZGC 的命名

根據(jù)OpenJDK官方網(wǎng)站的說明ZGC其實(shí)并沒有什么特殊意義，就是一個(gè)名字而已。起初只是為了致敬ZFS 文件系統(tǒng)，表示ZGC與ZFS一樣都是革命性的，是一個(gè)跨時(shí)代的產(chǎn)品。更像是一種崇拜命名法。所以ZGC就是要做革命性的與以往的垃圾回收器性能上有很大提高的GC。

1.2ZGC的好處及特點(diǎn)

ZGC是一個(gè)低延遲的可擴(kuò)展GC，它有以下的目標(biāo)

1. 亞毫秒級(jí)別的時(shí)間延遲 (就是不超過1毫秒。)

   下圖是SPEC做出的測試對(duì)比，Java16中ZGC 已經(jīng)可做到亞毫秒級(jí)別的延遲了

2. 暫停時(shí)間不會(huì)隨著堆的大小、存活集、根集的大小的增加而增加

3. 支持8MB-16TB級(jí)別的堆大小

同時(shí)ZGC有如下標(biāo)簽：

• 并發(fā)
• 基于Region
• 堆壓縮
• 彩色指針 (對(duì)象使用64的指針，有44位表示對(duì)象內(nèi)存地址（如果是8TB ， 4TB堆內(nèi)存則會(huì)用到43,42位） ，其中有4位用于GC, 其余為備用 )，個(gè)別詳情請(qǐng)看 http://hg.openjdk.java.net/jdk/jdk/rev/24f6b0e413a0

• 負(fù)載屏障
• NUMA支持 （每個(gè)CPU單獨(dú)訪問一塊內(nèi)存）

2 ZGC如何使用及調(diào)優(yōu)

2.1 ZGC支持那些系統(tǒng)

直至Java17 ZGC基本支持所有的主流系統(tǒng)。

2.2 ZGC可用的調(diào)優(yōu)參數(shù)

盡管ZGC有比較大的改動(dòng)，但是它仍然可以使用絕大部分的GC參數(shù)。當(dāng)然它也有其特有的參數(shù)。

2.2.1 ZGC 通用的參數(shù)

-XX:MinHeapSize, -Xms 最小堆大小 (default = 8388608 = 8M)

-XX:InitialHeapSize, -Xms 初始化堆大小 (default = 134217728 = 128M )

-XX:MaxHeapSize, -Xmx 最大堆大小 (default = 2134900736 = 2036M)

-XX:SoftMaxHeapSize JVM堆的最大軟限制 (default = 2134900736 = 2036M)

-XX:ConcGCThreads 并發(fā)GC的線程數(shù)量（default -XX:+ConcGCThreads=1 )

-XX:ParallelGCThreads 設(shè)置垃圾回收時(shí)的并行GC線程數(shù)量 (default = 4 )

-XX:UseLargePages 使用大頁面內(nèi)存 (dafault false)

-XX:UseTransparentHugePages 使用Transparent大頁面內(nèi)存

-XX:UseNUMA 使用UNMA內(nèi)存分配，可以獲得更好的性能

-XX:SoftRefLRUPolicyMSPerMB 每MB的空閑內(nèi)存空間允許軟引用對(duì)象存活時(shí)間（default = 1000）

-XX:AllocateHeapAt = 堆分配參數(shù)，可以使用非DRAM 內(nèi)存，這個(gè)參數(shù)將指向文件系統(tǒng)的文件并使用內(nèi)存映射來達(dá)到在備用存儲(chǔ)設(shè)備上進(jìn)行堆分配。

2.2.2 ZGC 特有的參數(shù)

-XX:ZAllocationSpikeTolerance 修正系數(shù)，數(shù)值越大，越早觸發(fā)GC (default = 2.000000)

-XX:ZCollectionInterval ZGC發(fā)生的最小時(shí)間間隔 ，秒 (default = 0.000000)

-XX:ZFragmentationLimit relocation時(shí)，當(dāng)前region碎片化大于此值，則回收region (default = 25.000000) -XX:ZMarkStackSpaceLimit 指定為標(biāo)記堆棧分配的最大字節(jié)數(shù) (default = 8589934592 = 8096M)

-XX:ZProactive 是否啟用主動(dòng)回收 (default true)

-XX:ZUncommit 是否歸還不使用的內(nèi)存給OS(default true)

-XX:ZUncommitDelay 不再使用的內(nèi)存最多延遲多久會(huì)歸還給OS (default = 300 s)

2.2.3 ZGC的一些診斷參數(shù)

-XX:+UnlockDiagnosticVMOptions 使用診斷模式，下面的參數(shù)才會(huì)起作用

-XX:ZStatisticsInterval 指定統(tǒng)計(jì)數(shù)據(jù)輸出之間的時(shí)間間隔(秒)。

-XX:ZVerifyForwarding 檢驗(yàn)轉(zhuǎn)發(fā)表 -XX:ZVerifyMarking 檢驗(yàn)標(biāo)記集

-XX:ZVerifyObjects 檢驗(yàn)對(duì)象 -XX:ZVerifyRoots 檢驗(yàn)根節(jié)點(diǎn)

-XX:ZVerifyViews 檢驗(yàn)堆視圖訪問

2.3 啟用ZGC

-XX:+UseZGC 啟用ZGC

-XX:+UseZGC -Xmx-Xlog:gc

-XX:+UseZGC -Xmx-Xlog:gc* 可以打印更詳細(xì)的GC日志

2.4 可優(yōu)化參數(shù)詳解

2.4.1 堆參數(shù)的設(shè)置

ZGC比較重要的調(diào)優(yōu)參數(shù)是設(shè)置最大堆內(nèi)存(-Xmx).， ZGC設(shè)置一個(gè)最大堆內(nèi)存有兩個(gè)考量：1.堆可以容納程序的存活集 2.堆中要有足夠的空間允許GC運(yùn)行時(shí)分配.

然而多大內(nèi)存合適這就要根據(jù) 內(nèi)存使用情況以及GC頻率來確定。

2.4.2 并發(fā)GC線程數(shù)設(shè)置

另一個(gè)調(diào)優(yōu)參數(shù)就是并發(fā)GC線程數(shù)量的設(shè)置 (-XX:ConcGCThreads=) 。

一般情況下ZGC可以自動(dòng)選擇一個(gè)合適的值，但是也要根據(jù)程序的特點(diǎn)來修改。這個(gè)參數(shù)對(duì)GC使用CPU的時(shí)間影響比較大，如果數(shù)量太大的話，GC線程會(huì)占用過多的CPU時(shí)間，數(shù)量過少的話垃圾回收有會(huì)不及時(shí)。通常情況下如果程序的低延遲很重要，那么CPU使用率最好永遠(yuǎn)不要超過70%。

2.4.3 將不用的內(nèi)存返回給OS

默認(rèn)情況下，ZGC會(huì)將不使用的內(nèi)存還給OS。可以使用XX:-ZUncommit 取消這一功能。然而如果實(shí)際堆內(nèi)存比最小堆內(nèi)存都小的話，肯定不會(huì)將不使用的內(nèi)存返還給OS，另外最大堆內(nèi)存(-Xmx)和最小堆內(nèi)存 (-Xms) 的設(shè)置相等的話，也不會(huì)起作用。

另外可以設(shè)置延遲歸還對(duì)內(nèi)存的時(shí)間 -XX:ZUncommitDelay=

2.4.4 在Linux中開啟大頁支持

在Linux操作系統(tǒng)中，采用內(nèi)存映射來管理內(nèi)存，邏輯頁面映射到對(duì)應(yīng)的物理內(nèi)存，

使用大頁面這個(gè)參數(shù)在吞吐量，低延遲，啟動(dòng)時(shí)間方面都有很好的性能提升，可以說除了設(shè)置起來有點(diǎn)復(fù)雜之外，沒有任何的缺點(diǎn)。設(shè)置這個(gè)參數(shù)需要Root權(quán)限，所以默認(rèn)沒有開啟。

2.4.5 Linux中使用大透明頁

Linux下的大頁分為兩種標(biāo)準(zhǔn)，大頁（Huge Pages）和透明大頁（Transparent Huge Pages）。大頁是預(yù)分配的方式管理，透明大頁是動(dòng)態(tài)分配的方式。我們可以使用這個(gè)參數(shù)-XX:+UseTransparentHugePages 來使用 transparent huge pages .對(duì)延遲要求很高的程序而言，這個(gè)參數(shù)是不推薦使用的，它可能會(huì)造成不必要的延遲峰值。

2.4.6 配置NUMA的支持

NUMA（非一致性內(nèi)存訪問）是Intel為了解決SMP多CPU結(jié)構(gòu)中中線訪問方式中資源競爭和一致性問題引起的。ZGC支持NUMA，此特性是默認(rèn)開啟的，它可以自主判斷系統(tǒng)是否支持NUMA。如果在支持NUMA的機(jī)器上運(yùn)行，那么將有顯著的性能提升。

3 ZGC垃圾回收流程簡述

3.1 ZGC同G1類似，也將內(nèi)存分為Regions， 叫做ZPages。ZPages可以動(dòng)態(tài)的創(chuàng)建和銷毀，而且還可以動(dòng)態(tài)的變化大小，無論怎么變化均為2MB 的倍數(shù)。

ZGC的堆區(qū)可以分為Small(2MB) Medium(32MB) Large(N*2MB)等多個(gè)Heap Regions. 其中Medium和Large是連續(xù)分配的內(nèi)存。

ZGC的垃圾回收一般可以分為已下幾個(gè)步驟流程。

1. Pause Mark Start
   這個(gè)階段會(huì)有 STW ，主要對(duì)Root集進(jìn)行掃描，標(biāo)記Root集中存活對(duì)象，即標(biāo)記根可達(dá)對(duì)象。
2. Concurrent Mark/Remap
   并發(fā)標(biāo)記階段，根據(jù)上一步標(biāo)記的根對(duì)象去遍歷對(duì)象圖，并標(biāo)記存活對(duì)象，主要根據(jù)上一步的Root存活對(duì)象標(biāo)記其對(duì)象樹上的對(duì)象。
3. Pause Mark End
   標(biāo)記結(jié)束，此處有 STW ，算再標(biāo)記階段，由于之前標(biāo)記的時(shí)候程序也在運(yùn)行，此時(shí)會(huì)有對(duì)象引用的變更，此處會(huì)對(duì)那些變更引用的對(duì)象重新標(biāo)記一下。此時(shí)也會(huì)清理一些Root對(duì)象以及無效空間。
4. Concurrent Prepare for Relocate
   并發(fā)標(biāo)記Region及處理弱根對(duì)象 ，標(biāo)記需要整理的Region集合，并選擇下一步Relocation要用到的Region集合，也會(huì)處理不是強(qiáng)根的對(duì)象。
5. Pause Relocate Start
   開始Relocate，此處有 STW ，處理Root對(duì)象的指針，此時(shí)會(huì)將Roots的對(duì)象移動(dòng)到選好的Region集合中。
6. Concurrent Relocate
   并發(fā)Relocate，此時(shí)并發(fā)執(zhí)行，將存活對(duì)象移動(dòng)到上一步選好的新的Region集合中。然后就是清理被釋放的分區(qū)，等等工作。

可以看出來ZGC整體使用了標(biāo)記復(fù)制加整理的思想，不過ZGC可以根據(jù)當(dāng)前的內(nèi)存使用情況，選擇將存活對(duì)象整理到一個(gè)全新的空Region集合中或者某個(gè)存有對(duì)象的Region中。由于整個(gè)GC的流程中只有三處需要暫停，然而這三處的STW時(shí)間都是亞毫秒級(jí)別。整個(gè)GC的流程延遲總體會(huì)小于1ms。

總結(jié)

本片總體概括了介紹了比較成熟的ZGC，介紹了ZGC的一些重要調(diào)優(yōu)參數(shù)，講解了一下ZGC的垃圾回收流程。相信各位看官也有所收獲。目前ZGC的應(yīng)用比較少，但隨著Java17的正式推出，那么ZGC必然會(huì)逐漸成為主流GC。