必须将-Xms和-Xmx设为相等，因不等会导致运行时堆扩容引发不可控STW停顿、GC波动及响应抖动；扩容由MinHeapFreeRatio等隐式参数驱动且无法关闭，仅能通过设相等规避，容器中还需预留非堆内存空间并验证生效。
直接把 -Xms 和 -Xmx 设成一样，是最有效、最简单、也最被验证过的做法。这不是“建议”，而是生产环境的硬性要求——只要两者不等，JVM 就一定会在运行中扩容堆，带来不可控的 STW 停顿、GC 波动，甚至让服务响应忽快忽慢。
为什么必须相等？
堆不是“用多少分多少”的弹性资源。-Xms 是 JVM 启动时向操作系统申请的初始内存，-Xmx 是它允许自己长到的最大值。默认情况下（比如 -Xms256m -Xmx4g），堆一开始很小，随着对象增多，JVM 会反复判断是否要扩大堆——每次扩容都要停顿、重排结构、可能触发 Full GC，而且这个过程不会记为标准 GC 日志事件，只在详细日志里出现 heap expansion 或 grown 字样。
- 即使老年代长期只用 1GB，只要 -Xms 还没到 -Xmx，JVM 就可能在某次 GC 后主动扩一次
- 扩容行为受 MinHeapFreeRatio 等隐式参数驱动，你无法关闭，只能靠设相等来绕过
- G1 虽比 ParallelGC 更适应动态堆，但依然不推荐；固定堆才能让它真正按预期规划回收区域
设多大才合适？看真实占用，不是看机器总内存
别一上来就写 -Xmx8g。先跑起来，用真实流量压测，再观察稳定期的老年代使用峰值。
- 用
jstat -gc持续 10 分钟以上，重点关注 OU（Old Used）和 OU/OC（老年代已用 / 老年代容量）比值1000 - 或用 Prometheus + jvm_exporter 查
jvm_memory_used_bytes{area="heap"}的 P95 值 - 在此基础上上浮 10%～20% 作为安全余量：比如老年代稳定在 1.2GB，可设 -Xms2g -Xmx2g
- 小内存服务（≤2g）可略放宽，但避免 -Xms512m -Xmx2g 这类跨度太大的组合
容器环境要额外留出缓冲空间
Kubernetes 的 memory limit 是硬上限，JVM 超了会被直接 OOMKilled。而 -Xmx 只管堆，不管元空间、直接内存、线程栈这些“隐形开销”。
- 容器内 -Xmx 必须严格小于 memory limit，建议控制在 75%～80%，留出至少 10%～20% 给非堆内存
- 例如容器 limit 是 16Gi，-Xmx 最多设 12g～14g，再配 -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=2g
- JDK 10+ 更稳妥的做法是弃用 -Xms/-Xmx，改用
-XX:InitialRAMPercentage=75.0 -XX:MaxRAMPercentage=75.0 - 旧版本 JDK（如 8u191 之前）必须显式加
-XX:+UseContainerSupport，否则根本读不到容器限制
配完还得验证和兜底
设相等只是第一步。启动后必须确认是否真生效，并防住其他地方的内存失控。
- 执行
jinfo -flag MaxHeapSize和jinfo -flag InitialHeapSize，两个输出字节数必须完全一致 - 必须显式设置
-XX:MaxMetaspaceSize，否则类加载器泄漏时元空间无限增长，照样 OOM - 用
-XX:NativeMemoryTracking=detail+jcmd查非堆内存实际占用VM.native_memory summary - 加
-XX:+AlwaysPreTouch（延迟敏感场景），让 JVM 启动时就把堆内存真实映射并清零，避免首次访问缺页中断
