验证JVM调优后稳定性需在相同业务压力下确保关键指标不劣化：DeadlockedThreadCount恒为0、5xx错误率≤基线120%、连接池活跃比持续＞0.95不超过2分钟、锁等待线程数无突增、JFR中MonitorEnter阻塞时间增长≤30%，且必须同机复用线上Trace压测、覆盖≥2个Full GC周期，并排查OOM Killer、ZGC元数据泄漏及Metaspace热部署溢出等隐性风险。
验证调优后JVM稳定性：别只看GC日志
调优不是改完参数就完事，真正危险的是“表面正常、暗地崩坏”——比如GC停顿变短了，但线程死锁概率上升；吞吐量涨了，但偶发连接重置率从0.01%升到0.5%。验证核心是：在**相同业务压力下，关键稳定性指标不能劣化**。
必须监控的5个稳定性硬指标
这些指标比“服务没挂”更有说服力，且全部可量化、可告警：
-
java.lang:type=ThreadingMBean 中DeadlockedThreadCount必须恒为 0（哪怕瞬时非零也要告警） - HTTP 接口的
5xx_rate_5m（5分钟内5xx错误占比）不能超过基线值的120% - 连接池中
activeCount / maxTotal比值持续 > 0.95 超过2分钟，说明资源争抢已成常态 - 通过
jstack -l <pid>抽样发现java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await等待线程数突增，暗示锁竞争恶化 - JFR 录制中
jdk.JavaMonitorEnter事件平均阻塞时间增长 > 30%，说明同步开销被低估
对比测试必须控制变量
很多人用不同机器、不同压测流量做对比，结果毫无意义。真实验证要满足：
- 同一台机器重启JVM，仅切换JVM参数，禁用所有外部缓存（如Redis本地缓存清空）
- 压测流量必须复用线上录制的Trace ID和请求体，避免因随机数/时间戳导致路径分支差异
- 观察窗口至少覆盖2个Full GC周期（例如堆设为4G时，G1默认约30分钟一次），不能只看前5分钟
- 特别注意
-XX:+UseStringDeduplication类参数：它会降低内存占用，但首次触发时可能造成100ms+ STW，需检查G1EvacuationPause事件中的deduplicationTime字段
容易被忽略的“伪稳定”陷阱
有些调优会让系统进入一种脆弱平衡态，上线后几天才暴露：
-
-Xmx设得过大（如物理内存80%），但容器未配memory.limit_in_bytes，导致Linux OOM Killer静默杀进程——dmesg -T | grep -i "killed process"才能发现 - 启用
-XX:+UseZGC后，ZStatistics显示停顿极短，但/proc/<pid>/status中VmRSS持续缓慢上涨，说明ZGC的元数据区（Metaspace）或Native Memory 未被正确回收 - 把
-XX:MaxMetaspaceSize固定设为256m，短期没问题，但热部署3次后触发java.lang.OutOfMemoryError: Compressed class space，而这个错误不会出现在GC日志里
真正的稳定性验证，永远发生在“业务逻辑跑满、资源边界踩实、时间维度拉长”的组合条件下。任何跳过这三者的测试，都只是给故障埋彩蛋。
