调优效果评估需建立可比、可追溯、有业务意义的对照关系，聚焦gc停顿、频率、老年代增速、内存水位等核心指标，结合业务响应、吞吐、错误率验证，并用gc日志、heapdump、jstack归因佐证，形成闭环逻辑。
调优后的指标对比不是简单看数字变小了没，关键在于建立可比、可追溯、有业务意义的对照关系。重点不是“调了之后好不好”，而是“比调之前好在哪、好多少、是否符合预期目标”。
明确对比基准和时间窗口
必须固定两个前提：
- 基准数据必须来自调优前同一套监控体系：用 jstat、GC 日志、Prometheus + Grafana 等采集的原始数据，不能混用不同工具或不同采样频率的数据
- 时间窗口需匹配业务特征：比如对比高峰期（如每日 10:00–12:00）的 2 小时数据，而非随机截取；避免跨节假日、版本发布、流量突增等干扰时段
核心指标逐项对比方法
不堆砌所有指标，只盯与调优目标强相关的几项，按优先级排序：
- GC 停顿时间（STW）：对比 Full GC 和单次 Young GC 的 P95/P99 耗时。例如调优前 Full GC 平均 1200ms、P99 达 2800ms，调优后降到平均 450ms、P99 ≤ 800ms，且无 >1s 的长停顿，即达标
- GC 频率与吞吐占比：计算 GC 总耗时 ÷ 应用运行总时间。若目标是高吞吐，调优后该比值应从 8% 降至 ≤5%；同时看 YGC 次数是否稳定（如从每分钟 15 次降到 6 次），避免为降停顿而换来高频短停
- 老年代增长速率：用 jstat -gc 输出的 OU（Old Used）列，观察单位时间（如每分钟）增长量。调优后若晋升对象减少（如因调整 MaxTenuringThreshold 或 SurvivorRatio），OU 应明显趋缓，避免再出现每小时触发一次 Full GC
- 内存使用水位：重点关注老年代使用率是否长期 ≤70%，Eden 区是否不再持续卡在 85%+ 触发 YGC；元空间使用率是否稳定在 60% 以内，不再爬升逼近 80%
结合业务效果验证
技术指标改善必须映射到真实业务表现：
- 接口 P99 响应时间下降幅度是否与 GC 停顿降低幅度基本一致？例如停顿减少 60%，而接口延迟只降 15%，说明瓶颈可能不在 GC
- 系统吞吐量（QPS）是否提升？若 GC 时间占比下降但 QPS 不涨，需检查线程池、DB 连接池或外部依赖是否成为新瓶颈
- 错误率（如 5xx）是否同步下降？频繁 Full GC 常伴随请求超时或连接中断，调优后该类错误应收敛
用日志和快照做归因佐证
光看汇总指标不够，要回溯证据链：
- 开启 -XX:+PrintGCDetails 后，对比调优前后 GC 日志中 “GC Cause” 字段：是否从 “Allocation Failure” 或 “Metadata GC Threshold” 变为更良性的 “G1 Evacuation Pause”
- 调优前若存在内存泄漏，MAT 分析 heapdump 会显示某类对象实例数持续增长；调优后再次 dump，同类对象数量应趋于平稳
- jstack 抓取线程栈，确认 BLOCKED 线程数是否从 12 个降到 0–2 个，验证是否缓解了锁竞争导致的 GC 间接延迟
真正有效的对比，是把 JVM 参数变动、GC 行为变化、资源水位走势、业务指标响应串成一条逻辑闭环。不追求所有数字都变好，而要清楚每一处改善是否服务于最初设定的目标——低延迟、高吞吐，还是稳住不 OOM。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
