故小里1. G1垃圾回收器概述：面向服务端应用的新一代收集器
G1（Garbage-First）是JDK 7中首次引入的垃圾回收器，在JDK 9中成为默认收集器。与传统的分代收集器不同，G1采用了一种全新的内存布局和回收策略，专门针对具有大内存、多处理器硬件的服务端应用设计。我在实际生产环境中的性能调优经验表明，当堆内存超过4GB且要求延迟可控时，G1相比CMS和Parallel Old等传统收集器通常能展现出明显优势。
G1的核心设计目标是：在保证高吞吐量的同时，尽可能降低停顿时间（通常控制在几百毫秒内）。它通过将堆划分为多个大小相等的Region（区域），并优先回收垃圾最多的区域（Garbage-First名称的由来）来实现这一目标。这种设计使得G1能够避免全堆回收，同时提供可预测的停顿时间模型。
注意：虽然G1在JDK 9后成为默认收集器，但并不意味着它适合所有场景。对于堆内存小于4GB的应用，Parallel Scavenge+Parallel Old组合可能仍然是更好的选择。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Region划分：G1内存管理的基石
2.1 Region的基本特性与内存布局
G1将堆划分为多个大小相等的Region，默认情况下Region的大小根据堆内存自动计算，范围在1MB到32MB之间。可以通过-XX:G1HeapRegionSize参数手动指定。在我的测试环境中，8GB堆通常会生成约2048个4MB大小的Region。
每个Region在任意时刻都只属于一种角色：
- Eden区：存放新创建的对象
- Survivor区：存放年轻代GC后存活的对象
- Old区：存放长期存活的对象
- Humongous区：存放大小超过Region 50%的大对象
- 空闲区：未分配使用的Region
这种设计打破了传统分代收集器物理上连续的年轻代和老年代划分，使得内存管理更加灵活。例如在一次回收中，可以只清理部分Eden Region和部分Old Region，而不必像CMS那样必须处理整个老年代。
2.2 Humongous对象的特殊处理
对于超过单个Region 50%的大对象，G1会分配连续的多个Region作为Humongous Region来存储。这类对象的处理需要特别注意：
- 分配时可能触发GC：因为需要连续的Region空间
- 回收效率较低：必须等到Full GC时才能回收
- 影响停顿时间预测：大对象过多会导致回收时间波动
在实际应用中，我们曾遇到一个案例：一个缓存服务频繁分配2-3MB的大数组，导致Humongous对象激增。通过调整-XX:G1HeapRegionSize=8M（使这些数组不再被视为Humongous对象），Young GC时间从平均120ms降至80ms。
3. Remembered Set：跨代引用的关键解决方案
3.1 基本原理与数据结构
Remembered Set（记忆集）是G1解决跨代引用问题的核心机制。每个Region都有一个对应的Remembered Set，用于记录从其他Region指向本Region的引用。这种设计避免了传统收集器需要扫描整个老年代来查找对年轻代引用的开销。
在实现上，Remembered Set本质是一个哈希表结构：
- Key：引用来源Region的地址
- Value：引用具体位置的集合（通常用位图表示）
当程序执行写操作时（如objA.field = objB），如果满足：
- objA位于Old Region
- objB位于Young Region
则会触发写屏障（Write Barrier）逻辑，将这一引用关系记录到对应Region的Remembered Set中。
3.2 维护开销与优化实践
Remembered Set虽然解决了跨代引用问题，但也带来了额外的开销：
- 写屏障导致的运行时开销：每次跨代引用写入都有额外操作
- 内存占用：每个Region的Remembered Set需要额外空间
- 并发处理复杂度：需要与用户线程并发执行
在我们的生产环境中，曾遇到Remembered Set占用堆内存15%的情况。通过以下调整显著降低了开销：
- 增加-XX:G1RSetUpdatingPauseTimePercent（默认10%）：控制GC时更新RSet的时间占比
- 使用-XX:+ReduceInitialCardMarks：减少初始标记阶段的卡表处理
- 避免过度使用"老年代引用年轻代"的数据结构
4. 混合回收：G1的核心回收策略
4.1 回收阶段详解
G1的回收过程分为以下几个阶段：
- 初始标记（Initial Mark）：标记GC Roots直接关联的对象，需要STW
- 并发标记（Concurrent Mark）：从GC Roots开始追踪整个对象图
- 最终标记（Final Mark）：处理SATB（Snapshot-At-The-Beginning）缓冲，需要STW
- 筛选回收（Evacuation）：选择收益最高的Region进行回收，需要STW
其中最具特色的是混合回收（Mixed GC）阶段，它会同时清理年轻代和老年代的Region。这与传统收集器严格区分Young GC和Old GC的做法完全不同。
4.2 回收策略与Region选择
G1采用启发式算法选择要回收的Region，主要考虑：
- 垃圾比例：优先选择垃圾最多的Region（Garbage-First）
- 回收效率：考虑对象存活率、Region间引用关系等
- 停顿时间目标：通过-XX:MaxGCPauseMillis指定（默认200ms）
在实际调优中，我们发现过于激进的停顿时间目标（如50ms）会导致：
- 回收频率显著增加
- 每次回收的Region数量减少
- 总体吞吐量下降30%以上
建议根据应用特点合理设置该参数，通常100-200ms是比较平衡的选择。
5. 停顿时间预测：G1的核心竞争力
5.1 预测模型与实现机制
G1的停顿时间预测基于以下几个关键因素：
- Region统计信息：每个Region的存活对象数量、引用关系等
- 历史数据：过去几次回收的实际耗时
- 硬件特性：CPU性能、内存带宽等
预测过程大致如下：
- 根据历史数据建立回归模型
- 对候选Region集合估算回收时间
- 选择满足停顿时间目标的Region组合
- 动态调整模型参数
这种预测使得G1能够相对准确地控制每次GC的停顿时间，特别适合对延迟敏感的应用。
5.2 预测不准的常见原因与解决方案
在实践中，我们遇到过多次预测失准的情况，主要原因包括：
- Humongous对象突然增加
- Remembered Set维护开销激增
- 引用关系突然变化（如缓存失效）
解决方案通常有：
- 增加-XX:G1ReservePercent（默认10%）：预留更多空间应对突发情况
- 监控Humongous对象比例：超过阈值时告警
- 优化数据结构：减少跨代引用
6. G1调优实战经验分享
6.1 关键参数与典型配置
基于我们在多个生产系统的实践，以下是一组经过验证的G1配置参数：
bash复制-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45
-XX:G1HeapRegionSize=8M
-XX:G1ReservePercent=15
-XX:ConcGCThreads=4
这些参数适用于16-32GB堆内存、8核CPU的典型服务端应用。其中：
- InitiatingHeapOccupancyPercent控制并发标记触发的时机
- ConcGCThreads应与CPU核心数匹配（通常为1/4总核心数）
6.2 常见问题排查指南
问题1：长时间停顿（>1s）
可能原因：
- Humongous对象过多
- Remembered Set过大
- 并发标记阶段被长时间阻塞
排查步骤：
- 检查GC日志中的Humongous统计
- 使用jcmd GC.heap_info查看RSet大小
- 分析系统是否在GC时存在CPU竞争
问题2：吞吐量显著下降
可能原因：
- MaxGCPauseMillis设置过小
- 并发GC线程不足
- 堆内存过大导致回收效率低
解决方案：
- 适当放宽停顿时间目标
- 增加ConcGCThreads
- 考虑分拆服务或使用更大Region
在最近一次金融系统调优中，我们通过将G1HeapRegionSize从默认4M调整为8M，配合ConcGCThreads从2增加到4，使得99%的GC停顿控制在150ms以内，同时吞吐量提升了约20%。这充分展示了合理配置G1参数的重要性。