Java生产环境JVM调优是持续演进过程，需围绕低延迟、高吞吐、稳内存目标动态校准；依赖GC、内存、线程三类监控；坚持单变量闭环验证；善用JDK升级与重构实现质变。
Java 生产环境 JVM 性能调优不是一次配置就一劳永逸的事，而是一条需要持续演进的长期路径。它本质是跟随业务增长、流量变化、代码迭代和 JDK 升级而动态校准的过程。
明确目标是起点，不是选择题
低延迟、高吞吐、稳内存——三者天然存在权衡。支付服务必须压 STW < 150ms；日志聚合任务可接受 2s 停顿但要求吞吐翻倍；后台定时任务则更关注老年代不缓慢爬升。目标一旦模糊，调优就会失去标尺。每次重大版本上线前，需重审当前 SLA 是否仍匹配业务需求。
监控体系必须先于调优落地
没有可靠数据支撑的调优等于盲调。生产环境至少要固化三类可观测能力：
- GC 行为：通过
-Xlog:gc*:file=gc.log（JDK9+）或-XX:+PrintGCDetails（JDK8）持续采集，配合 GCViewer 或 GCEasy 自动识别 YGC 频率拐点、Full GC 触发模式、晋升失败等信号 - 内存分布：用
jstat -gc PID 2000每两秒采样，观察老年代使用率是否阶梯式上升；结合 Arthasvmtool --action getInstances --className java.util.HashMap --limit 10快速定位大对象实例 - 线程与锁：定期
jstack PID > thread.log，配合thread命令在 Arthas 中查看 BLOCKED 线程占比，避免 GC 停顿被误判为线程卡死
参数调整必须闭环验证
每次修改只动一个变量，且必须走“基线记录 → 参数变更 → 负载压测 → 指标比对 → 回滚预案”完整流程。例如将 -XX:MaxGCPauseMillis=200 改为 150，若发现 YGC 次数激增 3 倍而停顿未明显下降，说明目标值已逼近硬件瓶颈，应回退并检查对象生命周期是否异常（如缓存未设过期、流未 close）。
升级与重构是调优的加速器
JDK 版本跃迁带来质变机会：
- 从 JDK8 + CMS 迁移至 JDK17 + ZGC，可将百 GB 堆的停顿稳定控制在 10ms 内，无需大幅改动代码
- 启用 JFR（Java Flight Recorder）替代部分 Prometheus 指标采集，降低监控本身开销
- 结合 Spring Boot 3.x 的 GraalVM 原生镜像能力，在冷启动和内存占用上获得数量级改善
不复杂但容易忽略。
