1. 垃圾回收器选型的关键考量
在Java应用性能调优中，垃圾收集器（GC）的选择往往直接影响系统吞吐量和延迟表现。作为经历过多次生产环境GC调优的老手，我深刻理解不同业务场景下收集器选型的微妙差异。CMS、G1和ZGC这三个主流收集器的技术演进，实际上反映了Java生态对低延迟、高吞吐和大内存管理的持续追求。
选择收集器时首先要明确应用的SLA要求：
- 延迟敏感型（如交易系统）：关注最大停顿时间（Max Pause Time）
- 吞吐优先型（如批处理）：关注GC时间占比（Throughput）
- 大堆应用（如大数据处理）：关注内存碎片和Full GC风险
2. CMS收集器：老牌低延迟方案的实战解析
2.1 核心工作原理
CMS（Concurrent Mark-Sweep）采用标记-清除算法实现，其"并发"特性体现在：
- 初始标记（STW）：标记GC Roots直接关联对象
- 并发标记：遍历对象图
- 重新标记（STW）：处理并发标记期间变动的引用
- 并发清除：回收垃圾对象
典型配置示例：
bash复制-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
2.2 生产环境痛点实录
去年在电商大促期间，我们某个核心服务使用CMS时遭遇了promotion failed：
- 老年代空间碎片化导致大对象分配失败
- 触发串行Full GC造成秒级停顿
- 最终通过-XX:+UseCMSCompactAtFullCollection缓解
其他典型问题包括：
- 并发模式失败（Concurrent Mode Failure）
- 元空间溢出引发的Full GC
- 浮动垃圾导致的频繁GC
关键建议：CMS适合6-8GB以下堆内存，且需要预留至少30%空间缓冲
3. G1收集器：区域化设计的平衡之道
3.1 架构设计突破
G1（Garbage-First）的核心创新在于：
- 堆内存划分为多个Region（默认2048个）
- 可预测停顿模型（-XX:MaxGCPauseMillis）
- 混合收集（Mixed GC）机制
内存布局示例：
| Region类型 | 占比 | 作用 |
|---|---|---|
| Eden | 60% | 新对象分配 |
| Survivor | 10% | 存活对象过渡 |
| Old | 30% | 长期存活对象 |
3.2 调优实战笔记
在为某金融系统做G1调优时，我们通过以下步骤将停顿控制在50ms内：
- 确定目标停顿时间：-XX:MaxGCPauseMillis=50
- 调整Region大小：-XX:G1HeapRegionSize=4m
- 限制并发周期：-XX:G1ConcRefinementThreads=4
- 监控关键指标：
- GC Pause Duration
- Remembered Sets大小
- 并发标记效率
常见误区警示：
- 盲目设置过小的MaxGCPauseMillis会导致吞吐量骤降
- 大堆（>32G）时需特别注意Humongous对象分配
- JDK8u40之前的版本存在已知性能问题
4. ZGC：革命性低延迟方案的内幕
4.1 核心技术解析
ZGC的三大核心技术支柱：
- 着色指针（Colored Pointers）
- 利用64位指针的元数据位存储标记信息
- 实现并发标记和并发压缩
- 读屏障（Load Barrier）
- 在访问对象时执行额外检查
- 确保内存视图一致性
- 内存多重映射
- 相同物理内存映射到不同虚拟地址
- 支持并发对象移动
启用配置：
bash复制-XX:+UseZGC
-XX:+ZGenerational # JDK21+启用分代
-XX:ZAllocationSpikeTolerance=5.0
4.2 生产落地挑战
在迁移某实时风控系统到ZGC时，我们遇到并解决了：
- 大堆（64G）下初始标记阶段耗时过长
- 解决方案：升级到JDK17+使用并发类卸载
- 原生内存占用过高
- 调整：-XX:ZNativeMemoryLimit=20g
- 突发流量导致分配速率飙升
- 优化：-XX:ZCollectionInterval=120
性能对比数据（相同硬件）：
| 指标 | CMS | G1 | ZGC |
|---|---|---|---|
| 最大停顿 | 280ms | 120ms | 1.2ms |
| 吞吐损失 | 15% | 12% | 8% |
| 内存开销 | 低 | 中 | 高 |
5. 收集器选型决策树
根据百家机构调研数据，我总结出以下选型策略：
mermaid复制graph TD
A[堆大小] -->|≤8G| B[延迟要求]
A -->|>8G| C[是否TB级堆]
B -->|≤100ms| D[是否允许Full GC]
B -->|>100ms| E[G1]
D -->|否| F[ZGC]
D -->|是| G[CMS]
C -->|否| H[G1]
C -->|是| I[ZGC]
关键版本选择建议：
- JDK8：CMS/G1
- JDK11：G1（CMS已废弃）
- JDK17+：ZGC/Shenandoah
6. 面试深度问题剖析
6.1 经典问题拆解
"G1如何处理跨代引用？"
- 核心机制：Remembered Set
- 每个Region维护RSet记录外部引用
- 写屏障（Post-Write Barrier）更新RSet
- 垃圾收集时扫描相关RSet
6.2 高阶问题准备
"ZGC如何实现并发压缩？"
- 着色指针标记对象状态
- 转发表（Forwarding Table）记录新地址
- 读屏障处理指针重定向
- 多重映射消除复制开销
6.3 故障排查模拟
"服务突然出现长时间停顿可能原因？"
检查清单：
- Full GC触发（jstat -gcutil）
- 系统交换（vmstat 1）
- 分配速率突变（GC日志）
- 元空间耗尽（-XX:MetaspaceSize）
- 线程竞争（jstack）
7. 前沿趋势与个人建议
经过数十次生产环境验证，我的三点核心经验：
- 中小堆场景（<32G）：G1平衡性最佳
- 云原生环境：ZGC更适合动态伸缩
- 传统系统迁移：建议分阶段实施
未来关注方向：
- Generational ZGC（JDK21+）
- 向量化GC（Project Vector）
- 持久内存支持
最后分享一个诊断技巧：使用-XX:+PrintAdaptiveSizePolicy可以观察G1的自我调节过程，这对理解GC行为非常有帮助。