评估JVM垃圾回收器性能的关键指标是吞吐量、延迟和内存占用，其中吞吐量=用户代码运行时间/(用户代码运行时间+GC时间)，延迟即STW停顿时间，二者通常呈反比关系，需依应用场景权衡取舍。
评估 JVM 垃圾回收器的性能，关键看三个相互关联又彼此权衡的指标：吞吐量、延迟（即停顿时间）、内存占用。其中前两个最常被直接用于选型和调优。
吞吐量（Throughput）
它反映的是应用程序实际干活的时间占比——不是 GC 越少越好，而是用户代码运行时间占总时间的比例越高越好。
- 计算公式：吞吐量 = 用户代码运行时间 / (用户代码运行时间 + GC 时间)
- 生产环境通常要求 ≥90%，高吞吐意味着 GC 开销小，适合批处理、后台计算类任务
- 提升吞吐量的常见做法：增大堆内存、选用 Parallel GC、减少对象创建频率、避免过早晋升到老年代
延迟（Latency）——也就是停顿时间（Pause Time）
这是用户能“感知”到的卡顿，由 Stop-the-World（STW）阶段决定。哪怕只发生一次 2 秒 Full GC，对交易系统来说也可能造成订单超时或接口失败。
- 关注指标包括：单次 GC 最大停顿、P95/P99 停顿时间、GC 频率
- 交互型系统（如电商下单、金融支付）通常要求最大停顿
- 降低延迟的典型策略：用 G1 或 ZGC 替代 Parallel GC；合理设置 GC 目标（如 -XX:MaxGCPauseMillis=200）；避免大对象直接进入老年代
内存占用（Footprint）
指 JVM 堆内存的峰值使用量，影响部署密度与资源成本。它不直接出现在 GC 日志里，但会显著左右吞吐与延迟的表现。
- 内存太小 → GC 频繁 → 吞吐下降、停顿增多
- 内存太大 → 每次 GC 扫描范围大 → 单次停顿拉长（尤其 CMS/Parallel Old）；G1/ZGC 对大堆更友好
- 观察方法：通过 -Xmx 和 -Xms 设定后，用 jstat -gc 或 GC 日志中的 “max heap” 和 “used heap” 对比分析
指标之间的真实关系
吞吐量和延迟天然存在张力——想停顿短，就得频繁回收，总 GC 时间变多，吞吐就掉；想吞吐高，就得攒着一起收，单次停顿就变长。没有“全能型”回收器，只有“更适合当前场景”的选择。
- 后台任务优先吞吐 → Parallel Scavenge + Parallel Old
- 响应敏感型服务优先低延迟 → G1（JDK8u40+）、ZGC（JDK11+）、Shenandoah（JDK12+）
- 小内存或单核环境 → Serial GC（简单可靠，但仅限测试或嵌入式）
