垃圾收集器必問系列—ZGC

本文已收錄至Github，推薦閱讀 ?? Java隨想錄

微信公眾號：Java隨想錄

CSDN： 碼農BookSea

人的一切痛苦，本質上都是對自己的無能的憤怒，——王小波

• Region布局
• 讀屏障
• 染色指標
  • 染色指標的優勢
• 運作程序
• ZGC的優缺點

ZGC有人稱它為Zero GC，其實“Z”并非什么專業名詞的縮寫，這款收集器的名字就叫作Z Garbage Collector，根據OpenJDK官方網站的說明ZGC其實并沒有什么特殊意義，就是一個名字而已，起初只是為了致敬ZFS 檔案系統，表示ZGC與ZFS一樣都是革命性的，是一個跨時代的產品，更像是一種崇拜命名法，所以ZGC就是要做革命性的與以往的垃圾回收器性能上有很大提高的GC，

ZGC的目標是希望在盡可能對吞吐量影響不太大的前提下 ，實作在任意堆記憶體大小下都可以把垃圾收集的停頓時間限制在十毫秒以內的低延遲，

在ZGC演算法中，并沒有分代的概念，所以就不存在Young GC、Old GC，所有的GC行為都是Full GC，

Region布局

先從ZGC的記憶體布局說起，和G1一樣，ZGC也采用基于Region的堆記憶體布局，但與G1不同的是，ZGC的Region具有動態性——動態創建和銷毀，以及動態的區域容量大小，在x64硬體平臺下，ZGC的Region可以有小、中、大、三類容量：

• 小型Region（Small Region）：容量固定為2MB，用于放置小于256KB的小物件，
• 中型Region（Medium Region）：容量固定為32MB，用于放置大于等于256KB但小于4MB的物件，
• 大型Region（Large Region）：容量不固定，可以動態變化，但必須為2MB的整數倍，用于放置4MB或以上的大物件，每個大型Region中只會存放一個大物件，這也預示著雖然名字叫作“大型Region”，但它的實際容量完全有可能小于中型Region，最小容量可低至4MB，大型Region在ZGC的實作中是不會被重分配的，因為復制一個大物件的代價非常高昂，

讀屏障

之前的GC都是采用寫屏障（Write Barrier），而ZGC采用的是讀屏障，讀屏障（Load Barriers）類似于 Spring AOP 的前置通知，在ZGC中，當讀取處于重分配集的物件時，會被讀屏障攔截，通過轉發表記錄將訪問轉發到新復制的物件上，并同時修正更新該參考的值，使其直接指向新物件，ZGC將這種行為叫做指標的“自愈能力”，這樣就算GC把物件移動了，讀屏障也會發現并修正指標，于是應用代碼就永遠都會持有更新后的有效指標，而且不需要STW，類似JDK里的CAS自旋，讀取的值發現已經失效了，需要重新讀取，

好處是：第一次訪問舊物件訪問會變慢，但也只會有一次變慢，當“自愈”完成后，后續訪問就不會變慢了，

正是因為Load Barriers的存在，所以會導致配置ZGC的應用的吞吐量會變低，不過這點開銷是值得的，

染色指標

ZGC收集器有一個標志性的設計是它采用的染色指標技術，

ZGC 出現之前， GC 資訊保存在物件頭的 Mark Word 中，如物件的哈希碼、分代年齡、鎖記錄等就是這樣存盤的，

追蹤式收集演算法的標記階段就可能存在只跟指標打交道而不必涉及指標所參考的物件本身的場景，例如物件標記的程序中需要給物件打上三色標記，這些標記本質上就只和物件的參考有關，而與物件本身無關、ZGC的染色指標將這些資訊直接標記在參考物件的指標上，

染色指標是一種直接將少量額外的資訊存盤在指標上的技術，Linux下64位指標的高18位不能用來尋址，ZGC的染色指標技術盯上了這剩下的46位指標寬度，將其高4位提取出來存盤四個標志資訊，當然，由于這些標志位進一步壓縮了原本就只有46位的地址空間，也直接導致ZGC能夠管理的記憶體不可以超過4TB（2的42次冪）

JVM 可以從指標上直接看到物件的三色標記狀態（Marked0、Marked1）、是否進入了重分配集（Remapped）、是否需要通過 finalize 方法來訪問到（Finalizable），

18位：預留給以后使用；
1位：Finalizable標識，此位與并發參考處理有關，它表示這個物件只能通過finalizer才能訪問；
1位：Remapped標識，設定此位的值后，物件未指向relocation set中（relocation set表示需要GC的Region集合）；
1位：Marked1標識；
1位：Marked0標識，和上面的Marked1都是標記物件用于輔助GC；
42位：物件的地址（所以它可以支持2^42=4T記憶體）；

染色指標的優勢

染色指標主要有三大優勢：

• 染色指標可以使得一旦某個Region的存活物件被移走之后，這個Region立即就能夠被釋放和重用掉，而不必等待整個堆中所有指向該Region的參考都被修正后才能清理，理論上只要還有一個空閑Region，ZGC就能完成收集，
• 染色指標可以大幅減少在垃圾收集程序中記憶體屏障的使用數量，ZGC只使用了讀屏障，因為資訊直接維護在指標中，
• 染色指標可以作為一種可擴展的存盤結構用來記錄更多與物件標記、重定位程序相關的資料，以便日后進一步提高性能，如果開發了前18位指標，既可以騰出已用的4個標志位，將ZGC可支持的最大堆記憶體從4TB拓展到64TB，也可以利用其余位置再存盤更多的標志，譬如存盤一些追蹤資訊來讓垃圾收集器在移動物件時能將低頻次使用的物件移動到不常訪問的記憶體區域，

