一文讀懂Java GC原理和調優

• 2019 年 10 月 9 日
• 筆記

概述

本文介紹GC基礎原理和理論，GC調優方法思路和方法，基於Hotspot jdk1.8，學習之後將了解如何對生產系統出現的GC問題進行排查解決

閱讀時長約30分鐘，內容主要如下：

• GC基礎原理，涉及調優目標，GC事件分類、JVM記憶體分配策略、GC日誌分析等
• CMS原理及調優
• G1原理及調優
• GC問題排查和解決思路

GC基礎原理

1 GC調優目標

大多數情況下對 Java 程式進行GC調優, 主要關注兩個目標：響應速度、吞吐量

• 響應速度(Responsiveness)
  響應速度指程式或系統對一個請求的響應有多迅速。比如，用戶訂單查詢響應時間，對響應速度要求很高的系統，較大的停頓時間是不可接受的。調優的重點是在短的時間內快速響應

• 吞吐量(Throughput)
  吞吐量關注在一個特定時間段內應用系統的最大工作量，例如每小時批處理系統能完成的任務數量，在吞吐量方面優化的系統，較長的GC停頓時間也是可以接受的，因為高吞吐量應用更關心的是如何儘可能快地完成整個任務，不考慮快速響應用戶請求

GC調優中，GC導致的應用暫停時間影響系統響應速度，GC處理執行緒的CPU使用率影響系統吞吐量

2 GC分代收集演算法

現代的垃圾收集器基本都是採用分代收集演算法，其主要思想：
將Java的堆記憶體邏輯上分成兩塊：新生代、老年代，針對不同存活周期、不同大小的對象採取不同的垃圾回收策略

• 新生代（Young Generation）

新生代又叫年輕代，大多數對象在新生代中被創建，很多對象的生命周期很短。每次新生代的垃圾回收（又稱Young GC、Minor GC、YGC）後只有少量對象存活，所以使用複製演算法，只需少量的複製操作成本就可以完成回收

新生代內又分三個區：一個Eden區，兩個Survivor區(S0、S1，又稱From Survivor、To Survivor)，大部分對象在Eden區中生成。當Eden區滿時，還存活的對象將被複制到兩個Survivor區（中的一個）。當這個Survivor區滿時，此區的存活且不滿足晉陞到老年代條件的對象將被複制到另外一個Survivor區。對象每經歷一次複製，年齡加1，達到晉陞年齡閾值後，轉移到老年代

• 老年代（Old Generation）

在新生代中經歷了N次垃圾回收後仍然存活的對象，就會被放到老年代，該區域中對象存活率高。老年代的垃圾回收通常使用「標記-整理」演算法

3 GC事件分類

根據垃圾收集回收的區域不同，垃圾收集主要通常分為Young GC、Old GC、Full GC、Mixed GC

(1) Young GC

新生代記憶體的垃圾收集事件稱為Young GC(又稱Minor GC)，當JVM無法為新對象分配在新生代記憶體空間時總會觸發 Young GC，比如 Eden 區佔滿時。新對象分配頻率越高, Young GC 的頻率就越高

Young GC 每次都會引起全線停頓(Stop-The-World)，暫停所有的應用執行緒，停頓時間相對老年代GC的造成的停頓，幾乎可以忽略不計

(2) Old GC 、Full GC、Mixed GC

Old GC，只清理老年代空間的GC事件，只有CMS的並發收集是這個模式
Full GC，清理整個堆的GC事件，包括新生代、老年代、元空間等

• Mixed GC，清理整個新生代以及部分老年代的GC，只有G1有這個模式

4 GC日誌分析

GC日誌是一個很重要的工具，它準確記錄了每一次的GC的執行時間和執行結果，通過分析GC日誌可以調優堆設置和GC設置，或者改進應用程式的對象分配模式，開啟的JVM啟動參數如下：

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -XX:+PrintGCTimeStamps

常見的Young GC、Full GC日誌含義如下：

免費的GC日誌圖形分析工具推薦下面2個：

