ki-pi1. G1垃圾回收器：现代Java应用的性能救星
第一次遇到G1是在2017年一个电商大促的深夜，当时我们的CMS回收器已经无法应对突增的流量，老年代频繁Full GC导致服务雪崩。紧急切换到G1后，GC停顿时间从秒级降到了200毫秒以内。这种"起死回生"的体验让我彻底迷上了这个革命性的垃圾回收器。
G1（Garbage-First）是JDK 7u4引入的服务器端垃圾回收器，在JDK9中成为默认回收器。它颠覆了传统分代回收的物理划分，改用逻辑分代+分区（Region）的设计，能够预测性地控制停顿时间。对于运行在8GB以上堆内存的现代Java应用，G1往往是解决"Stop-The-World"痛点的最佳选择。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. G1核心设计解析
2.1 分区（Region）模型
G1将堆划分为2048个默认大小的Region（范围1MB-32MB），每个Region可以是Eden、Survivor或Old区。这种设计带来三个关键优势：
- 内存利用率提升：不再需要连续的老年代空间，避免CMS的碎片化问题
- 回收粒度更细：可以单独回收某些Region而非整个代
- 并行处理能力：不同Region可以由不同GC线程并行处理
实际案例：在16GB堆内存中，G1会创建约2048个8MB的Region（可通过-XX:G1HeapRegionSize调整）
2.2 回收策略演进
G1的回收过程分为两个阶段：
-
年轻代回收（Young GC）：
- 只回收Eden和Survivor区
- 采用复制算法到新的Survivor区
- 会计算每个Region的回收价值（回收空间大小/所需时间）
-
混合回收（Mixed GC）：
- 不仅回收年轻代，还会选择部分老年代Region
- 选择标准基于"回收价值"排序（Garbage-First原则）
- 通过-XX:InitiatingHeapOccupancyPercent（默认45%）触发
java复制// 查看G1回收详情的JVM参数
-XX:+PrintGCDetails -XX:+PrintGCDateStamps
-Xloggc:/path/to/gc.log
3. G1调优实战手册
3.1 关键参数配置
| 参数 | 默认值 | 推荐值 | 作用说明 |
|---|---|---|---|
| -XX:MaxGCPauseMillis | 200ms | 50-200ms | 目标停顿时间（不是硬限制） |
| -XX:ParallelGCThreads | CPU核数 | 核数的5/8 | 并行回收线程数 |
| -XX:ConcGCThreads | 并行线程1/4 | 并行线程1/3 | 并发标记线程数 |
| -XX:G1NewSizePercent | 5% | 维持默认 | 年轻代最小占比 |
| -XX:G1MaxNewSizePercent | 60% | 维持默认 | 年轻代最大占比 |
3.2 监控指标解读
通过jstat观察关键指标：
bash复制jstat -gcutil <pid> 1000
重点关注：
- YGC/YGCT：年轻代回收次数/耗时
- FGC/FGCT：Full GC次数/耗时（G1应极少出现）
- GCT：总GC时间
- O：老年代使用率（超过IHOP会触发并发周期）
4. 生产环境常见问题排查
4.1 Full GC频繁
现象：监控显示FGC次数异常增长
排查步骤：
- 检查-XX:InitiatingHeapOccupancyPercent是否设置过高
- 确认没有显式调用System.gc()
- 使用jmap检查大对象分配：
bash复制jmap -histo:live <pid> | head -20
解决方案：
- 降低IHOP阈值（如从45%降到35%）
- 增加-XX:ConcGCThreads加快并发标记速度
- 添加-XX:+ExplicitGCInvokesConcurrent避免System.gc()触发Full GC
4.2 长时间停顿
案例：某次Mixed GC耗时超过1秒
根因分析：
- 使用-XX:+PrintAdaptiveSizePolicy发现Humongous对象过多
- Region大小（8MB）小于大对象阈值（50% Region大小）
优化方案：
- 增大G1HeapRegionSize到16MB（需重启）
- 优化代码避免分配超大数组
- 添加-XX:G1HeapWastePercent=10（默认5%）提前触发混合回收
5. 进阶技巧：G1与其他回收器对比
5.1 适用场景矩阵
| 回收器 | 堆大小 | 停顿敏感度 | 吞吐量优先级 | 适用版本 |
|---|---|---|---|---|
| Serial | <100MB | 不敏感 | 低 | 所有 |
| Parallel | <4GB | 中等 | 高 | JDK8- |
| CMS | 4-8GB | 高 | 中等 | JDK9前 |
| G1 | >8GB | 极高 | 中等偏高 | JDK7+ |
| ZGC | >32GB | 极致 | 中等 | JDK15+ |
5.2 G1与ZGC的选择
在JDK17环境中测试对比：
-
停顿时间：
- G1：90%的停顿<200ms，最大停顿1.2s
- ZGC：99%停顿<10ms，最大停顿50ms
-
吞吐量损失：
- G1比Parallel低约15%
- ZGC比G1低约8%
-
内存开销：
- G1额外占用约10%堆内存
- ZGC需要额外15-20%内存
决策建议：
- 对延迟要求<100ms选ZGC
- 内存<32GB且预算有限选G1
- 监控GC日志两周后再做最终决定
6. 真实案例：电商系统G1优化实录
某日订单系统在晚高峰出现周期性卡顿，通过以下步骤定位：
-
采集GC日志：
bash复制-Xlog:gc*=debug:file=gc.log:time,uptime,level,tags -
使用GCViewer分析发现：
- 每2小时出现一次400ms+停顿
- 老年代占用率在停顿前达到70%
-
根本原因：
- 定时任务每小时生成大型报表
- 这些临时对象过早晋升老年代
-
解决方案组合：
java复制-XX:InitiatingHeapOccupancyPercent=35 -XX:G1MixedGCLiveThresholdPercent=85 -XX:G1HeapWastePercent=10配合代码改造：
- 将报表生成改为流式处理
- 添加-XX:+UseStringDeduplication减少字符串重复
优化后最大停顿时间降至150ms以内，YGC频率降低40%。这个案例教会我：G1调优必须结合业务代码特性，仅靠参数调整难以解决所有问题