-xms与-xmx设为不同值会导致频繁gc，因初始堆小引发多次minor gc，扩容时stw整理内存并触发更多full gc；生产环境应设为相同值，容器中需配合maxrampercentage等参数防oom。
为什么-Xms和-Xmx设成不同值会导致频繁GC
当 -Xms 远小于 -Xmx（比如 -Xms256m -Xmx2g），JVM 启动后堆很小，但业务一上来就分配大量对象，触发多次 Minor GC；接着又不断扩容堆，每次扩容都要 Stop-The-World 做内存整理，还会引发更多 Full GC。这不是“省内存”，是把压力从启动时挪到运行时。
- 生产环境强烈建议
-Xms和-Xmx设为相同值，避免动态扩容带来的 STW 波动 - 若必须留弹性空间（如容器环境资源不固定），差值控制在 10% 以内，且需配合
-XX:MaxRAMPercentage等现代参数替代硬编码 - 注意：JDK 8u191+ 支持
-XX:InitialRAMPercentage和-XX:MaxRAMPercentage，比写死-Xms/-Xmx更适合容器化部署
在Docker里用-Xms/-Xmx要注意什么
容器里直接写 -Xms2g -Xmx2g 很危险——JVM 不认 cgroup 内存限制，默认按宿主机总内存算最大堆，可能超限被 OOM Killer 杀掉，错误日志里只看到 Killed process java，没有 Java 层堆溢出信息。
- JDK 8u131+ / JDK 10+ 默认启用
-XX:+UseContainerSupport，但必须同时加-XX:MaxRAMPercentage=75.0（或类似值）才能真正按容器限制算堆 - 验证是否生效：启动后查
jstat -gc <pid></pid>的max列，应接近容器memory limit× 百分比，而非宿主机内存 - 别信
java -XX:+PrintFlagsFinal -version | grep MaxRAM的输出——它显示默认值，不反映运行时实际生效值
设置-Xms/-Xmx后还是OOM，先看这三个地方
堆参数调大了却还报 java.lang.OutOfMemoryError: Java heap space，大概率不是堆不够，而是其他环节卡住了。
- 检查是否启用了
-XX:+HeapDumpOnOutOfMemoryError，并确认 dump 文件路径有写权限——没 dump 就像没病历，纯靠猜 - 确认 GC 日志开了：
-Xlog:gc*:file=gc.log:time,tags,level（JDK 11+）或-XX:+PrintGCDetails -Xloggc:gc.log（旧版），看是 GC 频繁但回收不了，还是压根没触发 GC - 排查非堆内存泄漏：
-XX:NativeMemoryTracking=detail+jcmd <pid> VM.native_memory summary</pid>，Metaspace、Direct Buffer、线程栈都可能吃光内存
Spring Boot应用里怎么安全地传入-Xms/-Xmx
别在 java -jar 命令里硬写，也别塞进 application.properties——那只是 Spring 配置，JVM 根本不读。
- 推荐方式：通过
JAVA_OPTS环境变量，例如JAVA_OPTS="-Xms512m -Xmx512m -XX:MaxRAMPercentage=75.0" - Docker 场景下，用
ENV JAVA_OPTS=...或docker run -e JAVA_OPTS="..."，确保在java进程启动前注入 - 如果用 Spring Boot Maven Plugin 打包成可执行 jar，可在
spring-boot-maven-plugin的executable配置里指定jvmArguments，但仅限本地测试，上线仍应走环境变量
-Xmx 却没同步调大 Metaspace 或 Direct Memory 限额，结果 OOM 换了个地方发生。
