-Xmx应根据可用内存和环境限制合理设置：物理机≤可用内存的70%～80%，容器需小于memory limit并预留10%～20%缓冲；-Xms与-Xmx必须相等以避免性能抖动；还需预留元空间、直接内存等非堆开销，并通过RSS和GC日志验证实际效果。
看物理内存和系统开销再定 -Xmx
别一上来就设 -Xmx16g，得先看机器还剩多少真可用内存。用 free -m 看 available 列，不是 total；容器里更要小心——Kubernetes 的 memory limit 是硬上限，JVM 超了会被 OOMKilled，而 -Xmx 必须严格小于它（建议留 10%～20% 缓冲）。比如容器 limit 是 16Gi，-Xmx 最多设到 12g～14g。
- 物理机：推荐
-Xmx≤ 可用内存的 70%～80%，给 OS、页缓存、本地进程留足空间 - 容器环境：必须
-Xmx < memory limit，否则 GC 还没来得及跑，cgroup 已经杀进程 - 混部场景（如和 Redis、Nginx 同机）：按实际压测后 RSS 峰值反推，别信“理论值”
-Xms 和 -Xmx 一定要相等
不等就等于主动引入性能抖动：堆从 -Xms 开始扩容时，会触发额外的 Full GC 或 STW（尤其 ParallelGC），且 JVM 需反复向 OS 申请内存页，延迟不可控。G1 虽稍好，但依然不推荐动态伸缩。
- 生产服务一律设成相同值，例如：
-Xms8g -Xmx8g - 小内存服务（≤2g）可放宽，但也要避免
-Xms512m -Xmx2g这类跨度太大的组合 - Spring Boot 应用注意：若用了
spring-boot-starter-actuator+management.endpoint.heapdump.show-info=true，堆越大，heap dump 文件生成越慢，可能阻塞线程
别忽略元空间和直接内存的“隐形开销”
-Xmx 只管堆，但 JVM 还要吃掉元空间（-XX:MaxMetaspaceSize）、线程栈（-Xss）、直接内存（-XX:MaxDirectMemorySize）、JIT 编译代码缓存等。这些加起来可能比堆还多，尤其在大量反射、动态代理、Netty 场景下。
- 典型搭配：
-Xmx8g -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=2g - 未设
-XX:MaxMetaspaceSize？类加载器泄漏时，元空间无限增长，最终触发java.lang.OutOfMemoryError: Metaspace - Netty 应用常见坑：
-Xmx4g却没调-XX:MaxDirectMemorySize，结果堆没满，直接内存先爆，报OutOfMemoryError: Direct buffer memory
验证是否设对了：盯住 GC 日志和 RSS 实际值
参数写了不等于生效，更不等于合理。真正要看的是 JVM 进程的 RSS（Resident Set Size）是否稳定、Full GC 是否频繁、老年代占用率是否长期 >70%。
- 启动加参数：
-Xlog:gc*:file=gc.log:time,tags,level（JDK 11+），别用老旧的-XX:+PrintGCDetails - 运行中查真实内存：
ps -o pid,rss,comm -p <pid>，对比rss/1024（MB）和-Xmx值，差值过大说明非堆内存吃得多 - 老年代持续 >85%？说明
-Xmx其实不够，或有内存泄漏，光调大没用
最常被跳过的一步是：没确认容器 cgroup memory.max 的实际限制值，就凭经验设 -Xmx。一上线就被 kill，连 GC 日志都来不及打出来。
