從實際案例聊聊JDK 17 的GC優化

文章目錄

從實際案例聊聊JDK 17 的GC優化

一、優化前的準備

GC優化需知

1. GC優化不能解決一切性能問題，它是最後的調優手段。

伸手黨福利:

JVM基礎回顧

JVM記憶體結構
常見垃圾回收器
GC日志

參數基本政策

二、優化步驟

确定目标

優化

驗收優化結果

三、GC優化案例

案例一 Major GC和Minor GC頻繁

确定目标
優化
優化結果
小結
更多思考

案例二請求高峰期發生GC，導緻服務可用性下降

确定目标
優化
優化結果
小結
更多思考

案例三發生Stop-The-World的GC

确定目标
優化
優化結果
小結

四、總結

結語

當Java程式性能達不到既定目标，且其他優化手段都已經窮盡時，通常需要調整垃圾回收器來進一步提高性能，稱為GC優化。但GC算法複雜，影響GC性能的參數衆多，且參數調整又依賴于應用各自的特點，這些因素很大程度上增加了GC優化的難度。即便如此，GC調優也不是無章可循，仍然有一些通用的思考方法。本篇會介紹這些通用的GC優化政策和相關實踐案例，主要包括如下内容： > 優化前準備: 簡單回顧JVM相關知識、介紹GC優化的一些通用政策。 > 優化方法: 介紹調優的一般流程：明确優化目标→優化→跟蹤優化結果。 > 優化案例: 簡述筆者所在團隊遇到的GC問題以及優化方案。

一、優化前的準備

GC優化需知

為了更好地了解本篇所介紹的内容，你需要了解如下内容。 1. GC相關基礎知識，包括但不限于： a) GC工作原理。 b) 了解新生代、老年代、晉升等術語含義。 c) 可以看懂GC日志。

1. GC優化不能解決一切性能問題，它是最後的調優手段。

伸手黨福利:

送一套gc優化參數:

java -server -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/app/heapdump -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:"/app/logs/mes-gcc-%t.log" -Djava.rmi.server.hostname=192.168.18.244 -Djava.net.preferIPv4Stack=true -XX:+PrintStringDeduplicationStatistics -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:InitiatingHeapOccupancyPercent=80 -Dcom.sun.management.jmxremote.ssl=false -XX:+UnlockDiagnosticVMOptions -XX:G1HeapRegionSize=1M -XX:+G1SummarizeRSetStats -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -Xss5000K -Xmx8192M -Xms8192M -XX:NewSize=4G -XX:MaxNewSize=6G -XX:SurvivorRatio=4 -XX:NewRatio=4 -Dfile.encoding=UTF-8 -Xverify:none -jar "%BASE%\mes-lastest.jar" --spring.profiles.active=dev --spring.mvc.async.request-timeout=10000 --server.undertow.io-threads=12 --server.undertow.worker-threads=1024 --server.undertow.buffer-size=1024

如果對第一點中提及的知識點不是很熟悉，可以先閱讀小結-JVM基礎回顧；如果已經很熟悉，可以跳過該節直接往下閱讀。

JVM基礎回顧

JVM記憶體結構

簡單介紹一下JVM記憶體結構和常見的垃圾回收器。

當代主流虛拟機（Hotspot VM）的垃圾回收都采用“分代回收”的算法。“分代回收”是基于這樣一個事實：對象的生命周期不同，是以針對不同生命周期的對象可以采取不同的回收方式，以便提高回收效率。

Hotspot VM将記憶體劃分為不同的實體區，就是“分代”思想的展現。如圖所示，JVM記憶體主要由新生代、老年代、永久代構成。

① 新生代（Young Generation）：大多數對象在新生代中被建立，其中很多對象的生命周期很短。每次新生代的垃圾回收（又稱Minor GC）後隻有少量對象存活，是以選用複制算法，隻需要少量的複制成本就可以完成回收。

新生代内又分三個區：一個Eden區，兩個Survivor區（一般而言），大部分對象在Eden區中生成。當Eden區滿時，還存活的對象将被複制到兩個Survivor區（中的一個）。當這個Survivor區滿時，此區的存活且不滿足“晉升”條件的對象将被複制到另外一個Survivor區。對象每經曆一次Minor GC，年齡加1，達到“晉升年齡門檻值”後，被放到老年代，這個過程也稱為“晉升”。顯然，“晉升年齡門檻值”的大小直接影響着對象在新生代中的停留時間，在Serial和ParNew GC兩種回收器中，“晉升年齡門檻值”通過參數MaxTenuringThreshold設定，預設值為15。

