必须将-xms与-xmx设为相同值，否则jvm会在运行时动态扩容堆内存，引发stw停顿和gc波动；设相等后堆大小启动即锁定，彻底避免扩容逻辑。
必须把 -Xms 和 -Xmx 设成完全相同的值，否则 JVM 一定会在运行时扩容堆，带来 STW 停顿和 GC 波动。
为什么设相等就能阻止扩容
JVM 堆的初始容量由 -Xms 控制，上限由 -Xmx 限定。默认情况下两者差很大（比如 -Xms256m -Xmx4g），JVM 启动后堆很小，随着对象分配逐渐逼近当前容量，就会触发扩容——每次扩容都要 Stop-The-World、重排内存结构、可能连带触发 Full GC。
设为相等后，堆从启动那一刻就锁定大小，不再伸缩，彻底绕开扩容逻辑。
- 扩容不是“可选优化”，而是 JVM 内存管理的默认行为，只要
-Xms 就一定会发生 - 扩容过程不记录为 “GC event”，但在 GC 日志里能看到
heap expansion或grown字样 - 即使应用内存使用率长期只有 30%，只要堆未满且
-Xms ，JVM 仍可能在 GC 后主动扩容（受 <code>MinHeapFreeRatio等隐式参数影响）
怎么确定该设多大
不能拍脑袋定值，得看真实负载下的堆占用峰值：
- 用
jstat -gc <pid> 1000</pid>持续观察 10 分钟以上，重点关注OU（老年代已用）和OU/OC比值，取稳定期的峰值 - 或用 Prometheus +
jvm_exporter查jvm_memory_used_bytes{area="heap"}的 P95 值 - 在此基础上上浮 10%~20% 作为安全余量，例如老年代长期在 1.2GB，可设
-Xms2g -Xmx2g - 避免设过大：单次 GC 耗时随堆增大而上升；也避免过小：Minor GC 频繁，对象提前晋升到老年代
容器环境必须额外注意的坑
Docker/Kubernetes 中直接写死 -Xmx4g 极易 OOM Killed，因为 JVM 默认不感知容器内存限制：
- JDK 8u191+ 默认开启
-XX:+UseContainerSupport，但旧版本必须显式加该参数才认memory limit - 更稳妥的做法是弃用
-Xms/-Xmx，改用-XX:InitialRAMPercentage=75.0 -XX:MaxRAMPercentage=75.0（JDK 10+ 支持） - 若仍用
-Xms/-Xmx，确保-Xmx不超过容器memory limit的 75%，留出元空间、直接内存、线程栈等开销 - 验证是否生效：启动后执行
jinfo -flag MaxHeapSize <pid></pid>和jinfo -flag InitialHeapSize <pid></pid>，输出字节数必须完全一致
配完还得防其他地方“偷偷扩容”
堆锁住了，不代表整个 JVM 内存就稳了：
-
-XX:MetaspaceSize和-XX:MaxMetaspaceSize必须显式设置，否则元空间会无限增长，类加载器泄漏时照样 OOM - 直接内存（
ByteBuffer.allocateDirect）、线程栈（-Xss）、CodeCache 都不受-Xms/-Xmx控制，需单独监控 - 用
-XX:NativeMemoryTracking=detail+jcmd <pid> VM.native_memory summary</pid>查非堆内存占用 - GC 日志里一旦出现
Metaspace相关的Full GC，说明元空间已成瓶颈，不是堆的问题
真正麻烦的从来不是堆扩容本身，而是它常和元空间泄漏、直接内存滥用、线程数失控同时发生——只盯 -Xms/-Xmx 而不查 NMT，等于修了门却忘了窗。
