选对垃圾回收器是降低Java系统停顿最直接有效的手段：堆≤4GB且P99要求<200ms选G1，8GB–64GB选ZGC，≥64GB或严苛延迟场景选Shenandoah；需结合GC日志与jstat验证YGC频次、停顿分布及暂停总时长占比。
选对垃圾回收器是降低 Java 系统停顿最直接有效的手段，核心不是“调参数”，而是让 GC 行为匹配业务的真实延迟要求和运行环境。
看堆大小和延迟目标选回收器
堆容量与停顿容忍度共同决定回收器边界：
- 堆 ≤ 4GB，且 P99 响应时间要求 -XX:+UseG1GC -XX:MaxGCPauseMillis=200，JVM 会动态调整回收节奏
- 堆 8GB–64GB，要求稳定亚秒级停顿（如支付、API 网关）：ZGC 更优，只需 -XX:+UseZGC -Xmx32g，99% 停顿可压到 10ms 内
- 堆 ≥ 64GB 或延迟极端敏感（如风控决策、高频交易）：Shenandoah 在大堆下仍保持低抖动，支持 Linux/x64 和 AArch64
- 避免使用 Parallel GC（吞吐优先，单次停顿不可控）和已废弃的 CMS（JDK 14+ 移除）
匹配 JDK 版本和平台限制
回收器能力受限于运行时环境：
- ZGC 自 JDK 15 起正式生产就绪，推荐搭配 JDK 17+；在 JDK 21 中已支持并发类卸载，进一步减少元空间相关 STW
- Shenandoah 自 JDK 12 起集成，JDK 17 后默认启用，但需确认 OS 架构是否支持（目前不支持 Windows）
- G1 是 JDK 9+ 默认回收器，兼容性最好，适合过渡或保守升级场景
- 不要在 JDK 11 上强行启用 ZGC——部分特性缺失可能导致隐式 Full GC
避开常见误配陷阱
很多停顿问题其实源于配置冲突或认知偏差：
立即学习“Java免费学习笔记（深入）”；
- 别给 G1 设 -XX:MaxGCPauseMillis=50：目标过低会导致频繁 Young GC 和 CPU 消耗上升，反而拉高平均延迟
- ZGC 不需要也不建议设置 -XX:NewRatio 或 -Xmn：它无分代设计，硬设新生代参数会被忽略甚至引发警告
- 避免堆大小浮动：-Xms 和 -Xmx 必须相等，否则扩容缩容过程本身就会触发额外 STW
- 检查日志中 Humongous Allocation 频次：G1 中 >½ Region（默认约 512KB）的对象直入老年代，易诱发碎片和提前 Full GC
用真实数据验证效果
调参后必须观测实际行为，不能依赖理论值：
- 加 JVM 参数开启详细 GC 日志：-Xlog:gc*,gc+heap=debug:file=gc.log:time,uptime（JDK 10+）
- 重点关注指标：YGC 频次与耗时、G1 Evacuation Pause 分布、ZGC 的 Pause (Load) 和 Pause (Mark) 是否稳定在目标内
- 结合应用监控看 GC 暂停总时长占比，理想值应