運作程序

ZGC的運作程序大致可劃分為以下四個大的階段，全部四個階段都是可以并發執行的，僅是兩個階段中間會存在短暫的停頓小階段，這些小階段，譬如初始化GC Root直接關聯物件的Mark Start，ZGC的運作程序具體如圖所示，

• 并發標記（Concurrent Mark）：并發標記是遍歷物件圖做可達性分析的階段，與G1、Shenandoah不同的是，ZGC的標記是在指標上而不是在物件上進行的，標記階段會更新染色指標中的Marked 0、Marked 1標志位，

• 并發預備重分配（Concurrent Prepare for Relocate）：這個階段需要根據特定的查詢條件統計得出本次收集程序要清理哪些Region，將這些Region組成重分配集（Relocation Set），重分配集與G1收集器的回收集（Collection Set）還是有區別的，ZGC劃分Region的目的并非為了像G1那樣做收益優先的增量回收，相反，ZGC每次回收都會掃描所有的Region，用范圍更大的掃描成本換取省去G1中記憶集的維護成本，因此，ZGC的重分配集只是決定了里面的存活物件會被重新復制到其他的Region中，里面的Region會被釋放，而并不能說回收行為就只是針對這個集合里面的Region進行，因為標記程序是針對全堆的，此外，在JDK 12的ZGC中開始支持的類卸載以及弱參考的處理，也是在這個階段中完成的，

• 并發重分配（Concurrent Relocate）：重分配是ZGC執行程序中的核心階段，這個程序要把重分配集中的存活物件復制到新的Region上，并為重分配集中的每個Region維護一個轉發表（Forward Table），記錄從舊物件到新物件的轉向關系，得益于染色指標的支持，ZGC收集器能僅從參考上就明確得知一個物件是否處于重分配集之中，如果用戶執行緒此時并發訪問了位于重分配集中的物件，這次訪問將會被預置的記憶體屏障所截獲，然后立即根據Region上的轉發表記錄將訪問轉發到新復制的物件上，并同時修正更新該參考的值，使其直接指向新物件，ZGC將這種行為稱為指標的“自愈”（Self-Healing）能力，這樣做的好處是只有第一次訪問舊物件會陷入轉發，也就是只慢一次，對比Shenandoah的Brooks轉發指標，那是每次物件訪問都必須付出的固定開銷，簡單地說就是每次都慢，因此ZGC對用戶程式的運行時負載要比Shenandoah來得更低一些，還有另外一個直接的好處是由于染色指標的存在，一旦重分配集中某個Region的存活物件都復制完畢后，這個Region就可以立即釋放用于新物件的分配（但是轉發表還得留著不能釋放掉），哪怕堆中還有很多指向這個物件的未更新指標也沒有關系，這些舊指標一旦被使用，它們都是可以自愈的，

• 并發重映射（Concurrent Remap）：重映射所做的就是修正整個堆中指向重分配集中舊物件的所有參考，這一點從目標角度看是與Shenandoah并發參考更新階段一樣的，但是ZGC的并發重映射并不是一個必須要“迫切”去完成的任務，因為前面說過，即使是舊參考，它也是可以自愈的，最多只是第一次使用時多一次轉發和修正操作，重映射清理這些舊參考的主要目的是為了不變慢（還有清理結束后可以釋放轉發表這樣的附帶收益），所以說這并不是很“迫切”，因此，ZGC很巧妙地把并發重映射階段要做的作業，合并到了下一次垃圾收集回圈中的并發標記階段里去完成，反正它們都是要遍歷所有物件的，這樣合并就節省了一次遍歷物件圖的開銷，一旦所有指標都被修正之后，原來記錄新舊物件關系的轉發表就可以釋放掉了，

ZGC幾乎整個收集程序都全程可并發，短暫停頓也只與GC Roots大小相關而與堆記憶體大小無關，因而同樣實作了任何堆上停頓都小于十毫秒的目標，

ZGC的優缺點

相比G1、Shenandoah等先進的垃圾收集器，ZGC在實作細節上做了一些不同的權衡選擇，譬如G1需要通過寫屏障來維護記憶集，才能處理跨代指標，得以實作Region的增量回收，記憶集要占用大量的記憶體空間，寫屏障也對正常程式運行造成額外負擔，這些都是權衡選擇的代價，ZGC就完全沒有使用記憶集，它甚至連分代都沒有，連像CMS中那樣只記錄新生代和老年代間參考的卡表也不需要，因而完全沒有用到寫屏障，所以給用戶執行緒帶來的運行負擔也要小得多，

可是，有優就有劣，ZGC的這種選擇也限制了它能承受的物件分配速率不會太高，因為ZGC四個階段都支持并發，如果分配速率高，將創造大量的新物件，這就產生了大量的浮動垃圾，如果這種高速分配持續維持的話，回收到的記憶體空間持續小于期間并發產生的浮動垃圾所占的空間，堆中剩余可騰挪的空間就越來越小了，目前唯一的辦法就是盡可能地增加堆容量大小，獲得更多喘息的時間，但是若要從根本上提升ZGC能夠應對的物件分配速率，還是需要引入分代收集，讓新生物件都在一個專門的區域中創建，所以分代演算法有利有弊，

如果本篇博客有任何錯誤和建議，歡迎給我留言指正，文章持續更新，可以關注公眾號第一時間閱讀，

標籤：Java

上一篇：帶你熟悉3種AQS的執行緒并發工具的用法

下一篇：記一次線上FGC問題排查