• GCViewer，下載jar包直接運行
• gceasy，web工具，上傳GC日誌在線使用

5 記憶體分配策略

Java提供的自動記憶體管理，可以歸結為解決了對象的記憶體分配和回收的問題，前面已經介紹了記憶體回收，下面介紹幾條最普遍的記憶體分配策略

• 對象優先在Eden區分配
  大多數情況下，對象在先新生代Eden區中分配。當Eden區沒有足夠空間進行分配時，虛擬機將發起一次Young GC

• 大對象之間進入老年代
  JVM提供了一個對象大小閾值參數(-XX:PretenureSizeThreshold，默認值為0，代表不管多大都是先在Eden中分配記憶體)，大於參數設置的閾值值的對象直接在老年代分配，這樣可以避免對象在Eden及兩個Survivor直接發生大記憶體複製

• 長期存活的對象將進入老年代
  對象每經歷一次垃圾回收，且沒被回收掉，它的年齡就增加1，大於年齡閾值參數(-XX:MaxTenuringThreshold，默認15)的對象，將晉陞到老年代中

• 空間分配擔保
  當進行Young GC之前，JVM需要預估：老年代是否能夠容納Young GC後新生代晉陞到老年代的存活對象，以確定是否需要提前觸發GC回收老年代空間，基於空間分配擔保策略來計算：

continueSize：老年代最大可用連續空間

Young GC之後如果成功(Young GC後晉陞對象能放入老年代)，則代表擔保成功，不用再進行Full GC，提高性能；如果失敗，則會出現「promotion failed」錯誤，代表擔保失敗，需要進行Full GC

• 動態年齡判定
  新生代對象的年齡可能沒達到閾值(MaxTenuringThreshold參數指定)就晉陞老年代，如果Young GC之後，新生代存活對象達到相同年齡所有對象大小的總和大於任一Survivor空間(S0 或 S1總空間)的一半，此時S0或者S1區即將容納不了存活的新生代對象，年齡大於或等於該年齡的對象就可以直接進入老年代，無須等到MaxTenuringThreshold中要求的年齡

另外，如果Young GC後S0或S1區不足以容納：未達到晉陞老年代條件的新生代存活對象，會導致這些存活對象直接進入老年代，需要盡量避免

CMS原理及調優

1 名詞解釋

可達性分析演算法：用於判斷對象是否存活，基本思想是通過一系列稱為「GC Root」的對象作為起點（常見的GC Root有系統類載入器、棧中的對象、處於激活狀態的執行緒等），基於對象引用關係，從GC Roots開始向下搜索，所走過的路徑稱為引用鏈，當一個對象到GC Root沒有任何引用鏈相連，證明對象不再存活

Stop The World：GC過程中分析對象引用關係，為了保證分析結果的準確性，需要通過停頓所有Java執行執行緒，保證引用關係不再動態變化，該停頓事件稱為Stop The World(STW)

Safepoint：程式碼執行過程中的一些特殊位置，當執行緒執行到這些位置的時候，說明虛擬機當前的狀態是安全的，如果有需要GC，執行緒可以在這個位置暫停。HotSpot採用主動中斷的方式，讓執行執行緒在運行期輪詢是否需要暫停的標誌，若需要則中斷掛起

2 CMS簡介

CMS(Concurrent Mark and Swee 並發-標記-清除)，是一款基於並發、使用標記清除演算法的垃圾回收演算法，只針對老年代進行垃圾回收。CMS收集器工作時，儘可能讓GC執行緒和用戶執行緒並發執行，以達到降低STW時間的目的

通過以下命令行參數，啟用CMS垃圾收集器:

-XX:+UseConcMarkSweepGC

值得補充的是，下面介紹到的CMS GC是指老年代的GC，而Full GC指的是整個堆的GC事件，包括新生代、老年代、元空間等，兩者有所區分

3 新生代垃圾回收