② 老年代（Old Generation）：在新生代中經曆了N次垃圾回收後仍然存活的對象，就會被放到年老代，該區域中對象存活率高。老年代的垃圾回收（又稱Major GC）通常使用“标記-清理”或“标記-整理”算法。整堆包括新生代和老年代的垃圾回收稱為Full GC（HotSpot VM裡，除了CMS之外，其它能收集老年代的GC都會同時收集整個GC堆，包括新生代）。

③ 永久代（Perm Generation）：主要存放中繼資料，例如Class、Method的元資訊，與垃圾回收要回收的Java對象關系不大。相對于新生代和年老代來說，該區域的劃分對垃圾回收影響比較小。

常見垃圾回收器

不同的垃圾回收器，适用于不同的場景。常用的垃圾回收器：

串行（Serial）回收器是單線程的一個回收器，簡單、易實作、效率高。
并行（ParNew）回收器是Serial的多線程版，可以充分的利用CPU資源，減少回收的時間。
吞吐量優先（Parallel Scavenge）回收器，側重于吞吐量的控制。
并發标記清除（CMS，Concurrent Mark Sweep）回收器是一種以擷取最短回收停頓時間為目标的回收器，該回收器是基于“标記-清除”算法實作的。

GC日志

每一種回收器的日志格式都是由其自身的實作決定的，換而言之，每種回收器的日志格式都可以不一樣。但虛拟機設計者為了友善使用者閱讀，将各個回收器的日志都維持一定的共性。JavaGC日志中簡單介紹了這些共性。

參數基本政策

各分區的大小對GC的性能影響很大。如何将各分區調整到合适的大小，分析活躍資料的大小是很好的切入點。

活躍資料的大小是指，應用程式穩定運作時長期存活對象在堆中占用的空間大小，也就是Full GC後堆中老年代占用空間的大小。可以通過GC日志中Full GC之後老年代資料大小得出，比較準确的方法是在程式穩定後，多次擷取GC資料，通過取平均值的方式計算活躍資料的大小。活躍資料和各分區之間的比例關系如下（見參考文獻1）：

空間	倍數
總大小	3-4 倍活躍資料的大小
新生代	1-1.5 活躍資料的大小
老年代	2-3 倍活躍資料的大小
永久代	1.2-1.5 倍Full GC後的永久代空間占用

例如，根據GC日志獲得老年代的活躍資料大小為300M，那麼各分區大小可以設為：

總堆：1200MB = 300MB × 4* 新生代：450MB = 300MB × 1.5* 老年代： 750MB = 1200MB - 450MB*

這部分設定僅僅是堆大小的初始值，後面的優化中，可能會調整這些值，具體情況取決于應用程式的特性和需求。

二、優化步驟

GC優化一般步驟可以概括為：确定目标、優化參數、驗收結果。

确定目标

明确應用程式的系統需求是性能優化的基礎，系統的需求是指應用程式運作時某方面的要求，譬如： - 高可用，可用性達到幾個9。 - 低延遲，請求必須多少毫秒内完成響應。 - 高吞吐，每秒完成多少次事務。

明确系統需求之是以重要，是因為上述性能名額間可能沖突。比如通常情況下，縮小延遲的代價是降低吞吐量或者消耗更多的記憶體或者兩者同時發生。

由于筆者所在團隊主要關注高可用和低延遲兩項名額，是以接下來分析，如何量化GC時間和頻率對于響應時間和可用性的影響。通過這個量化名額，可以計算出目前GC情況對服務的影響，也能評估出GC優化後對響應時間的收益，這兩點對于低延遲服務很重要。

舉例：假設機關時間T内發生一次持續25ms的GC，接口平均響應時間為50ms，且請求均勻到達，根據下圖所示：

