JAVA程序最爽的地方是它的GC機制,開發人員不須要關注內存申請和回收問題。同時,JAVA程序最頭疼的地方也是它的GC機制,由於掌握JVM和GC調優是一件很是困難的事情。在ParallelOldGC、CMS、G1以後,JDK11帶來的全新的「ZGC」爲咱們解決了什麼問題?Oracle官方介紹它是一個Scalable、Low Latency的垃圾回收器。因此它的目的是「下降停頓時間」,由此會致使吞吐量會有所下降。吞吐量下降問題不大,橫向擴展幾臺服務器就能解決問題了啦。java
以下圖所示,ZGC的目標主要有4個:算法
另外,Oracle官方提到了它最大的優勢是:它的停頓時間不會隨着堆的增大而增加!也就是說,幾十G堆的停頓時間是10ms如下,幾百G甚至上T堆的停頓時間也是10ms如下。服務器
接下來從幾個維度概述一下ZGC。架構
ZGC是一個全新的垃圾回收器,它徹底不一樣以往HotSpot的任何垃圾回收器,好比:PS、CMS、G1等。若是真要說它最像誰的話,那應該是Azul公司的商業化垃圾回收器:「C4」,ZGC所採用的算法就是Azul Systems不少年前提出的Pauseless GC,而實現上它介於早期Azul VM的Pauseless GC與後來Zing VM的C4之間。不過須要說明的是,JDK11中ZGC只能運行在Linux64操做系統之上。JDK14新增支持了MacOS和Window平臺:併發
以下圖所示,是ZGC和Parallel以及G1的壓測對比結果(CMS在JDK9中已經被標記deprecated,更高版本中已經被完全移除,因此不在對比範圍內)。咱們能夠明顯的看到,停頓時間方面,ZGC是100%不超過10ms的,簡直是秒天秒地般的存在:app
接下來,再看一下ZGC的垃圾回收過程,以下圖所示。由圖咱們可知,ZGC依然沒有作到整個GC過程徹底併發執行,依然有3個STW階段,其餘3個階段都是併發執行階段:less
這一步就是初始化標記,和CMS以及G1同樣,主要作Root集合掃描,「GC Root是一組必須活躍的引用,而不是對象」。例如:活躍的棧幀裏指向GC堆中的對象引用、Bootstrap/System類加載器加載的類、JNI Handles、引用類型的靜態變量、String常量池裏面的引用、線程棧/本地(native)棧裏面的對象指針等,但不包括GC堆裏的對象指針。因此這一步驟的STW時間很是短暫,而且和堆大小沒有任何關係。不過會根據線程的多少、線程棧的大小之類的而變化。性能
第二步就是併發標記階段,這個階段在第一步的基礎上,繼續往下標記存活的對象。併發標記後,還會有一個短暫的暫停(Pause Mark End),確保全部對象都被標記。測試
即爲Relocation階段作準備,選取接下來須要標記整理的Region集合,這個階段也是併發執行的。接下來又會有一個Pause Relocate Start步驟,它的做用是隻移動Root集合對象引用,因此這個STW階段也不會停頓太長時間。spa
單代,即ZGC「沒有分代」。咱們知道之前的垃圾回收器之因此分代,是由於源於「「大部分對象朝生夕死」」的假設,事實上大部分系統的對象分配行爲也確實符合這個假設。
那麼爲何ZGC就不分代呢?由於分代實現起來麻煩,做者就先實現出一個比較簡單可用的單代版本。用符合咱們國情的話來解釋,大概就是說:工做量太大了,人力又不夠,老闆,先上個1.0版本吧!!!
這一點和G1同樣,都是基於Region設計的垃圾回收器,ZGC中的Region也被稱爲「ZPages」,ZPages被動態建立,動態銷燬。不過,和G1稍微有點不一樣的是,G1的每一個Region大小是徹底同樣的,而ZGC的Region大小分爲3類:2MB,32MB,N×2MB,如此一來,靈活性就更好了:
部分壓縮,這一點也很G1相似。之前的ParallelOldGC,以及CMS GC在壓縮Old區的時候,不管Old區有多大,必須總體進行壓縮(CMS GC默認狀況下只是標記清除,只會發生FGC時纔會採用Mark-Sweep-Compact對Old區進行壓縮),如此一來,Old區越大,壓縮須要的時間確定就越長,從而致使停頓時間就越長。
而G1和ZGC都是基於Region設計的,在回收的時候,它們只會選擇一部分Region進行回收,這個回收過程採用的是Mark-Compact算法,即將待回收的Region中存活的對象拷貝到一個全新的Region中,這個新的Region對象分配就會很是緊湊,幾乎沒有碎片。垃圾回收算法這一點上,和G1是同樣的。
NUMA對應的有UMA,UMA即Uniform Memory Access Architecture,NUMA就是Non Uniform Memory Access Architecture。UMA表示內存只有一塊,全部CPU都去訪問這一塊內存,那麼就會存在競爭問題(爭奪內存總線訪問權),有競爭就會有鎖,有鎖效率就會受到影響,並且CPU核心數越多,競爭就越激烈。NUMA的話每一個CPU對應有一塊內存,且這塊內存在主板上離這個CPU是最近的,每一個CPU優先訪問這塊內存,那效率天然就提升了:
服務器的NUMA架構在中大型系統上一直很是盛行,也是高性能的解決方案,尤爲在系統延遲方面表現都很優秀。ZGC是能自動感知NUMA架構並充分利用NUMA架構特性的。
Colored Pointers,即顏色指針是什麼呢?以下圖所示,ZGC的核心設計之一。之前的垃圾回收器的GC信息都保存在對象頭中,而ZGC的GC信息保存在指針中。每一個對象有一個64位指針,這64位被分爲:
經過對配置ZGC後對象指針分析咱們可知,對象指針必須是64位,那麼ZGC就沒法支持32位操做系統,一樣的也就沒法支持壓縮指針了(CompressedOops,壓縮指針也是32位)。
這個應該翻譯成讀屏障(與之對應的有寫屏障即Write Barrier,以前的GC都是採用Write Barrier,此次ZGC採用了徹底不一樣的方案),這個是ZGC一個很是重要的特性。在標記和移動對象的階段,每次「從堆裏對象的引用類型中讀取一個指針」的時候,都須要加上一個Load Barriers。那麼咱們該如何理解它呢?看下面的代碼,第一行代碼咱們嘗試讀取堆中的一個對象引用obj.fieldA並賦給引用o(fieldA也是一個對象時纔會加上讀屏障)。若是這時候對象在GC時被移動了,接下來JVM就會加上一個讀屏障,這個屏障會把讀出的指針更新到對象的新地址上,而且把堆裏的這個指針「修正」到本來的字段裏。這樣就算GC把對象移動了,讀屏障也會發現並修正指針,因而應用代碼就永遠都會持有更新後的有效指針,並且不須要STW。那麼,JVM是如何判斷對象被移動過呢?就是利用上面提到的顏色指針,若是指針是Bad Color,那麼程序還不能往下執行,須要「slow path」,修正指針;若是指針是Good Color,那麼正常往下執行便可:
這個動做是否是很是像JDK併發中用到的CAS自旋?讀取的值發現已經失效了,須要從新讀取。而ZGC這裏是以前持有的指針因爲GC後失效了,須要經過讀屏障修正指針。
後面3行代碼都不須要加讀屏障:Object p = o這行代碼並無從堆中讀取數據;o.doSomething()也沒有從堆中讀取數據;obj.fieldB不是對象引用,而是原子類型。
正是由於Load Barriers的存在,因此會致使配置ZGC的應用的吞吐量會變低。官方的測試數據是須要多出額外4%的開銷:
那麼,判斷對象是Bad Color仍是Good Color的依據是什麼呢?就是根據上一段提到的Colored Pointers的4個顏色位。當加上讀屏障時,根據對象指針中這4位的信息,就能知道當前對象是Bad/Good Color了。
「擴展閱讀」:既然低42位指針能夠支持4T內存,那麼可否經過預定更多位給對象地址來達到支持更大內存的目的呢?答案確定是不能夠。由於目前主板地址總線最寬只有48bit,4位是顏色位,就只剩44位了,因此受限於目前的硬件,ZGC最大隻能支持16T的內存,JDK13就把最大支持堆內存從4T擴大到了16T。
啓用ZGC比較簡單,設置JVM參數便可:-XX:+UnlockExperimentalVMOptions 「-XX:+UseZGC」。調優也並不難,由於ZGC調優參數並很少,遠不像CMS那麼複雜。它和G1同樣,能夠調優的參數都比較少,大部分工做JVM能很好的自動完成。下圖所示是ZGC能夠調優的參數:
下面對部分參數進行更加詳細的說明。
UseNUMA
ZGC默認是開啓支持NUMA的,不過,若是JVM探測到系統綁定的是CPU子集,就會自動禁用NUMA。咱們能夠經過參數-XX:+UseNUMA顯示啓動,或者經過參數-XX:-UseNUMA顯示禁用。若是運行在NUMA服務器上,而且設置-XX:+UseNUMA,那對性能提高是顯而易見的。
UseLargePages
配置ZGC使用large page一般就會獲得更好的性能,好比在吞吐量、延遲、啓動時間等方面。並且沒有明顯的缺點,除了配置過程複雜一點。由於它須要root權限,這也是默認並無開啓使用large page的緣由。
ConcGCThreads
ZGC是一個併發垃圾收集器,那麼併發GC線程數就很是重要了。若是設置併發GC線程數越多,意味着應用線程數就會越少,這確定是很是不利於應用系統穩定運行的。這個參數ZGC能自動設置,若是沒有十足的把握。最好不要設置這個參數。
ParallelGCThreads
這是個並行線程數,與上一個參數ConcGCThreads有所不一樣,ConcGCThreads表示GC線程和應用線程「併發」執行時GC線程數量。而ParallelGCThreads表示GC時STW階段的「並行」GC線程數量(例如第一階段的Root掃描),這時候只有GC線程,沒有應用線程。筆者這裏解釋了JVM中「併發和並行的區別」,也是JVM中比較容易理解錯誤的地方。
ZUncommit
掌握這個參數以前,咱們先說一下JVM申請以及回收內存的行爲。之前的垃圾回收器好比ParallelOldGC和CMS,只要JVM申請過的內存,即便發生了GC回收了不少內存空間,JVM也不會把這些內存歸還給操做系統。這就會致使top命令中看到的RSS只會愈來愈高,並且通常都會超過Xmx的值(參考文章:)。
不過,默認狀況下,ZGC是會把再也不使用的內存歸還給操做系統的。這對於那些比較注意內存佔用狀況的應用和服務器來講,是頗有用的。這種行爲能夠經過JVM參數-XX:-ZUncommit關閉。不過,不管怎麼歸還,JVM至少會保留Xms參數指定的內存大小,這就是說,當Xmx和Xms同樣大的時候,這個參數就不起做用了。
和這個參數一塊兒起做用的還有另外一個參數:-「XX:ZUncommitDelay=sec」,默認300秒。這個參數表示再也不使用的內存最多延遲多長時間纔會被歸還給操做系統。由於再也不使用的內存不該該當即歸還給操做系統,這樣會形成頻繁的歸還和申請行爲,因此經過這個參數來控制再也不使用的內存須要通過多久的時間才歸還給操做系統。
接下來,咱們看一下從JDK11到JDK15這5個版本,ZGC都迭代了哪些特性:
JDK 15 (under development)
JDK 14
JDK 13
JDK 12
JDK 11
若是你以爲這篇內容對你還蠻有幫助,我想邀請你幫我三個小忙:
點贊,轉發,有大家的 『點贊和評論』,纔是我創造的動力。
關注公衆號 『 java爛豬皮 』,不按期分享原創知識。
同時能夠期待後續文章ing🚀