在 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等参数灵活调优 |
🚀一句话总结：
G1 把“不可控的大扫除”变成了“可计划的小范围整理”，既保证了效率，又稳住了停顿！
视频看了几百小时还迷糊？关注我，几分钟让你秒懂！（发点评论可以给博主加热度哦）