那麼有(50ms+25ms)/T比例的請求會受GC影響，其中GC前的50ms内到達的請求都會增加25ms，GC期間的25ms内到達的請求，會增加0-25ms不等，如果時間T内發生N次GC，受GC影響請求占比=(接口響應時間+GC時間)×N/T 。可見無論降低單次GC時間還是降低GC次數N都可以有效減少GC對響應時間的影響。

優化

通過收集GC資訊，結合系統需求，确定優化方案，例如選用合适的GC回收器、重新設定記憶體比例、調整JVM參數等。

進行調整後，将不同的優化方案分别應用到多台機器上，然後比較這些機器上GC的性能差異，有針對性的做出選擇，再通過不斷的試驗和觀察，找到最合适的參數。

驗收優化結果

将修改應用到所有伺服器，判斷優化結果是否符合預期，總結相關經驗。

接下來，我們通過三個案例來實踐以上的優化流程和基本原則（本文中三個案例使用的垃圾回收器均為ParNew+CMS，CMS失敗時Serial Old替補)。

三、GC優化案例

案例一 Major GC和Minor GC頻繁

确定目标

服務情況：Minor GC每分鐘100次，Major GC每4分鐘一次，單次Minor GC耗時25ms，單次Major GC耗時200ms，接口響應時間50ms。

由于這個服務要求低延時高可用，結合上文中提到的GC對服務響應時間的影響，計算可知由于Minor GC的發生，12.5%的請求響應時間會增加，其中8.3%的請求響應時間會增加25ms，可見目前GC情況對響應時間影響較大。

（50ms+25ms）× 100次/60000ms = 12.5%，50ms × 100次/60000ms = 8.3% 。

優化目标：降低TP99、TP90時間。

優化

首先優化Minor GC頻繁問題。通常情況下，由于新生代空間較小，Eden區很快被填滿，就會導緻頻繁Minor GC，是以可以通過增大新生代空間來降低Minor GC的頻率。例如在相同的記憶體配置設定率的前提下，新生代中的Eden區增加一倍，Minor GC的次數就會減少一半。

這時很多人有這樣的疑問，擴容Eden區雖然可以減少Minor GC的次數，但會增加單次Minor GC時間麼？根據上面公式，如果單次Minor GC時間也增加，很難保證最後的優化效果。我們結合下面情況來分析，單次Minor GC時間主要受哪些因素影響？是否和新生代大小存線上性關系？首先，單次Minor GC時間由以下兩部分組成：T1（掃描新生代）和 T2（複制存活對象到Survivor區）如下圖。（注：這裡為了簡化問題，我們認為T1隻掃描新生代判斷對象是否存活的時間，其實該階段還需要掃描部分老年代，後面案例中有較長的描述。）

擴容前：新生代容量為R ，假設對象A的存活時間為750ms，Minor GC間隔500ms，那麼本次Minor GC時間= T1（掃描新生代R）+T2（複制對象A到S）。
擴容後：新生代容量為2R ，對象A的生命周期為750ms，那麼Minor GC間隔增加為1000ms，此時Minor GC對象A已不再存活，不需要把它複制到Survivor區，那麼本次GC時間 = 2 × T1（掃描新生代R），沒有T2複制時間。

可見，擴容後，Minor GC時增加了T1（掃描時間），但省去T2（複制對象）的時間，更重要的是對于虛拟機來說，複制對象的成本要遠高于掃描成本，是以，單次Minor GC時間更多取決于GC後存活對象的數量，而非Eden區的大小。是以如果堆中短期對象很多，那麼擴容新生代，單次Minor GC時間不會顯著增加。下面需要确認下服務中對象的生命周期分布情況：

通過上圖GC日志中兩處紅色框标記内容可知： 1. new threshold = 2（動态年齡判斷，對象的晉升年齡門檻值為2），對象僅經曆2次Minor GC後就晉升到老年代，這樣老年代會迅速被填滿，直接導緻了頻繁的Major GC。 2. Major GC後老年代使用空間為300M+，意味着此時絕大多數(86% = 2G/2.3G)的對象已經不再存活，也就是說生命周期長的對象占比很小。

由此可見，服務中存在大量短期臨時對象，擴容新生代空間後，Minor GC頻率降低，對象在新生代得到充分回收，隻有生命周期長的對象才進入老年代。這樣老年代增速變慢，Major GC頻率自然也會降低。

優化結果

