1. 项目概述
G1垃圾回收器（Garbage-First）作为JVM新一代垃圾回收器的代表，从JDK7开始引入，到JDK9成为默认垃圾回收器，其设计理念和实现机制与传统的CMS、Parallel等回收器有着本质区别。我在生产环境调优过程中发现，很多开发者虽然知道G1的基本概念，但对Region划分、Mixed GC、Remembered Set等核心机制的理解仍停留在表面。本文将结合我处理过的真实性能案例，带你看透G1从对象分配到回收触发的完整生命周期。
2. 核心设计原理
2.1 分区模型与堆内存布局
G1将堆划分为2048个大小相等的Region（默认值，可通过-XX:G1HeapRegionSize调整），每个Region可以是Eden、Survivor或Old区。这种设计带来三个关键特性：
动态角色转换：Region的类型会随着GC过程动态变化。比如在一次Young GC后，存活的Eden Region会变成Survivor Region，而部分Survivor Region可能晋升为Old Region。
大对象专属处理：超过Region大小50%的对象会被直接放入Humongous Region（特殊Old Region）。我在某电商系统就遇到过因大数组分配不当导致Humongous Region碎片化的问题。
回收优先级计算：G1会根据各个Region的回收价值（可释放空间大小/回收所需时间）构建优先级队列，这也是"Garbage-First"名称的由来。
2.2 跨代引用与记忆集
传统分代GC面临的跨代引用问题，在G1中通过Remembered Set（记忆集）解决。每个Region都有自己的Remembered Set，记录其他Region对当前Region的引用。具体实现采用：
- 精细粒度记录：使用PerRegionTable存储引用信息，通过哈希表避免重复记录
- 写前屏障维护：在对象引用修改前插入的代码片段（如HotSpot的G1SATBCardTableModRefBS）
- 并行处理优化：通过-XX:G1ConcRefinementThreads控制并发 refinement线程数
重要提示：过大的Remembered Set会显著增加内存占用，我曾遇到一个20GB堆的系统中Remembered Set占用超过1.5GB的情况，需要通过-XX:G1RSetUpdatingPauseTimePercent调整维护开销。
3. 垃圾回收过程详解
3.1 Young GC触发机制
当Eden区占用达到-XX:G1NewSizePercent设定的阈值时（默认5%），触发Young GC。其执行流程为：
- 根扫描：遍历GC Roots（栈引用、全局变量等）
- 标记存活对象：使用三色标记算法（后续详述）
- 对象拷贝：存活对象被拷贝到Survivor Region（或直接晋升到Old）
- Region回收：清空原Eden/Survivor Region加入空闲列表
关键参数调节建议：
- -XX:MaxGCPauseMillis：目标暂停时间（默认200ms）
- -XX:G1NewSizePercent：年轻代最小占比（动态调整下限）
- -XX:G1MaxNewSizePercent：年轻代最大占比（默认60%）
3.2 Mixed GC运作流程
当老年代占用超过-XX:InitiatingHeapOccupancyPercent（默认45%）时，启动并发标记周期，随后触发Mixed GC（混合回收）。这个过程的四个阶段值得特别关注：
- 初始标记（Initial Mark）：STW阶段，标记从GC Roots直接可达的对象
- 并发标记（Concurrent Mark）：与应用线程并发执行，完成全堆标记
- 最终标记（Remark）：STW阶段，处理SATB（Snapshot-At-The-Beginning）记录
- 清理（Cleanup）：统计各Region存活对象，决定回收列表
在某个金融系统中，我们通过调整-XX:G1MixedGCLiveThresholdPercent（默认85%）避免回收存活率过高的Region，使GC效率提升30%。
4. 关键算法实现
4.1 三色标记与SATB
G1采用三色标记法（白/灰/黑）进行可达性分析，配合SATB机制解决"对象消失"问题：
- 白色：未访问对象
- 灰色：已访问但子引用未处理
- 黑色：已访问且子引用处理完成
SATB（Snapshot-At-The-Beginning）通过在并发标记开始时创建对象图快照，确保标记完整性。具体实现依赖：
- 前置写屏障：在引用修改前将原引用记录到线程本地缓冲区（SATBMarkQueue）
- 全局队列处理：当线程本地缓冲区满时，转移到全局队列
- 标记阶段消费：在最终标记阶段处理这些记录
4.2 回收选择算法
G1采用基于效率的回收选择策略，计算公式为：
回收优先级 = 可回收空间 / 预计回收时间其中回收时间估算考虑：
- 对象拷贝开销
- Remembered Set处理成本
- 跨Region引用复杂度
在日志分析系统调优时，我们通过-XX:G1MixedGCCountTarget增加Mixed GC次数（默认8次），使每次回收的Region数量更均匀，避免出现长时间停顿。
5. 性能调优实战
5.1 参数配置黄金法则
根据数十个生产系统调优经验，总结出以下配置原则：
- 暂停时间目标：-XX:MaxGCPauseMillis设为应用可容忍值的70%-80%
- 并发线程数：-XX:ConcGCThreads=可用CPU核数的1/4
- IHOP自适应：开启-XX:G1UseAdaptiveIHOP优化老年代触发阈值
- 大对象预警：监控Humongous Region占比，超过10%需优化对象分配
5.2 典型问题排查指南
案例1：长时间并发标记现象：并发标记阶段耗时超过5秒 排查步骤：
- 检查-XX:G1ConcRefinementThreads是否足够
- 分析jstat -gc输出中RG队列是否积压
- 确认是否有大量大对象分配
案例2：Mixed GC效果差现象：老年代占用持续增长但回收空间有限 解决方案：
- 降低-XX:G1MixedGCLiveThresholdPercent（建议65%）
- 增加-XX:G1HeapWastePercent（默认5%→10%）
- 检查是否有内存泄漏
6. 监控与工具链
6.1 关键指标监控项
通过JMX或jstat监控这些核心指标：
| 指标名称 | 监控命令 | 健康阈值 |
|---|---|---|
| 老年代占比 | jstat -gc 老年代容量 | <IHOP阈值-10% |
| Humongous分配数 | jcmd GC.humongous_stats | <总Region数5% |
| Remembered Set大小 | jcmd GC.remembered_sets | <堆内存5% |
| 并发标记耗时 | GC日志中ConcurrentMark | <MaxGCPauseMillis×3 |
6.2 GC日志分析技巧
启用详细日志记录：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M使用GCViewer或GCEasy分析时重点关注：
- Pause Time分布：识别异常长停顿
- 回收效率曲线：观察各阶段时间占比
- 晋升速率：Young→Old的对象量变化趋势
在最近一个物联网平台项目中，通过分析GC日志发现对象晋升过早的问题，调整-XX:G1ReservePercent（默认10%→15%）后，Young GC频率降低40%。
7. 进阶优化策略
7.1 字符串去重优化
G1提供字符串去重功能（需手动开启）：
-XX:+UseStringDeduplication -XX:StringDeduplicationAgeThreshold=3实现原理：
- 后台线程扫描新生代存活字符串
- 对char[]内容计算哈希值
- 通过哈希表查找重复内容
- 重定向引用指向单一副本
某社交应用启用该功能后，节省了约12%的堆内存。
7.2 区域化内存管理
对于多租户系统，可通过以下方式实现隔离：
- 使用-XX:G1HeapRegionSize设置更大Region（如16MB）
- 通过JVMTI API动态设置Region属性
- 结合-XX:SoftRefLRUPolicyMSPerMB控制软引用回收
这种方案在某SaaS平台中实现了租户间GC影响隔离，使99%的GC停顿控制在50ms内。
