JDK11 | 第七篇 : ZGC 垃圾收集器

1、簡介

Java 11包含一個全新的垃圾收集器--ZGC，它由Oracle開發，承諾在數TB的堆上具備很是低的暫停時間。 在本文中，咱們將介紹開發新GC的動機，技術概述以及由ZGC開啓的一些可能性。

那麼爲何須要新GC呢？畢竟Java 10已經有四種發佈多年的垃圾收集器，而且幾乎都是無限可調的。 換個角度看，G1是2006年時引入Hotspot VM的。當時最大的AWS實例有1 vCPU和1.7GB內存，而今天AWS很樂意租給你一個x1e.32xlarge實例，該類型實例有128個vCPU和3,904GB內存。 ZGC的設計目標是：支持TB級內存容量，暫停時間低（<10ms），對整個程序吞吐量的影響小於15%。 未來還能夠擴展實現機制，以支持很多使人興奮的功能，例如多層堆（即熱對象置於DRAM和冷對象置於NVMe閃存），或壓縮堆。

2、GC術語

爲了理解ZGC如何匹配現有收集器，以及如何實現新GC，咱們須要先了解一些術語。最基本的垃圾收集涉及識別再也不使用的內存並使其可重用。現代收集器在幾個階段進行這一過程，對於這些階段咱們每每有以下描述：

• 並行：在JVM運行時，同時存在應用程序線程和垃圾收集器線程。 並行階段是由多個gc線程執行，即gc工做在它們之間分配。 不涉及GC線程是否須要暫停應用程序線程。

• 串行：串行階段僅在單個gc線程上執行。與以前同樣，它也沒有說明GC線程是否須要暫停應用程序線程。

• STW：STW階段，應用程序線程被暫停，以便gc執行其工做。 當應用程序由於GC暫停時，這一般是因爲Stop The World階段。

• 併發：若是一個階段是併發的，那麼GC線程能夠和應用程序線程同時進行。 併發階段很複雜，由於它們須要在階段完成以前處理可能使工做無效。

• 增量：若是一個階段是增量的，那麼它能夠運行一段時間以後因爲某些條件提早終止，例如須要執行更高優先級的gc階段，同時仍然完成生產性工做。 增量階段與須要徹底完成的階段造成鮮明對比。

3、工做原理

如今咱們瞭解了不一樣gc階段的屬性，讓咱們繼續探討ZGC的工做原理。 爲了實現其目標，ZGC給Hotspot Garbage Collectors增長了兩種新技術：着色指針和讀屏障。

着色指針

着色指針是一種將信息存儲在指針（或使用Java術語引用）中的技術。由於在64位平臺上（ZGC僅支持64位平臺），指針能夠處理更多的內存，所以可使用一些位來存儲狀態。 ZGC將限制最大支持4Tb堆（42-bits），那麼會剩下22位可用，它目前使用了4位： finalizable， remap， mark0和mark1。 咱們稍後解釋它們的用途。

着色指針的一個問題是，當您須要取消着色時，它須要額外的工做（由於須要屏蔽信息位）。 像SPARC這樣的平臺有內置硬件支持指針屏蔽因此不是問題，而對於x86平臺來講，ZGC團隊使用了簡潔的多重映射技巧。

多重映射

要了解多重映射的工做原理，咱們須要簡要解釋虛擬內存和物理內存之間的區別。 物理內存是系統可用的實際內存，一般是安裝的DRAM芯片的容量。 虛擬內存是抽象的，這意味着應用程序對（一般是隔離的）物理內存有本身的視圖。 操做系統負責維護虛擬內存和物理內存範圍之間的映射，它經過使用頁表和處理器的內存管理單元（MMU）和轉換查找緩衝器（TLB）來實現這一點，後者轉換應用程序請求的地址。

多重映射涉及將不一樣範圍的虛擬內存映射到同一物理內存。 因爲設計中只有一個remap，mark0和mark1在任什麼時候間點均可覺得1，所以可使用三個映射來完成此操做。 ZGC源代碼中有一個很好的圖表能夠說明這一點。

讀屏障

讀屏障是每當應用程序線程從堆加載引用時運行的代碼片斷（即訪問對象上的非原生字段non-primitive field）：

void printName( Person person ) {
    String name = person.name;  // 這裏觸發讀屏障
                                // 由於須要從heap讀取引用 
                                // 
    System.out.println(name);   // 這裏沒有直接觸發讀屏障
}

在上面的代碼中，String name = person.name 訪問了堆上的person引用，而後將引用加載到本地的name變量。此時觸發讀屏障。 Systemt.out那行不會直接觸發讀屏障，由於沒有來自堆的引用加載（name是局部變量，所以沒有從堆加載引用）。 可是System和out，或者println內部可能會觸發其餘讀屏障。

