在 Java 應用的運行中，垃圾回收（GC）是保障內存安全的核心機制，但傳統 GC 如 CMS 和 Parallel GC 常面臨兩大痛點：不可控的停頓時間和內存碎片問題。

例如，CMS 的“并發模式失敗”可能導致長達數秒的 Full GC 停頓，而大內存場景下頻繁的 Young GC 和 Mixed GC 可能拖累吞吐量。

G1（Garbage-First）垃圾回收器應運而生，它以“可控的停頓時間”為核心設計目標，通過分區（Region）模型和智能回收策略，實現了低延遲與高吞吐的平衡。

本文將從設計思想、核心機制到實戰調優，帶你深入理解 G1 如何解決傳統 GC 的難題。

G1 分區模型

Region 分區模型

G1 將堆內存劃分為多個等大小的 Region（默認 1MB-32MB），每個 Region 可以是 Eden、Survivor 或 Old 區，默認是將堆內存按照 2048 份均分。

這種靈活的分區方式打破了傳統代際的物理隔離，允許動態調整各代內存占比。

Region 的角色（年輕代、老年代或大對象區）是動態分配的。例如，一個 Region 可能初始作為 Eden 區，回收后被標記為 Survivor 區，后續可能轉為老年代區。

大對象（Humongous 對象）：若對象大小超過 Region 的 50%，則分配到連續的 Humongous Region。此類對象回收需特殊處理，若空間不足可能觸發 Full GC。

例如，當老年代占用過高時，G1 會優先回收垃圾最多的 Region，而非全堆掃描。

跨代引用的智能追蹤

卡表（Card Table）：記錄跨 Region 的引用關系。例如，老年代對象引用年輕代對象時，對應的卡表條目會被標記為“臟卡”。

記憶集（RSet）：每個 Region 維護一個 RSet，存儲其他 Region 對其內部對象的引用。通過 RSet 快速定位跨 Region 引用，避免全堆掃描。

寫屏障（Write Barrier）：在對象引用修改時觸發，更新卡表和 RSet。例如，當老年代對象引用新生代對象時，寫屏障會記錄該引用。

混合回收（Mixed GC）

混合回收是 G1 的精髓：在一次回收中，同時處理年輕代和老年代的 Region。

通過計算回收收益（垃圾量/耗時），G1 選擇性價比最高的 Region 集合（Collection Set），在用戶設定的最大停頓時間內（如 200ms）完成回收。

在邏輯上，G1 分為年輕代和老年代，但它的年輕代和老年代比例，并不是那么“固定”，為了達到 MaxGCPauseMillis 所規定的效果，G1 會自動調整兩者之間的比例。

如果你強行使用 -Xmn 或者 -XX:NewRatio 去設定它們的比例的話，我們給 G1 設定的這個目標將會失效。

G1 的回收過程主要分為 3 類：

1. G1“年輕代”的垃圾回收，同樣叫 Minor GC，這個過程和我們前面描述的類似，發生時機就是 Eden 區滿的時候。
2. 老年代的垃圾收集，嚴格上來說其實不算是收集，它是一個“并發標記”的過程，順便清理了一點點對象。
3. 真正的清理，發生在“混合模式”，它不止清理年輕代，還會將老年代的一部分區域進行清理。

年輕代回收（Young GC）

Chaya：年輕代回收觸發流程是什么？

Eden 區占滿時觸發，僅回收年輕代 Region。回收流程如下所示：

• 根掃描：標記 GC Roots 直接可達的對象（如棧幀局部變量、靜態變量）。
• RSet 處理：通過臟卡隊列更新 RSet，將老年代對年輕代的引用加入 GC Roots。
• 復制存活對象：將 Eden 和 Survivor 區的存活對象復制到新 Survivor 區，年齡達閾值（默認 15）則晉升老年代。
• 這個過程通常是 Stop-The-World（STW）的，即在回收過程中，應用程序的其他線程會被暫停。

混合回收（Mixed GC）

Chaya：混合回收的觸發條件是什么？

多次回收之后，會出現很多 Old 老年代區，此時總堆占有率達到閾值（默認 45%）時會觸發混合回收 MixedGC。混合回收會回收 整個年輕代 + 部分老年代。

回收過程如下：