能與CMS搭配使用的新生代垃圾收集器有Serial收集器和ParNew收集器。這2個收集器都採用標記複製演算法，都會觸發STW事件，停止所有的應用執行緒。不同之處在於，Serial是單執行緒執行，ParNew是多執行緒執行

4 老年代垃圾回收

CMS GC以獲取最小停頓時間為目的，儘可能減少STW時間，可以分為7個階段

• 階段 1: 初始標記(Initial Mark)

此階段的目標是標記老年代中所有存活的對象, 包括 GC Root 的直接引用, 以及由新生代中存活對象所引用的對象，觸發第一次STW事件

這個過程是支援多執行緒的（JDK7之前單執行緒，JDK8之後並行，可通過參數CMSParallelInitialMarkEnabled調整）

• 階段 2: 並發標記(Concurrent Mark)

此階段GC執行緒和應用執行緒並發執行，遍歷階段1初始標記出來的存活對象，然後繼續遞歸標記這些對象可達的對象

• 階段 3: 並發預清理(Concurrent Preclean)

此階段GC執行緒和應用執行緒也是並發執行，因為階段2是與應用執行緒並發執行，可能有些引用關係已經發生改變。
通過卡片標記(Card Marking)，提前把老年代空間邏輯劃分為相等大小的區域(Card)，如果引用關係發生改變，JVM會將發生改變的區域標記位「臟區」(Dirty Card)，然後在本階段，這些臟區會被找出來，刷新引用關係，清除「臟區」標記

• 階段 4: 並發可取消的預清理(Concurrent Abortable Preclean)

此階段也不停止應用執行緒. 本階段嘗試在 STW 的 最終標記階段(Final Remark)之前儘可能地多做一些工作，以減少應用暫停時間
在該階段不斷循環處理：標記老年代的可達對象、掃描處理Dirty Card區域中的對象，循環的終止條件有：
1 達到循環次數
2 達到循環執行時間閾值
3 新生代記憶體使用率達到閾值

• 階段 5: 最終標記(Final Remark)

這是GC事件中第二次(也是最後一次)STW階段，目標是完成老年代中所有存活對象的標記。在此階段執行：
1 遍歷新生代對象，重新標記
2 根據GC Roots，重新標記
3 遍歷老年代的Dirty Card，重新標記

• 階段 6: 並發清除(Concurrent Sweep)

此階段與應用程式並發執行，不需要STW停頓，根據標記結果清除垃圾對象

• 階段 7: 並發重置(Concurrent Reset)

此階段與應用程式並發執行，重置CMS演算法相關的內部數據, 為下一次GC循環做準備

5 CMS常見問題

最終標記階段停頓時間過長問題

CMS的GC停頓時間約80%都在最終標記階段(Final Remark)，若該階段停頓時間過長，常見原因是新生代對老年代的無效引用，在上一階段的並發可取消預清理階段中，執行閾值時間內未完成循環，來不及觸發Young GC，清理這些無效引用

通過添加參數：-XX:+CMSScavengeBeforeRemark。在執行最終操作之前先觸發Young GC，從而減少新生代對老年代的無效引用，降低最終標記階段的停頓，但如果在上個階段(並發可取消的預清理)已觸發Young GC，也會重複觸發Young GC

併發模式失敗(concurrent mode failure) & 晉陞失敗(promotion failed)問題

併發模式失敗：當CMS在執行回收時，新生代發生垃圾回收，同時老年代又沒有足夠的空間容納晉陞的對象時，CMS 垃圾回收就會退化成單執行緒的Full GC。所有的應用執行緒都會被暫停，老年代中所有的無效對象都被回收

晉陞失敗：當新生代發生垃圾回收，老年代有足夠的空間可以容納晉陞的對象，但是由於空閑空間的碎片化，導致晉陞失敗，此時會觸發單執行緒且帶壓縮動作的Full GC

併發模式失敗和晉陞失敗都會導致長時間的停頓，常見解決思路如下：

