jvm垃圾回收器选型核心看吞吐量和延迟：吞吐量优先适用于后台批处理，推荐parallel gc、zgc；延迟敏感适用于交互服务，推荐g1、zgc、shenandoah；三者受内存占用制约，需结合监控验证效果。
JVM 垃圾回收器的性能指标不是抽象参数，而是直接影响业务体验和系统稳定性的关键信号。选错回收器或调参不当，轻则响应变慢、订单超时，重则服务雪崩。真正落地时，核心就看两个指标：吞吐量和延迟（即用户停顿时间），它们在不同业务场景下有截然不同的优先级。
吞吐量优先：适合后台批处理类业务
吞吐量 = 业务代码运行时间 / 总运行时间。数值越高，说明 CPU 花在真实计算上的比例越大。
- 典型场景：日志归档、报表生成、离线数据清洗、定时任务调度
- 这类业务不直接面向用户，允许单次 GC 停顿稍长（比如 200–500ms），但要求单位时间内完成更多任务
- 推荐回收器：Parallel GC（默认在 Server 模式启用）、ZGC（大堆下兼顾吞吐与低停顿）
- 调参重点：增大堆内存（-Xmx）、调高年轻代比例（-XX:NewRatio）、避免频繁 Full GC
延迟敏感：交互型服务必须守住 P99 停顿底线
延迟指单次 GC 引起的 Stop-the-World 时间，尤其关注 P95/P99 停顿值——它决定绝大多数用户的实际感知。
- 典型场景：API 网关、支付接口、实时聊天、秒杀下单、前端渲染服务
- 用户能容忍 100ms 内抖动，但无法接受 1.5s 卡顿；一次 2s 的 Full GC 可能导致大量请求超时熔断
- 推荐回收器：G1（可控停顿）、ZGC（毫秒级，JDK11+）、Shenandoah（低延迟，并发整理）
- 调参重点：设置目标停顿时间（-XX:MaxGCPauseMillis=200）、合理预估对象晋升速率、避免堆过大导致并发标记拖慢
内存占用与“不可能三角”的现实权衡
吞吐量、延迟、内存占用三者构成经典制约关系——提升其中一项，往往要牺牲另一项。业务上线前必须明确底线：
- 如果机器内存受限（如容器环境限制 2GB），就不能盲目用 ZGC（它需要额外元数据空间），而应选 G1 + 精细调优
- 若业务对象生命周期短、分配快（如电商详情页），可适当提高 -XX:MaxGCPauseMillis，换取更少 GC 频次和更高吞吐
- 老年代持续增长且触发频繁 CMS 或 G1 Mixed GC，说明对象晋升过快或存在内存泄漏，此时再调参数已无意义，需查代码
监控与验证：用真实指标代替理论选择
回收器效果不能靠文档判断，必须结合生产流量验证：
- 开启 GC 日志（-Xlog:gc*,gc+age=trace,safepoint）观察实际 pause time 分布和频率
- 用 Prometheus + JVM Micrometer 抓取 jvm_gc_pause_seconds_count 和 jvm_gc_pause_seconds_max
- 对比业务指标：GC 频次上升是否伴随 HTTP 5xx 增加？P99 响应时间拐点是否与某次 Full GC 时间吻合？
- 灰度发布时，对比新旧回收器在相同 QPS 下的错误率与平均延迟变化