• 初始標記（STW）：標記 GC Roots 直接可達對象，耗時短。
• 并發標記：與應用線程并行，遍歷堆標記存活對象，使用三色標記法（黑、灰、白）避免漏標。
• 重新（最終）標記（STW）：處理并發標記期間引用變化（通過 SATB 算法保證一致性），修正標記結果。
• 篩選回收：根據 Region 的回收價值（垃圾占比與回收時間）選擇 Region 集合（Collection Set），復制存活對象并清理。

注意：當混合回收無法快速釋放足夠空間時觸發 Full GC（如大對象分配失敗），采用單線程標記-整理算法，導致長停頓。

初始標記

初始標記會暫停所有用戶線程，只標記從 GC Root 可直達的對象，所以停頓時間不會太長。

采用三色標記法進行標記，三色標記法在原有雙色標記（黑也就是 1 代表存活，白 0 代表可回收）增加了一種灰色。

三色標記法

• 黑色：對象及其引用均完成標記。
• 灰色：對象已標記，但引用未完全處理。
• 白色：未標記或待回收對象。
• 漏標問題解決：通過 SATB（Snapshot-At-The-Beginning）機制，記錄并發標記開始時的對象快照，確保標記一致性

并發標記

默認線程數為ParallelGCThreads的 1/4（通過-XX:ConcGCThreads調整），減少應用線程阻塞。

允許系統程序的運行，同時進行"GC Roots"追蹤，追蹤所有存活對象(間接引用的對象)。該階段很耗時，因為要追蹤全部的存活對象。但是是并發運行，對系統影響不大。

GC 開始前所有對象都是白色，GC 一開始所有根能夠直達的對象被壓到棧中，待搜索，此時顏色是灰色。

然后灰色對象依次從棧中取出搜索子對象，子對象也會被涂為灰色，入棧。

當其所有的子對象都涂為灰色之后該對象被涂為黑色。

當 GC 結束之后灰色對象將全部沒了，剩下黑色的為存活對象，白色的為垃圾。

需要注意的是：由于用戶線程可能同時在修改對象的引用關系，就會出現錯標的情況。

Chaya:那咋辦呢？

G1 為了解決這個問題，使用了SATB 技術（Snapshot At The Beginning， 初始快照）。

在并發標記開始時，G1 會創建一個堆內存的快照，記錄所有存活對象的初始狀態。

在最終標記階段，系統會處理并發期間新增的引用變化，通過寫前屏障（Write Barrier）記錄這些變化，確保新對象不被錯誤回收。

最終標記

觸發時機：在并發標記（Concurrent Marking）完成后，G1 需要暫停所有應用線程（STW），以處理并發標記期間遺漏的引用變化，確保標記結果的準確性。

核心目標：修正并發標記階段因應用線程并發執行導致的對象引用變化（如新對象創建或引用更新），并生成最終的存活對象快照。

處理漏標對象：通過遍歷卡表（Card Table）中的“臟頁”（記錄引用修改的區域），重新掃描這些區域的對象，修正標記狀態

篩選回收

最終標記完成后，G1 根據停頓時間目標（MaxGCPauseMillis）和Region 回收價值，選擇最合適的區域進行回收。

優先回收垃圾比例高（存活對象少）的 Region，以最小化回收時間并最大化內存釋放效率。

根據每個 Region 的存活對象數量和回收時間成本計算“回收價值”，優先選擇存活率低、回收效率高的 Region 組成回收集（Collection Set, CSet）。

標記-復制算法：將存活對象從回收集的 Region 復制到空閑 Region，同時整理內存以減少碎片。

主要步驟如下所示：

構建回收集（CSet）：

• 根據 Region 的存活對象比例和用戶設定的停頓時間目標（如-XX:MaxGCPauseMillis），動態選擇需要回收的 Region。
• 通常包括所有年輕代 Region（Eden/Survivor）和部分老年代 Region（混合收集模式）

并行遷移存活對象：

• 暫停應用線程（STW），啟動多個 GC 線程并行執行。
• 將回收集內的存活對象復制到空閑 Region（如 Survivor 區或 Old 區的新 Region），并更新對象引用指針。

清理與釋放內存:

• 清空原 Region 的所有內容，將其標記為“空閑區域”。
• 更新Remembered Set（RSet）和卡表，記錄跨 Region 引用的變化。

