視頻課：https://edu.51cto.com/sd/ea9bd
前言
ZGC是最近由Oracle爲OpenJDK開源的新垃圾收集器。它主要由Per Liden編寫。ZGC類似於Shenandoah或Azul的C4，專注於減少暫停時間的同時仍然壓縮堆 。
雖然我不會在這裏給出完整的介紹，但“壓縮堆”只是意味着將仍然存活的對象移動到堆的其他區域.這樣做有助於減少碎片，但通常這也意味着整個應用程序（包括其所有線程）需要暫停,這通常被稱爲Stop the world 。只有GC完成後，才能恢復應用程序。
在GC相關的文獻中，應用程序通常稱爲mutator ，因爲從GC的角度來看，應用程序會改變堆(mutates the heap)。根據堆的大小，這樣的暫停可能需要幾秒鐘，這對於交互式應用程序來說可能是難以接受的。
有幾種方法可以減少暫停時間：
GC可以在壓縮時使用多個線程（並行壓縮 parallel compaction）
壓縮工作也可以分爲多個暫停（增量壓縮 incremental compaction）
壓縮堆的同時不暫停應用程序，或者只是很短時間暫停（併發壓縮 concurrent compaction）
Go的GC就是完全不壓縮堆
1
2
3
4如前所述，ZGC會進行併發壓縮，這當然不是一個簡單的實現功能，因此我想描述一下這是如何工作的。爲什麼這很複雜？
你需要將對象複製到另一個內存地址，同時另一個線程仍然可以讀寫舊對象。
如果對象已經複製成功，那麼堆中仍有許多指向舊地址的引用需要更新到新地址。
雖然併發壓縮（concurrent compaction）似乎是上述方案中降低暫停時間的最佳解決方案，但肯定會涉及一些權衡。因此，如果您不關心暫停時間，那麼最好使用專注於吞吐量的GC。
GC屏障 (GC Barriers)
理解ZGC如何進行併發壓縮的關鍵是Load barrier (通常在GC文獻中稱爲Read barrier).這裏簡單介紹一下，詳細的描述請看下面的Load Barrier一節。
如果GC有讀取屏障（Load barrier），則在從堆讀取引用時，GC需要執行一些額外操作。在Java中,也就是像執行這樣的代碼Object xxx=obj.field時需要額外操作。
對於像obj.field = value這樣的操作，GC也可能需要寫入屏障(叫做Write Barrier或者Store Barrier)[譯註：在分代GC還有引用計數中會用到寫入屏障].
這兩個操作都比較特殊因爲它們在每次讀取或寫入堆時發生的。Load Barrier和Store Barrier的名稱有點令人困惑，但注意這個屏障與CPU的內存障礙是完全不同的兩個概念
堆中的讀取和寫入都非常常見，因此兩種GC屏障都需要非常高效，在常見情況下就是一些彙編代碼。Read barrier通常比Write Barrier大一個數量級（可能會因應用程序而異），因此Read Barrier對性能要求更高。
例如，分代GC通常只需要一個寫屏障，不需要讀屏障。ZGC則需要一個讀屏障但沒有寫屏障。對於併發壓縮，我沒有看到沒有讀取障礙的解決方案。
這裏需要注意：即使GC需要某種類型的屏障，只有在讀取或寫入堆中的引用時需要它們。讀取或寫入像int或double這樣的基本類型是不需要屏障的.
指針標記（Pointer tagging Or Colored Pointers ）
ZGC在堆引用中存儲額外的元數據 ，在x64上是64 bit（ZGC目前不支持compressed oops和 class pointers）。64位中的48位用做x64上的虛擬內存地址 。雖然確切地說只有47位，因爲第47位確定了位48-63的值（目前這些位都是0）。ZGC保留對象實際地址的前42位（在源代碼中稱爲偏移量 ）。42位地址理論上就會有4TB的堆大小限制。其餘的位用於這些標誌： finalizable ， remapped ， marked1和marked0 （保留一位用於將來使用）。如下圖所示:
| 6 4 4 4 4 4 0 3 7 6 5 2 1 0 ±------------------±±—±----------------------------------------------+ |
00000000 00000000 0 | 0 | 1111 | 11 11111111 11111111 11111111 11111111 11111111 | ±------------------±±—±----------------------------------------------+ |
|---|---|---|---|---|---|
| * 41-0 Object Offset (42-bits, 4TB address space) | |||||
| * 45-42 Metadata Bits (4-bits) 0001 = Marked0 | |||||
| 0010 = Marked1 | |||||
| 0100 = Remapped | |||||
| 1000 = Finalizable | |||||
| * 46-46 Unused (1-bit, always zero) | |||||
63-47 Fixed (17-bits, always zero)在堆引用中具有元數據信息使得解引用更加昂貴，因爲需要mask地址以獲得沒有元信息的真實地址。ZGC採用了一個很好的技巧來避免這種情況：
當從內存中讀取時，會設置marked0 , marked1或remapped中的一個。
在偏移x處分配頁面（allocating a page）時，ZGC將同一頁面映射到3個不同的地址 ：
for marked0 ：(0b0001 << 42) | x
for marked1 ： (0b0010 << 42) | x
for remapped ： (0b0100 << 42) | x
1
2
3因此，ZGC從地址4TB開始保留16TB的地址空間（但實際上並未使用所有這些內存）。如下圖：
±-------------------------------+ 0x0000140000000000 (20TB)
| Remapped View |
±-------------------------------+ 0x0000100000000000 (16TB)
| (Reserved, but unused) |
±-------------------------------+ 0x00000c0000000000 (12TB)
| Marked1 View |
±-------------------------------+ 0x0000080000000000 (8TB)
| Marked0 View |
±-------------------------------+ 0x0000040000000000 (4TB)
在任何時間點，只使用這三個視圖中的一個。調試時可以取消映射（unmapped）未使用的視圖來驗證正確性。
Pages & Physical & Virtual Memory
Shenandoah將堆分成大量同樣大小的區域 。除了不適合單個區域的大對象外，對象通常不會跨越多個區域。大對象被分配在多個連續區域中。我非常喜歡這種方法，因爲它非常簡單。
在這方面，ZGC與Shenandoah非常相似。在ZGC的說法中，區域稱爲頁面Pages 。
與Shenandoah的主要區別：ZGC中的頁面可以有不同的大小（但在x64上總是2MB的倍數）。
ZGC有3種不同的頁面類型： 小型 （2MB大小）， 中型 （32MB大小）和大型 （2MB的倍數）。
在小頁面中分配小對象（最大256KB大小），在中型頁面中分配中型對象（最多4MB）。大頁面中分配大於4MB的對象。大頁面只能存儲一個對象.小頁面或中間頁面可以分配多個。
有些令人困惑的是大頁面實際上可能小於中等頁面（例如，對於大小爲6MB的大對象）。
ZGC的另一個不錯的特性是，它還可以區分物理內存和虛擬內存。這背後的想法是通常有足夠的虛擬內存（ZGC總是4TB），而物理內存更稀缺。物理內存可以擴展到最大堆大小（使用-Xmx設置），因此這比4 TB的虛擬內存要小得多。在ZGC中分配特定大小的頁面意味着分配物理和虛擬內存。在ZGC中，物理內存不需要是連續的，虛擬內存空間是連續的。
爲什麼說這是一個不錯的屬性？
分配連續範圍的虛擬內存是很容易的，因爲我們通常有足夠的虛擬內存。但在物理內存中有3個大小爲2MB的空閒頁面的情況很普通，但是對於大型對象分配我們需要6MB的連續內存。有足夠的空閒物理內存，但不幸的是這個內存是不連續的。ZGC能夠將這些非連續的物理頁面映射到單個連續的虛擬內存空間。如果無法映射，我們就會耗盡內存（發生OOM）
標記和重新安置對象（Marking & Relocating objects）
垃圾回收主要分爲兩個階段：標記和重新安置（實際上不止這兩個階段，你可以查閱源碼）。
[譯註：重新安置（Relocating）指的是把對象從一個內存區域移到另外一個區域，重映射(Remapping)只的是把指向老的地址的引用更新到新的地址]
一次GC從標記階段開始，標記所有可到達的對象。在這個階段結束時，我們知道哪些對象仍然存活，哪些對象是垃圾。ZGC將此信息存儲在每個頁面的Live Map中。Live Map是一個位圖(bitmap) ，用於存儲給定索引處的對象是否可達和/或最終可達（對於具有finalize method的對象而言）。
在標記階段，應用程序線程中的load-barrier將未標記的引用推送到線程局部標記緩衝區。只要此緩衝區已滿，GC線程就可以獲得此緩衝區的所有權，並以遞歸方式遍歷此緩衝區中的所有可到達對象。在應用程序線程中標記只是將引用推送到緩衝區，GC線程負責遍歷對象圖並更新Live map.
標記階段結束後，ZGC要重新安置 Relocation set中的所有活動對象。
Relocation Set表示一組需要被回收的頁面（Pages)，例如那些垃圾最多的頁面。存活的對象由GC線程或應用程序線程通過讀取屏障（Load Barrier）重新安置（relocated）（也就是放到新的地址去）.ZGC爲Relocation set中的每個頁面分配Forwarding table.
Forwarding table基本上是一個hash map，它存儲一個對象已被重新安置到的地址（如果該對象已經被重新安置）。
ZGC方法的優點是我們只需要爲relocation set中的頁面分配forwarding table的空間.
相比之下，Shenandoah將轉發指針存儲在每個對象本身，這樣就誰有一些額外的內存開銷。
GC線程遍歷 Relocation set中的存活對象，並重新安置（relocate）尚未重新安置的對象。這時可能發生應用程序線程和GC線程同時重新安置（relocate）同一個對象，在這種情況下，誰先relocate誰獲勝，ZGC使用原子CAS操作來確定勝者。
當不處於marking階段時，load-barrier會重新安置(relocates )/重新映射(remaps )從堆加載的所有引用。這確保了mutator看到的每個新引用都已指向對象的最新副本。重新映射（remaps）對象就是在forwarding table中查找新的對象地址。
一旦GC線程完成了relocation set的處理，重新安置階段就完成了。雖然這意味着所有對象都已重新安置，但通常仍會有引用指向relocation set，需要將其重新映射（remapped ）到新地址。這些引用會被Load-Barrier自我修復。如果對於這些引用的讀取發生的不夠快，（也就是這段時間內，應用程序沒有讀到這些指向relocation set的引用），這些引用會在下一次mark階段給修復。這意味着標記階段還需要檢查 forward table以重新映射(remap) （但不重新安置 ，所有對象之前階段都保證被重新安置）對象到它們的新地址。
這也解釋了爲什麼對象引用中有兩個標記位（marked0 和marked1 ）。標記階段在標記的marked0和marked1位之間交替。在重新安置階段之後，仍可能存在未重定向（remapped）的引用，所以我們需要知道上一個gc週期的情況。如果新的標記階段使用相同的標記位，則Load-Barrier就知道該引用爲已標記。
(譯註：這裏看起來像是GC週期remap和mark可以重疊，實際上確實是重疊的。如圖所示：
gc phase
更詳細的信息可以看這個Slide)
Load-Barrier
從堆中讀取引用時，ZGC需要一個所謂的load-barrier（也稱爲read-barrier）。每次Java程序訪問對象類型的字段時，我們都需要插入此load-barrier，例如obj.field 。訪問某些其他原始類型的字段不需要屏障，例如obj.anInt或obj.anDouble 。ZGC不需要obj.field = someValue存儲/寫入障礙。
根據GC當前所處的階段（存儲在全局變量ZGlobalPhase中 ），如果尚未標記或重新安置對象，則屏障會標記對象或重新安置它
全局變量ZAddressGoodMask和ZAddressBadMask
存儲對應的掩碼，該掩碼確定引用是否已被認爲是好的（這意味着已經標記或重新映射/重新安置remapped/relocated）或者是否仍然需要一些操作。這些變量僅在標記開始階段和重新安置階段同時改變.ZGC源代碼中的這個表格可以很好地概述這些掩碼的狀態：
GoodMask BadMask WeakGoodMask WeakBadMask
--------------------------------------------------------------
1
2Marked0 001 110 101 010
Marked1 010 101 110 001
Remapped 100 011 100 011
屏障的彙編代碼可以在MacroAssembler for x64中看到，我只會爲這個屏障顯示一些僞彙編代碼：
mov rax, [r10 + some_field_offset]
test rax, [address of ZAddressBadMask]
jnz load_barrier_mark_or_relocate
otherwise reference in rax is considered good
第一個彙編指令從堆讀取引用： r10存儲對象引用， some_field_offset是一些字段偏移常量。加載的引用存儲在rax寄存器中。
然後針對當前的壞掩碼測試該引用（這只是一個位與）。此處不需要同步，因爲ZAddressBadMask僅在STW時才更新。如果結果不爲零，我們需要執行屏障。
屏障需要根據我們當前所處的GC階段標記或重新安置對象。在此操作之後， 他需要更新存儲在r10 + some_field_offset中的引用來指向新引用。這步操作是必要的，以便來該字段的後續加載返回正確的引用。
由於我們可能需要更新引用地址，因此我們需要使用兩個寄存器r10和rax作爲加載的引用和對象地址。正確的引用也需要存儲到寄存器rax中 ，這樣在後面的執行過程中我們就已經加載了正確的引用。
由於每個引用都需要標記或重新安置，因此在開始標記或重新安置階段後，吞吐量可能會立即降低。當大多數引用被修復時，這應該會變得更快。
Stop-the-World 停頓
ZGC並沒有徹底擺脫STW。收集器在開始標記,結束標記和開始重新安置時需要暫停。但這種暫停通常很短,只有幾毫秒。
當開始標記時，ZGC遍歷所有線程堆棧以標記root set。root set是遍歷對象圖的開始的地方。root set通常由本地和全局變量組成，但也包括其他內部VM結構（例如JNI句柄）。
結束標記階段時需要再次暫停。在此暫停中，GC需要清空並遍歷所有線程局部標記緩衝區。由於GC可能會發現一個未標記的大型子圖，因此可能需要更長時間。ZGC試圖通過在1毫秒後停止標記階段的結束來避免這種情況。它返回到併發標記階段，直到遍歷整個對象圖，然後可以再次開始結束標記階段
啓動重新安置階段會再次暫停應用程序。此階段與開始標記非常相似，不同之處在於此階段重新安置Root Set中的對象。
zgc是一款可拓展的低時延，爲實現以下幾個目標而誕生的垃圾回收器：
停頓時間不超過10ms
停頓時間不會因堆變大而變長
堆大小範圍可支持幾G到幾T
1
2
3再看一下zgc的標籤：
region-based (和G1一樣)
NUMA-aware
Concurrent
Compacting
Using load barriers(讓一個CPU處理單元中的內存狀態對其它處理單元可見的一項技術，java的volatile底層使用的就是load barrier)
Using colored pointers()
1
2
3
4
5
6zgc介紹-by hotspot garbage collector team:https://archive.fosdem.org/2018/schedule/event/zgc/attachments/slides/2211/export/events/attachments/zgc/slides/2211/ZGC_FOSDEM_2018.pdf
一、zgc在jdk各個版本的changelog：
JDK 13 (Released September 2019)
Increased max heap size from 4TB to 16TB
Support for uncommitting unused memory (JEP 351)
Support for -XX:SoftMaxHeapSIze
Support for the Linux/AArch64 platform
Reduced Time-To-Safepoint
1
2
3
4
5JDK 12 (Released March 2019)
Support for concurrent class unloading
Further pause time reductions
1
2JDK 11 (Released September 2018)
Initial version of ZGC
Does not support class unloading (using -XX:+ClassUnloading has no effect)
1
2二、ZGC相關VM Options
General GC Options ZGC Options ZGC Dianostic Options （-XX:+UnlockDianosticVMOptions）
-XX:MinHeapSize, -Xms
-XX:InitialHeapSize, -Xms
-XX:MaxHeapSize, -Xmx
-XX:SoftMaxHeapSize
-XX:SoftRefLRUPolicyMSPerMB
-XX:ZAllocationSpikeTolerance
-XX:ZCollectionInterval
-XX:ZFragmentationLimit
-XX:ZMarkStackSpaceLimit
-XX:ZPath
-XX:ZUncommit
-XX:ZUncommitDelay
-XX:ZProactive
-XX:ZStatisticsForceTrace
-XX:ZStatisticsInterval
-XX:ZVerifyForwarding
-XX:ZVerifyMarking
-XX:ZVerifyObjects
-XX:ZVerifyRoots
-XX:ZVerifyViews
1、激活ZGC
-XX:+UnlockExperimentalVMOptions -XX:+UseZGC
2、設置堆大小，堆
-Xmx
3、併發線程數，併發線程數太多會導致佔用太多cpu時間分片，太少會導致回收速度跟不上垃圾生產速度。如果系統追求的是低時延，儘量不要讓系統超負荷工作，cpu使用率儘量控制在70%以下
-XX:ConcGCThreads=
4、return unused memery to os
這裏指的是設置了xms和xmx且xmx>xms的情況，zgc默認會返回未使用的內存給操作系統，對於內存水位是重要指標的系統，返回未使用內存可以更好的觀察內存使用情況。但如果要禁用這個功能，可以使用：-XX:-ZUncommit 。但無論使用哪種策略，jvm不會uncommit unsed memery導致堆大小小於xms。這也意味着如果配置xms=xmx，該特性會被隱式禁用
5、Enable Large Pages
啓用方式：-XX:+UseLargePages
Large Pages在Linux稱爲Huge Pages，配置zgc使用Huge Pages可以獲得更好的性能（吞吐量、延遲、啓動時間），並且基本沒有缺點，除了配置稍微複雜一點。配置Huge Pages大小，需要注意JVM除了堆以外其他需要使用到的內存也得算進去，具體配置方法如下，就不翻譯了：
6、 Enable Transparent Huge Page(THP)
一般不建議在對延時敏感的系統下使用，THP一個使管理Huge Pages自動化的抽象層。
7、Enable NUMA Support
zgc默認開啓NUMA支持，意味着在分配堆內存時，會盡量使用NUMA-local的內存（比跨die訪問快3倍）。但當jvm發現程序使用的只是cpu的一個子集（限定使用），則會自動禁用該特性。一般不需要關注這個特性，如果需要指定，可以通過以下參數指定
-XX:+/-UseNUMA
8、Enable GC logging