G1垃圾回收器：Java大内存应用性能优化实践

1. G1垃圾回收器：现代Java应用的性能救星

第一次接触G1（Garbage-First）是在2017年处理一个电商大促预案时，当时我们的CMS回收器在堆内存超过6GB后频繁出现并发模式失败。切换到G1后不仅解决了问题，还将GC停顿时间控制在200ms以内。作为JDK 9及以后版本的默认垃圾回收器，G1通过创新的Region内存布局和可预测的停顿时间模型，彻底改变了传统垃圾回收器的工作方式。

G1的核心设计目标很明确：在大内存（4GB以上）场景下，以可控的停顿时间（通常100-500ms）实现高吞吐量。与Parallel Old的"全堆压缩"和CMS的"老年代标记清除"不同，G1将堆划分为2048个左右的等大小Region（默认约2MB），每个Region可以是Eden、Survivor或Old区。这种设计带来三个革命性优势：

1. 并行与并发结合的回收策略：年轻代回收（Young GC）完全并行，而混合回收（Mixed GC）可以并发执行
2. 增量式压缩：通过每次回收部分Region来避免全堆压缩导致的长时间停顿
3. 停顿时间预测：基于Region回收成本的历史数据，精确控制每次GC的耗时

关键提示：G1的Region大小通过-XX:G1HeapRegionSize指定，建议保持默认值（堆大小/2048），过小的Region会导致记忆集膨胀，过大会降低停顿时间精度

2. Region划分：内存管理的乐高积木

2.1 Region的动态角色分配

在传统的分代垃圾回收器中，内存空间被静态划分为固定的年轻代和老年代。而G1的每个Region都可以在运行时动态改变身份：

// 通过HotSpot源码看Region类型定义（摘自g1HeapRegion.hpp） enum RegionType { Free, // 未分配区域 Eden, // 年轻代Eden区 Survivor, // 年轻代Survivor区 Old, // 老年代 Humongous, // 巨型对象区 Archive, // 存档区域（CDS特性） G1EdenSurvivor // 过渡状态 };

当应用申请内存时，G1会优先从Free Region分配。对于普通对象（小于Region一半大小），会被分配到Eden Region；超过Region 50%的大对象则进入Humongous Region（可能连续占用多个Region）。这种设计带来两个显著优势：

1. 内存利用率提升：不再有年轻代/老年代的固定比例限制（-XX:NewRatio失效），完全根据GC效率动态调整
2. 巨型对象处理优化：连续分配的Humongous Region避免了传统回收器中大对象导致的提前晋升问题

2.2 跨代引用与记忆集（Remembered Set）

每个Region都附带一个记忆集（Remembered Set），用于记录其他Region对该Region内对象的引用。这种设计解决了跨代引用的扫描难题：

Region A (Old) -> 对象X Region B (Eden) -> 引用对象X

在年轻代回收时，传统回收器需要扫描整个老年代找跨代引用，而G1只需检查Eden Region对应的记忆集。记忆集实现采用卡表（Card Table）的变体：

1. 每个Region被划分为512字节的卡页（Card）
2. 写屏障（Write Barrier）在对象引用更新时标记脏卡
3. 并行线程定期扫描脏卡，更新记忆集

避坑指南：记忆集可能占用堆大小的10-20%，对于超大堆建议调整-XX:G1RSetUpdatingPauseTimePercent（默认10%）控制更新耗时

3. 混合回收：G1的核心回收策略

3.1 回收阶段全景图

G1的回收过程分为三个主要阶段，形成完整的闭环：

1. 年轻代回收（Young GC）

   • 触发条件：Eden区耗尽
   • 过程：完全STW的并行标记-复制，存活对象转移到Survivor或Old Region
   • 特点：只处理年轻代Region，依赖记忆集避免全堆扫描

2. 并发标记周期（Concurrent Cycle）

   • 触发条件：堆占用超过IHOP阈值（-XX:InitiatingHeapOccupancyPercent，默认45%）
   • 过程：
     • 初始标记（Initial Mark）：STW，与Young GC同步进行
     • 根区域扫描（Root Region Scan）：并发扫描Survivor Region
     • 并发标记（Concurrent Mark）：与应用线程并行
     • 最终标记（Remark）：STW，处理SATB（Snapshot-At-The-Beginning）队列
     • 清理（Cleanup）：STW，统计存活对象最多的Region

3. 混合回收（Mixed GC）

   • 触发条件：并发标记周期完成后
   • 特点：同时回收年轻代和有价值的老年代Region（根据回收效益排序）
   • 目标：逐步将堆占用降到-XX:G1HeapWastePercent（默认5%）以下

3.2 停顿时间预测机制

G1通过历史数据预测每次回收的耗时，核心参数是：

• -XX:MaxGCPauseMillis（默认200ms）：目标最大停顿时间
• -XX:GCPauseIntervalMillis（可选）：期望的GC间隔

预测算法主要考虑：

1. Region存活对象比例（通过并发标记获得）
2. 复制单个Region的历史耗时
3. 记忆集处理成本

实际工作中，我通过以下JVM参数优化预测精度：

-XX:G1ReservePercent=10 # 保留内存应对晋升失败 -XX:G1ConcRefinementThreads=4 # 并发记忆集更新线程

4. 实战调优：从理论到落地

4.1 关键参数速查表

4.2 典型问题排查指南

问题1：并发模式失败（Concurrent Mode Failure）

• 现象：GC日志出现"Evacuation Failure"或"To-space exhausted"
• 原因：混合回收速度跟不上对象分配速率
• 解决方案：
  • 增加-XX:ConcGCThreads提升并发标记速度
  • 降低-XX:InitiatingHeapOccupancyPercent提前触发并发标记
  • 增加-XX:G1ReservePercent预留更多内存

问题2：记忆集占用过高

• 现象：堆内存充足但频繁Full GC，GC日志显示"Remembered Sets"占用大
• 原因：跨Region引用过多
• 解决方案：
  • 检查业务代码避免过度使用全局集合
  • 调整-XX:G1RSetUpdatingPauseTimePercent限制记忆集更新时间
  • 考虑增大Region大小（减少Region总数）

问题3：长时间停顿（>1s）

• 现象：个别GC事件远超MaxGCPauseMillis
• 原因：Humongous对象分配或系统调用干扰
• 解决方案：
  • 添加-XX:+PrintGCDetails分析停顿阶段
  • 使用-XX:+G1SummarizeRSetStats检查记忆集状态
  • 考虑禁用Linux透明大页（THP）

5. 进阶技巧：超越默认配置

5.1 巨型对象优化策略

对于频繁分配大对象（如缓存系统）的场景，建议：

-XX:G1HeapRegionSize=4M # 增大Region减少Humongous对象 -XX:G1EagerReclaimHumongousObjects=true # 主动回收巨型对象 -XX:G1EagerReclaimHumongousObjectsWithStaleRefs=true # 回收无引用巨型对象

5.2 日志分析与可视化

推荐GC日志配置：

-Xlog:gc*=debug:file=gc.log:time,uptime,level,tags:filecount=10,filesize=50M

使用工具链分析：

1. GCViewer：可视化停顿时间和吞吐量
2. JClarity Censum：专业GC日志分析
3. Grafana + Prometheus：实时监控GC指标

5.3 与ZGC的对比选择

在JDK 17+环境中，对于超大规模堆（>100GB）且要求亚毫秒停顿的应用，建议评估ZGC。但G1在成熟度和调优灵活性上仍有优势