生产环境应优先根据业务特征选择垃圾回收器：高并发低延迟场景首选g1；大对象长生命周期服务推荐zgc或shenandoah；老系统过渡期cms仍有价值。
生产环境选对回收器，比盲目调参数更重要。G1不是万能解药，CMS也不是历史遗迹，关键看业务特征和停顿容忍度。
高并发低延迟场景：G1 是主流选择
电商、支付、实时风控类服务普遍采用 G1，尤其堆内存超过 4GB 时。它把堆划分为多个 Region，支持并发标记和可预测停顿（如 -XX:MaxGCPauseMillis=200），避免 Serial Old 兜底导致的秒级卡顿。
- 典型配置：-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Xms8g -Xmx8g
- 注意点：G1 不强制要求年轻代大小，但若观察到 Mixed GC 频繁或晋升失败（To-space exhausted），可微调 -XX:G1HeapRegionSize（如设为 16m）或增加堆总量
- 避坑：不要同时设置 -XX:NewRatio 和 -XX:+UseG1GC，G1 会忽略 NewRatio
大对象+长生命周期服务：ZGC 或 Shenandoah 更合适
当系统存在大量缓存（如规则引擎、配置中心）、单次 Full GC 停顿超 1 秒且无法接受时，ZGC（JDK11+）或 Shenandoah（JDK12+）是更优解。它们将 STW 控制在 10ms 级别，代价是 CPU 占用略高、对 JDK 版本有要求。
- ZGC 启用方式：-XX:+UnlockExperimentalVMOptions -XX:+UseZGC（JDK17 起无需 Unlock）
- 适用信号：老年代增长缓慢但每次 GC 停顿长、监控显示 GC 线程持续占用 CPU
- 限制：ZGC 暂不支持 Windows（截至 JDK21），Shenandoah 在部分 JVM 版本中需额外启用
老系统迁移过渡期：CMS 仍有价值
部分运行在 JDK8u2xx 且未升级计划的系统，仍依赖 CMS。它虽已废弃，但在稳定版本中表现可靠——尤其是对吞吐量敏感、允许偶尔较长停顿（
- 关键参数：-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70
- 风险点：CMS 失败后会退化为 Serial Old，造成“雪崩式”卡顿；必须配合 -XX:+UseParNewGC 启用并行新生代回收
- 监控重点：关注 Concurrent Mode Failure 日志，一旦出现，说明老年代扩容跟不上对象晋升速度
小内存轻量服务：Parallel GC 反而更稳
微服务中大量 1~2GB 堆的后台任务类应用（如日志清洗、报表生成），Parallel GC（吞吐量优先）往往比 G1 更简单高效。它没有并发开销，GC 日志清晰，调优路径明确。
- 默认即启用（JDK8 默认），显式配置：-XX:+UseParallelGC
- 优化方向：调大 -Xms/-Xmx 使两者相等，避免动态扩容；用 -XX:MaxGCPauseMillis 仅作参考，实际以吞吐量为目标
- 识别信号：Minor GC 频繁但耗时短（
