一次只调一个JVM参数，结合jstat -gc观察5分钟以上YGC频次、耗时及老年代增长斜率，避免多参数耦合导致无法归因；否则调优只是将系统从一个不稳定态推向另一个隐蔽的不稳定态。
改多个JVM参数后无法归因问题根源
一次调整多个参数，等于同时改变堆大小、GC策略、元空间阈值、线程栈等变量，当压测或线上出现新问题时，根本没法判断是哪个改动引发的。比如 -Xmx 加大 + -XX:+UseG1GC 启用 + -XX:MaxMetaspaceSize 降低，结果 Full GC 频率上升，你无法确认是 G1 的 InitiatingHeapOccupancyPercent 没调好，还是元空间不足触发了额外 GC，抑或堆变大后对象晋升路径被干扰。
参数之间存在隐式耦合关系
JVM 参数不是独立开关，而是相互牵制的系统。例如：
-
-Xmn手动设新生代大小，会直接覆盖 G1 的弹性调节逻辑，导致-XX:MaxGCPauseMillis失效 -
-XX:MetaspaceSize设得太小，会频繁触发 Metaspace GC，而每次 Metaspace GC 都会触发一次完整的 Young GC（在 JDK 8u272 中已验证） -
-Xms和-Xmx差值过大，JVM 启动后要多次扩容堆，期间伴随多轮初始 GC，掩盖真实业务压力下的 GC 行为
缺乏基线对比，验证成本指数级上升
每多改一个参数，验证组合就翻倍。改 1 个参数只需 2 种状态（开/关）对比；改 3 个参数，就要跑 8 种组合才能穷举。现实中没人这么干——但更危险的是，很多人只跑“改完后的单次压测”，就认为优化成功。实际可能只是某次 GC 碰巧没触发，或者监控采样窗口刚好错过峰值。
真正有效的做法是：每次只动 1 个参数，用 jstat -gc 观察至少 5 分钟的 YGC 频次与耗时变化，再结合 GC log 看晋升率和老年代增长斜率。否则，所谓“调优”只是把系统从一个不稳定态，推到另一个你看不见的不稳定态。
