深入解析 G1 垃圾回收器：Region、Remembered Set 与 Mixed GC 全揭秘（附 CMS 对比）-育师

在 Java 高并发、大内存应用中，垃圾回收（GC）性能直接影响系统稳定性与用户体验。从 JDK 9 开始，G1（Garbage-First）成为默认垃圾回收器，取代了曾经的 CMS。那么，G1 到底强在哪里？它是如何做到低停顿、高吞吐、避免内存碎片的？

本文将用通俗语言 + 图解思维 + 实战配置，带你彻底搞懂 G1 的核心机制，并对比 CMS，让你明白为什么 G1 是现代 Java 应用的首选！

一、为什么需要 G1？传统回收器的痛点

在 G1 出现前，主流回收器有：

Parallel GC：吞吐量高，但 Full GC 停顿时间长（秒级），不适合低延迟场景。
CMS（Concurrent Mark-Sweep）：并发回收，停顿短，但存在严重内存碎片，且无法预测停顿时间。

🎯G1 的设计目标：
可预测的停顿时间（如 ≤ 200ms）
高吞吐
避免内存碎片
适用于大堆内存（4GB~TB 级）

二、G1 的核心思想：化整为零 —— Region 划分

✅ 什么是 Region？

G1 将整个堆内存划分为多个大小相等的 Region（默认约 2048 个，每个 1~32MB，由堆大小决定）。

[ Eden ] [ Eden ] [ Survivor ] [ Old ] [ Humongous ] ...

Eden Region：新对象分配
Survivor Region：Young GC 后存活的对象
Old Region：长期存活对象
Humongous Region：存储超大对象（> Region 50%），可能占用连续多个 Region

💡 关键突破：不再区分连续的新生代/老年代空间，而是用逻辑标签标记 Region 角色。

🔍 Region 的优势

回收时只选择部分 Region（“Garbage-First”），而非整个老年代
可灵活控制回收范围，实现停顿时间可预测

三、跨代引用难题：Remembered Set（RSet）的作用

❓ 问题：如何高效追踪 Old → Young 的引用？

在分代 GC 中，Young GC 需要知道哪些 Old 对象引用了 Young 对象（否则会误删）。传统方案需扫描整个老年代，代价巨大。

✅ G1 的解决方案：Remembered Set（RSet）

每个 Region 都有一个 RSet
RSet 记录其他 Region 中指向本 Region 的对象卡表（Card Table）索引
Young GC 时，只需扫描Eden/Survivor Region 的 RSet，无需遍历整个 Old 区

Region A (Old) ────引用───→ Region B (Eden) ↓ RSet of B: 记录 "Region A, Card #123"

⚡ 效果：Young GC 停顿时间与堆大小无关，只与活跃对象数和 RSet 大小相关！

四、G1 垃圾回收的两大阶段

1️⃣ Young GC（年轻代回收）

触发条件：Eden 区满

过程：

暂停所有应用线程（STW）
扫描Eden + Survivor Region
将存活对象复制到新的 Survivor 或 Old Region
清空原 Eden/Survivor Region，变为空闲 Region

✅ 特点：

停顿时间短（通常几十毫秒）
使用复制算法，无碎片

2️⃣ Mixed GC（混合回收）

触发条件：

完成一次并发标记周期（Concurrent Marking Cycle）
老年代占用达到IHOP（Initiating Heap Occupancy Percent，默认 45%）

过程：

并发标记阶段（与应用并发执行）：
- 初始标记（STW）
- 并发标记（遍历对象图）
- 最终标记（STW，修正并发期间变化）
Mixed GC 阶段（多次 STW）：
- 选择垃圾比例最高的若干 Old Region + 所有 Young Region
- 复制存活对象，释放空间

✅ 关键：优先回收垃圾最多的 Region（“Garbage-First” 名字来源）

📊 G1 通过-XX:G1MixedGCCountTarget（默认 8）控制 Mixed GC 次数，逐步清理老年代。

五、G1 vs CMS：两大关键改进

维度	CMS	G1	G1 的优势
内存碎片	使用标记-清除算法，产生大量碎片，可能导致 Full GC	使用复制算法，回收后 Region 完全清空，无碎片	✅ 避免因碎片触发 Full GC
停顿时间预测	无法预测，Concurrent Mode Failure 时退化为 Serial GC（秒级停顿）	通过Region 选择 + 停顿预测模型，可设置`-XX:MaxGCPauseMillis=200`（目标值）	✅可预测、可控的低延迟

🌰 举例说明

CMS 场景：
老年代碎片化严重 → 即使总空闲空间足够，也无法分配大对象 → 触发 Full GC → 应用停顿 2 秒！
G1 场景：
每次 Mixed GC 都整理内存 → Region 始终紧凑 → 大对象可直接分配到 Humongous Region →永不因碎片 Full GC！

六、Spring Boot 应用 G1 调优建议（实战配置）

# application-prod.yml（JVM 参数建议） java: opts: > -server -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 # 目标停顿时间 -XX:G1HeapRegionSize=4m # 显式设置 Region 大小（可选） -XX:G1NewSizePercent=20 # Eden 最小占比 -XX:G1MaxNewSizePercent=40 # Eden 最大占比 -XX:G1ReservePercent=10 # 保留内存防晋升失败 -XX:G1HeapWastePercent=5 # 允许浪费的堆比例 -XX:+G1PrintRegionLivenessInfo # 打印 Region 存活信息（调试用）

💡调优口诀：
“设目标停顿，控 Region 选择，防晋升失败，避 Humongous 滥用”

七、反例警示：这些用法会让 G1 性能暴跌！

❌ 反例1：堆太小（< 4GB）

G1 适合大堆，小堆下 Region 管理开销反而高于 Parallel GC。

✅ 建议：堆 ≥ 4GB 再考虑 G1。

❌ 反例2：频繁创建超大对象

// 错误！每次 new byte[100 * 1024 * 1024]（100MB） byte[] huge = new byte[100_000_000];

→ 触发Humongous Allocation，占用多个连续 Region，回收效率低。

✅ 建议：复用缓冲区，或使用堆外内存（如 Netty ByteBuf）。

❌ 反例3：忽略 IHOP 导致 Mixed GC 延迟

默认IHOP=45%，若老年代增长快，可能来不及回收就 OOM。

✅ 调优：

-XX:InitiatingHeapOccupancyPercent=30 # 提前触发并发标记

八、总结：G1 为何成为现代 Java 默认 GC？

特性	G1 实现方式
低停顿	分 Region 回收 + 停顿预测模型
无碎片	复制算法 + Region 整体释放
大堆友好	并发标记 + 混合回收
可配置性强	通过`MaxGCPauseMillis`等参数灵活调优