通過擴容新生代為為原來的三倍，單次Minor GC時間增加小于5ms，頻率下降了60%，服務響應時間TP90，TP99都下降了10ms+，服務可用性得到提升。

調整前：

調整後：

小結

如何選擇各分區大小應該依賴應用程式中對象生命周期的分布情況：如果應用存在大量的短期對象，應該選擇較大的年輕代；如果存在相對較多的持久對象，老年代應該适當增大。

案例二請求高峰期發生GC，導緻服務可用性下降

确定目标

GC日志顯示，高峰期CMS在重标記（Remark）階段耗時1.39s。Remark階段是Stop-The-World（以下簡稱為STW）的，即在執行垃圾回收時，Java應用程式中除了垃圾回收器線程之外其他所有線程都被挂起，意味着在此期間，使用者正常工作的線程全部被暫停下來，這是低延時服務不能接受的。本次優化目标是降低Remark時間。

優化

解決問題前，先回顧一下CMS的四個主要階段，以及各個階段的工作内容。下圖展示了CMS各個階段可以标記的對象，用不同顔色區分。

Init-mark初始标記(STW) ，該階段進行可達性分析，标記GC ROOT能直接關聯到的對象，是以很快。
Concurrent-mark并發标記，由前階段标記過的綠色對象出發，所有可到達的對象都在本階段中标記。
Remark重标記(STW)

，暫停所有使用者線程，重新掃描堆中的對象，進行可達性分析，标記活着的對象。因為并發标記階段是和使用者線程并發執行的過程，是以該過程中可能有使用者線程修改某些活躍對象的字段，指向了一個未标記過的對象，如下圖中紅色對象在并發标記開始時不可達，但是并行期間引用發生變化，變為對象可達，這個階段需要重新标記出此類對象，防止在下一階段被清理掉，這個過程也是需要STW的。特别需要注意一點，這個階段是以新生代中對象為根來判斷對象是否存活的。
并發清理，進行并發的垃圾清理。

可見，Remark階段主要是通過掃描堆來判斷對象是否存活。那麼準确判斷對象是否存活，需要掃描哪些對象？CMS對老年代做回收，Remark階段僅掃描老年代是否可行？結論是不可行，原因如下：

如果僅掃描老年代中對象，即以老年代中對象為根，判斷對象是否存在引用，上圖中，對象A因為引用存在新生代中，它在Remark階段就不會被修正标記為可達，GC時會被錯誤回收。新生代對象持有老年代中對象的引用，這種情況稱為**“跨代引用”**。因它的存在，Remark階段必須掃描整個堆來判斷對象是否存活，包括圖中灰色的不可達對象。

灰色對象已經不可達，但仍然需要掃描的原因：新生代GC和老年代的GC是各自分開獨立進行的，隻有Minor GC時才會使用根搜尋算法，标記新生代對象是否可達，也就是說雖然一些對象已經不可達，但在Minor GC發生前不會被标記為不可達，CMS也無法辨認哪些對象存活，隻能全堆掃描（新生代+老年代）。由此可見堆中對象的數目影響了Remark階段耗時。分析GC日志可以得出同樣的規律，Remark耗時>500ms時，新生代使用率都在75%以上。這樣降低Remark階段耗時問題轉換成如何減少新生代對象數量。

新生代中對象的特點是“朝生夕滅”，這樣如果Remark前執行一次Minor GC，大部分對象就會被回收。CMS就采用了這樣的方式，在Remark前增加了一個可中斷的并發預清理（CMS-concurrent-abortable-preclean），該階段主要工作仍然是并發标記對象是否存活，隻是這個過程可被中斷。此階段在Eden區使用超過2M時啟動，當然2M是預設的門檻值，可以通過參數修改。如果此階段執行時等到了Minor GC，那麼上述灰色對象将被回收，Reamark階段需要掃描的對象就少了。

除此之外CMS為了避免這個階段沒有等到Minor GC而陷入無限等待，提供了參數CMSMaxAbortablePrecleanTime ，預設為5s，含義是如果可中斷的預清理執行超過5s，不管發沒發生Minor GC，都會中止此階段，進入Remark。根據GC日志紅色标記2處顯示，可中斷的并發預清理執行了5.35s，超過了設定的5s被中斷，期間沒有等到Minor GC ，是以Remark時新生代中仍然有很多對象。