• 降低觸發CMS GC的閾值，即參數-XX:CMSInitiatingOccupancyFraction的值，讓CMS GC儘早執行，以保證有足夠的空間
• 增加CMS執行緒數，即參數-XX:ConcGCThreads，
• 增大老年代空間
• 讓對象盡量在新生代回收，避免進入老年代

記憶體碎片問題

通常CMS的GC過程基於標記清除演算法，不帶壓縮動作，導致越來越多的記憶體碎片需要壓縮，常見以下場景會觸發記憶體碎片壓縮：

• 新生代Young GC出現新生代晉陞擔保失敗(promotion failed)
• 程式主動執行System.gc()

可通過參數CMSFullGCsBeforeCompaction的值，設置多少次Full GC觸發一次壓縮，默認值為0，代表每次進入Full GC都會觸發壓縮，帶壓縮動作的演算法為上面提到的單執行緒Serial Old演算法，暫停時間(STW)時間非常長，需要儘可能減少壓縮時間

G1原理及調優

1 G1簡介

G1(Garbage-First）是一款面向伺服器的垃圾收集器，支援新生代和老年代空間的垃圾收集，主要針對配備多核處理器及大容量記憶體的機器，G1最主要的設計目標是: 實現可預期及可配置的STW停頓時間

2 G1堆空間劃分

• Region

為實現大記憶體空間的低停頓時間的回收，將劃分為多個大小相等的Region。每個小堆區都可能是 Eden區，Survivor區或者Old區，但是在同一時刻只能屬於某個代

在邏輯上, 所有的Eden區和Survivor區合起來就是新生代，所有的Old區合起來就是老年代，且新生代和老年代各自的記憶體Region區域由G1自動控制，不斷變動

• 巨型對象

當對象大小超過Region的一半，則認為是巨型對象(Humongous Object)，直接被分配到老年代的巨型對象區(Humongous regions)，這些巨型區域是一個連續的區域集，每一個Region中最多有一個巨型對象，巨型對象可以佔多個Region

G1把堆記憶體劃分成一個個Region的意義在於：

• 每次GC不必都去處理整個堆空間，而是每次只處理一部分Region，實現大容量記憶體的GC
• 通過計算每個Region的回收價值，包括回收所需時間、可回收空間，在有限時間內儘可能回收更多的垃圾對象，把垃圾回收造成的停頓時間控制在預期配置的時間範圍內，這也是G1名稱的由來: garbage-first

3 G1工作模式

針對新生代和老年代，G1提供2種GC模式，Young GC和Mixed GC，兩種會導致Stop The World

• Young GC
  當新生代的空間不足時，G1觸發Young GC回收新生代空間
  Young GC主要是對Eden區進行GC，它在Eden空間耗盡時觸發，基於分代回收思想和複製演算法，每次Young GC都會選定所有新生代的Region，同時計算下次Young GC所需的Eden區和Survivor區的空間，動態調整新生代所佔Region個數來控制Young GC開銷

• Mixed GC
  當老年代空間達到閾值會觸發Mixed GC，選定所有新生代里的Region，根據全局並發標記階段(下面介紹到)統計得出收集收益高的若干老年代 Region。在用戶指定的開銷目標範圍內，儘可能選擇收益高的老年代Region進行GC，通過選擇哪些老年代Region和選擇多少Region來控制Mixed GC開銷

4 全局並發標記

全局並發標記主要是為Mixed GC計算找出回收收益較高的Region區域，具體分為5個階段

• 階段 1: 初始標記(Initial Mark)
  暫停所有應用執行緒（STW），並發地進行標記從 GC Root 開始直接可達的對象（原生棧對象、全局對象、JNI 對象），當達到觸發條件時，G1 並不會立即發起並發標記周期，而是等待下一次新生代收集，利用新生代收集的 STW 時間段，完成初始標記，這種方式稱為借道（Piggybacking）

• 階段 2: 根區域掃描（Root Region Scan）
  在初始標記暫停結束後，新生代收集也完成的對象複製到 Survivor 的工作，應用執行緒開始活躍起來；
  此時為了保證標記演算法的正確性，所有新複製到 Survivor 分區的對象，需要找出哪些對象存在對老年代對象的引用，把這些對象標記成根(Root)；
  這個過程稱為根分區掃描（Root Region Scanning），同時掃描的 Suvivor 分區也被稱為根分區（Root Region）；
  根分區掃描必須在下一次新生代垃圾收集啟動前完成（接下來並發標記的過程中，可能會被若干次新生代垃圾收集打斷），因為每次 GC 會產生新的存活對象集合

• 階段 3: 並發標記（Concurrent Marking）
  標記執行緒與應用程式執行緒並行執行，標記各個堆中Region的存活對象資訊，這個步驟可能被新的 Young GC 打斷
  所有的標記任務必須在堆滿前就完成掃描，如果並發標記耗時很長，那麼有可能在並發標記過程中，又經歷了幾次新生代收集

• 階段 4: 再次標記(Remark)
  和CMS類似暫停所有應用執行緒（STW），以完成標記過程短暫地停止應用執行緒, 標記在並發標記階段發生變化的對象，和所有未被標記的存活對象，同時完成存活數據計算

• 階段 5: 清理(Cleanup)
  為即將到來的轉移階段做準備, 此階段也為下一次標記執行所有必需的整理計算工作：
  • 整理更新每個Region各自的RSet(remember set，HashMap結構，記錄有哪些老年代對象指向本Region，key為指向本Region的對象的引用，value為指向本Region的具體Card區域，通過RSet可以確定Region中對象存活資訊，避免全堆掃描)
  • 回收不包含存活對象的Region
  • 統計計算回收收益高（基於釋放空間和暫停目標）的老年代分區集合

5 G1調優注意點

Full GC問題

G1的正常處理流程中沒有Full GC，只有在垃圾回收處理不過來(或者主動觸發)時才會出現， G1的Full GC就是單執行緒執行的Serial old gc，會導致非常長的STW，是調優的重點，需要盡量避免Full GC，常見原因如下：

• 程式主動執行System.gc()
• 全局並發標記期間老年代空間被填滿（併發模式失敗）
• Mixed GC期間老年代空間被填滿（晉陞失敗）
• Young GC時Survivor空間和老年代沒有足夠空間容納存活對象

類似CMS，常見的解決是：

• 增大-XX:ConcGCThreads=n 選項增加並發標記執行緒的數量，或者STW期間並行執行緒的數量：-XX:ParallelGCThreads=n
• 減小-XX:InitiatingHeapOccupancyPercent 提前啟動標記周期
• 增大預留記憶體 -XX:G1ReservePercent=n ，默認值是10，代表使用10%的堆記憶體為預留記憶體，當Survivor區域沒有足夠空間容納新晉陞對象時會嘗試使用預留記憶體

巨型對象分配

巨型對象區中的每個Region中包含一個巨型對象，剩餘空間不再利用，導致空間碎片化，當G1沒有合適空間分配巨型對象時，G1會啟動串列Full GC來釋放空間。可以通過增加 -XX:G1HeapRegionSize來增大Region大小，這樣一來，相當一部分的巨型對象就不再是巨型對象了，而是採用普通的分配方式

不要設置Young區的大小

原因是為了盡量滿足目標停頓時間，邏輯上的Young區會進行動態調整。如果設置了大小，則會覆蓋掉並且會禁用掉對停頓時間的控制

平均響應時間設置

使用應用的平均響應時間作為參考來設置MaxGCPauseMillis，JVM會盡量去滿足該條件，可能是90%的請求或者更多的響應時間在這之內， 但是並不代表是所有的請求都能滿足，平均響應時間設置過小會導致頻繁GC

調優方法與思路

如何分析系統JVM GC運行狀況及合理優化？

GC優化的核心思路在於：儘可能讓對象在新生代中分配和回收，盡量避免過多對象進入老年代，導致對老年代頻繁進行垃圾回收，同時給系統足夠的記憶體減少新生代垃圾回收次數，進行系統分析和優化也是圍繞著這個思路展開

1 分析系統的運行狀況

• 系統每秒請求數、每個請求創建多少對象，佔用多少記憶體
• Young GC觸發頻率、對象進入老年代的速率
• 老年代佔用記憶體、Full GC觸發頻率、Full GC觸發的原因、長時間Full GC的原因

常用工具如下：

• jstat
  jvm自帶命令行工具，可用於統計記憶體分配速率、GC次數，GC耗時，常用命令格式

jstat -gc <pid> <統計間隔時間>  <統計次數>

輸出返回值代表含義如下：

例如： jstat -gc 32683 1000 10 ，統計pid=32683的進程，每秒統計1次，統計10次

• jmap
  jvm自帶命令行工具，可用於了解系統運行時的對象分布，常用命令格式如下

// 命令行輸出類名、類數量數量，類佔用記憶體大小，  // 按照類佔用記憶體大小降序排列  jmap -histo <pid>    // 生成堆記憶體轉儲快照，在當前目錄下導出dump.hrpof的二進位文件，  // 可以用eclipse的MAT圖形化工具分析  jmap -dump:live,format=b,file=dump.hprof <pid>

• jinfo
  命令格式

jinfo <pid> 

用來查看正在運行的 Java 應用程式的擴展參數，包括Java System屬性和JVM命令行參數

其他GC工具

• 監控告警系統：Zabbix、Prometheus、Open-Falcon
• jdk自動實時記憶體監控工具：VisualVM
• 堆外記憶體監控： Java VisualVM安裝Buffer Pools 插件、google perf工具、Java NMT(Native Memory Tracking)工具
• GC日誌分析：GCViewer、gceasy
• GC參數檢查和優化：http://xxfox.perfma.com/

2 GC優化案例

• 數據分析平台系統頻繁Full GC

平台主要對用戶在APP中行為進行定時分析統計，並支援報表導出，使用CMS GC演算法。數據分析師在使用中發現系統頁面打開經常卡頓，通過jstat命令發現系統每次Young GC後大約有10%的存活對象進入老年代。

原來是因為Survivor區空間設置過小，每次Young GC後存活對象在Survivor區域放不下，提前進入老年代，通過調大Survivor區，使得Survivor區可以容納Young GC後存活對象，對象在Survivor區經歷多次Young GC達到年齡閾值才進入老年代，調整之後每次Young GC後進入老年代的存活對象穩定運行時僅幾百Kb，Full GC頻率大大降低

• 業務對接網關OOM

網關主要消費Kafka數據，進行數據處理計算然後轉發到另外的Kafka隊列，系統運行幾個小時候出現OOM，重啟系統幾個小時之後又OOM，通過jmap導出堆記憶體，在eclipse MAT工具分析才找出原因：程式碼中將某個業務Kafka的topic數據進行日誌非同步列印，該業務數據量較大，大量對象堆積在記憶體中等待被列印，導致OOM

• 帳號許可權管理系統頻繁長時間Full GC

系統對外提供各種帳號鑒權服務，使用時發現系統經常服務不可用，通過Zabbix的監控平台監控發現系統頻繁發生長時間Full GC，且觸發時老年代的堆記憶體通常並沒有佔滿，發現原來是業務程式碼中調用了System.gc()

總結

GC問題可以說沒有捷徑，排查線上的性能問題本身就並不簡單，除了將本文介紹到的原理和工具融會貫通，還需要我們不斷去積累經驗，真正做到性能最優

篇幅所限，不再展開介紹常見GC參數的使用，我發布在github：https://github.com/caison/caison-blog-demo

參考

《Java Performance: The Definitive Guide》 Scott Oaks

《深入理解 Java 虛擬機：JVM 高級特性與最佳實踐（第二版》 周志華

Java性能調優實戰

Getting Started with the G1 Garbage Collector

GC參考手冊-Java版

請教G1演算法的原理——RednaxelaFX的回答

Java Hotspot G1 GC的一些關鍵技術——美團技術團隊