這與其餘GC使用的寫屏障造成對比，例如G1。讀屏障的工做是檢查引用的狀態，並在將引用（或者甚至是不一樣的引用）返回給應用程序以前執行一些工做。 在ZGC中，它經過測試加載的引用來執行此任務，以查看是否設置了某些位。 若是經過了測試，則不執行任何其餘工做，若是失敗，則在將引用返回給應用程序以前執行某些特定於階段的任務。

標記

如今咱們瞭解了這兩種新技術是什麼，讓咱們來看看ZG的GC循環。

GC循環的第一部分是標記。標記包括查找和標記運行中的應用程序能夠訪問的全部堆對象，換句話說，查找不是垃圾的對象。

ZGC的標記分爲三個階段。 第一階段是STW，其中GC roots被標記爲活對象。 GC roots相似於局部變量，經過它能夠訪問堆上其餘對象。 若是一個對象不能經過遍歷從roots開始的對象圖來訪問，那麼應用程序也就沒法訪問它，則該對象被認爲是垃圾。從roots訪問的對象集合稱爲Live集。GC roots標記步驟很是短，由於roots的總數一般比較小。

該階段完成後，應用程序恢復執行，ZGC開始下一階段，該階段同時遍歷對象圖並標記全部可訪問的對象。 在此階段期間，讀屏障針使用掩碼測試全部已加載的引用，該掩碼肯定它們是否已標記或還沒有標記，若是還沒有標記引用，則將其添加到隊列以進行標記。

在遍歷完成以後，有一個最終的，時間很短的的Stop The World階段，這個階段處理一些邊緣狀況（咱們如今將它忽略），該階段完成以後標記階段就完成了。

重定位

GC循環的下一個主要部分是重定位。重定位涉及移動活動對象以釋放部分堆內存。 爲何要移動對象而不是填補空隙？ 有些GC實際是這樣作的，可是它致使了一個不幸的後果，即分配內存變得更加昂貴，由於當須要分配內存時，內存分配器須要找到能夠放置對象的空閒空間。 相比之下，若是能夠釋放大塊內存，那麼分配內存就很簡單，只須要將指針遞增新對象所需的內存大小便可。

ZGC將堆分紅許多頁面，在此階段開始時，它同時選擇一組須要重定位活動對象的頁面。選擇重定位集後，會出現一個Stop The World暫停，其中ZGC重定位該集合中root對象，並將他們的引用映射到新位置。與以前的Stop The World步驟同樣，此處涉及的暫停時間僅取決於root的數量以及重定位集的大小與對象的總活動集的比率，這一般至關小。因此不像不少收集器那樣，暫停時間隨堆增長而增長。

移動root後，下一階段是併發重定位。 在此階段，GC線程遍歷重定位集並從新定位其包含的頁中全部對象。 若是應用程序線程試圖在GC從新定位對象以前加載它們，那麼應用程序線程也能夠重定位該對象，這能夠經過讀屏障（在從堆加載引用時觸發）實現，如流程圖以下所示：

這可確保應用程序看到的全部引用都已更新，而且應用程序不可能同時對重定位的對象進行操做。

GC線程最終將對重定位集中的全部對象重定位，然而可能仍有引用指向這些對象的舊位置。 GC能夠遍歷對象圖並從新映射這些引用到新位置，可是這一步代價很高昂。 所以這一步與下一個標記階段合併在一塊兒。在下一個GC週期的標記階段遍歷對象對象圖的時候，若是發現未重映射的引用，則將其從新映射，而後標記爲活動狀態。

歸納

試圖單獨理解複雜垃圾收集器（如ZGC）的性能特徵是很困難的，但從前面的部分能夠清楚地看出，咱們所碰到的幾乎全部暫停都只依賴於GC roots集合大小，而不是實時堆大小。標記階段中處理標記終止的最後一次暫停是惟一的例外，可是它是增量的，若是超過gc時間預算，那麼GC將恢復到併發標記，直到再次嘗試。

3、性能

那ZGC到底表現如何？

Stefan Karlsson和Per Liden在今年早些時候的Jfokus演講中給出了一些數字。 ZGC的SPECjbb 2015吞吐量與Parallel GC（優化吞吐量）大體至關，但平均暫停時間爲1ms，最長爲4ms。 與之相比G1和Parallel有不少次超過200ms的GC停頓。

然而，垃圾收集器是複雜的軟件，從基準測試結果可能沒法推測出真實世界的性能。咱們期待本身測試ZGC，以瞭解它的性能如何因工做負載而異。

本文參考：https://mp.weixin.qq.com/s/nAjPKSj6rqB_eaqWtoJsgw

歡迎掃碼或微信搜索公衆號《程序員果果》關注我，關注有驚喜~