對于這種情況，CMS提供CMSScavengeBeforeRemark參數，用來保證Remark前強制進行一次Minor GC。

優化結果

經過增加CMSScavengeBeforeRemark參數，單次執行時間>200ms的GC停頓消失，從監控上觀察，GCtime和業務波動保持一緻，不再有明顯的毛刺。

小結

通過案例分析了解到，由于跨代引用的存在，CMS在Remark階段必須掃描整個堆，同時為了避免掃描時新生代有很多對象，增加了可中斷的預清理階段用來等待Minor GC的發生。隻是該階段有時間限制，如果逾時等不到Minor GC，Remark時新生代仍然有很多對象，我們的調優政策是，通過參數強制Remark前進行一次Minor GC，進而降低Remark階段的時間。

案例三發生Stop-The-World的GC

确定目标

GC日志如下圖（在GC日志中，Full GC是用來說明這次垃圾回收的停頓類型，代表STW類型的GC，并不特指老年代GC），根據GC日志可知本次Full GC耗時1.23s。這個線上服務同樣要求低延遲時間高可用。本次優化目标是降低單次STW回收停頓時間，提高可用性。

優化

首先，什麼時候可能會觸發STW的Full

GC呢？

Perm空間不足；
CMS GC時出現promotion failed和concurrent mode failure（concurrent mode

failure發生的原因一般是CMS正在進行，但是由于老年代空間不足，需要盡快回收老年代裡面的不再被使用的對象，這時停止所有的線程，同時終止CMS，直接進行Serial

Old GC）；
統計得到的Young GC晉升到老年代的平均大小大于老年代的剩餘空間；
主動觸發Full GC（執行jmap -histo:live [pid]）來避免碎片問題。

然後，我們來逐一分析一下：

排除原因2：如果是原因2中兩種情況，日志中會有特殊辨別，目前沒有。
排除原因3：根據GC日志，當時老年代使用量僅為20%，也不存在大于2G的大對象産生。
排除原因4：因為當時沒有相關指令執行。
鎖定原因1：根據日志發現Full GC後，Perm區變大了，推斷是由于永久代空間不足容量擴充導緻的。

找到原因後解決方法有兩種： 1. 通過把-XX:PermSize參數和-XX:MaxPermSize設定成一樣，強制虛拟機在啟動的時候就把永久代的容量固定下來，避免運作時自動擴容。 2. CMS預設情況下不會回收Perm區，通過參數CMSPermGenSweepingEnabled、CMSClassUnloadingEnabled ，可以讓CMS在Perm區容量不足時對其回收。

由于該服務沒有生成大量動态類，回收Perm區收益不大，是以我們采用方案1，啟動時将Perm區大小固定，避免進行動态擴容。

優化結果

調整參數後，服務不再有Perm區擴容導緻的STW GC發生。

小結

對于性能要求很高的服務，建議将MaxPermSize和MinPermSize設定成一緻（JDK8開始，Perm區完全消失，轉而使用元空間。而元空間是直接存在記憶體中，不在JVM中），Xms和Xmx也設定為相同，這樣可以減少記憶體自動擴容和收縮帶來的性能損失。虛拟機啟動的時候就會把參數中所設定的記憶體全部化為私有，即使擴容前有一部分記憶體不會被使用者代碼用到，這部分記憶體在虛拟機中被辨別為虛拟記憶體，也不會交給其他程序使用。

四、總結

結合上述GC優化案例做個總結： 1. 首先再次聲明，在進行GC優化之前，需要确認項目的架構和代碼等已經沒有優化空間。我們不能指望一個系統架構有缺陷或者代碼層次優化沒有窮盡的應用，通過GC優化令其性能達到一個質的飛躍。 2. 其次，通過上述分析，可以看出虛拟機内部已有很多優化來保證應用的穩定運作，是以不要為了調優而調優，不當的調優可能适得其反。 3. 最後，GC優化是一個系統而複雜的工作，沒有萬能的調優政策可以滿足所有的性能名額。GC優化必須建立在我們深入了解各種垃圾回收器的基礎上，才能有事半功倍的效果。

從實際案例聊聊JDK 17 的GC優化