調優策略與參數

案例一：年輕代配置

案例：某線上服務因誤設-Xmn256m覆蓋 G1 的自動調節，導致 Eden 區過小（僅 256MB），頻繁觸發 Young GC（600+次/壓測），響應時間激增。

解決方案：刪除-Xmn參數，由 G1 根據G1NewSizePercent（默認 5%）和G1MaxNewSizePercent（默認 60%）動態調整新生代大小，GC 時間從 25 秒降至 1 秒內。

案例二：老年代“擁堵治理”

動態年齡判定：若 Survivor 區使用超過 50%（TargetSurvivorRatio默認值），對象會直接晉升老年代。需通過增大 Survivor 區或降低晉升閾值（MaxTenuringThreshold），避免過早“占道”。

混合回收觸發閾值：默認InitiatingHeapOccupancyPercent=45%（老年代占比），高并發場景可適度調低以提前回收，避免 Full GC。

大對象“專車配送”

大對象（超過 Region 50%）直接進入老年代，類似超重訂單需特殊車輛處理。通過G1HeapRegionSize調整 Region 大小（如 32MB），或設置PretenureSizeThreshold控制大對象閾值，減少內存碎片。

Full GC 的應急處理

內存不足：堆內存過小或老年代晉升過快，需檢查-Xmx/-Xms是否一致（建議設為物理內存 75%-80%）。

并發失敗：若 Mixed GC 無法及時回收，觸發 Full GC，需優化MaxGCPauseMillis或降低InitiatingHeapOccupancyPercent。

啟用 GC 日志：-XX:+PrintGCDetails -Xloggc:/path/gc.log，關注Full GC關鍵字及耗時。

關鍵調優參數

• -XX:MaxGCPauseMillis：設定最大停頓時間（默認 200ms），G1 根據此目標動態調整回收 Region 數量.
• -XX:G1HeapRegionSize：手動指定 Region 大小（需為 2 的冪次方）。
• -XX:G1MixedGCCountTarget：控制混合回收次數（默認 8 次），分批次回收老年代 Region 以減少單次停頓。
• -XX:G1ReservePercent：預留堆內存（默認 10%）防止晉升失敗。

總結

G1 是一款非常優秀的垃圾收集器，不僅適合堆內存大的應用，同時也簡化了調優的工作。通過主要的參數初始和最大堆空間、以及最大容忍的 GC 暫停目標，就能得到不錯的性能；同時，我們也看到 G1 對內存空間的浪費較高，但通過首先收集盡可能多的垃圾(Garbage First)的設計原則，可以及時發現過期對象，從而讓內存占用處于合理的水平。

雖然 G1 也有類似 CMS 的收集動作：初始標記、并發標記、重新標記、清除、轉移回收，并且也以一個串行收集器做擔保機制，但單純地以類似前三種的過程描述顯得并不是很妥當。

• G1 的設計原則是"首先收集盡可能多的垃圾(Garbage First)"。因此，G1 并不會等內存耗盡(串行、并行)或者快耗盡(CMS)的時候開始垃圾收集，而是在內部采用了啟發式算法，在老年代找出具有高收集收益的分區進行收集。同時 G1 可以根據用戶設置的暫停時間目標自動調整年輕代和總堆大小，暫停目標越短年輕代空間越小、總空間就越大；
• G1 采用內存分區(Region)的思路，將內存劃分為一個個相等大小的內存分區，回收時則以分區為單位進行回收，存活的對象復制到另一個空閑分區中。由于都是以相等大小的分區為單位進行操作，因此 G1 天然就是一種壓縮方案(局部壓縮)；
• G1 雖然也是分代收集器，但整個內存分區不存在物理上的年輕代與老年代的區別，也不需要完全獨立的 survivor(to space)堆做復制準備。G1 只有邏輯上的分代概念，或者說每個分區都可能隨 G1 的運行在不同代之間前后切換；
• G1 的收集都是 STW 的，但年輕代和老年代的收集界限比較模糊，采用了混合(mixed)收集的方式。即每次收集既可能只收集年輕代分區(年輕代收集)，也可能在收集年輕代的同時，包含部分老年代分區(混合收集)，這樣即使堆內存很大時，也可以限制收集范圍，從而降低停頓。