一、-Xms / -Xmx 到底怎么回事
-Xms 是 JVM 启动时直接分配的堆内存,-Xmx 是堆能用到的上限。
不手动配的话,JDK 有套默认算法:
- Xms = 物理内存的 1/64
- Xmx = 物理内存的 1/4
这套逻辑在裸机上没问题。但进了 Docker 容器,事情就变了。
二、容器里的坑:JDK 版本是分水岭
Docker 用 cgroup 限制容器能用的内存,但 JDK 读不读得到这个限制,取决于版本。
JDK8u191 之前:JDK 根本不认识 cgroup,它读的是宿主机整机内存。你给容器分了 512M,JDK 觉得自己有 64G,按 1/4 算 Xmx 就是 16G------直接 OOM 被 kill。
JDK8u191 及以后 / JDK9+ :默认开了 -XX:+UseContainerSupport,JDK 会去读 cgroup 的限制值,按容器实际可用内存来算默认值。这个版本之后基本不会踩这个坑了。
三、百分比参数:InitialRAMPercentage / MaxRAMPercentage
JDK9 原生支持,JDK8u191 往后的补丁版本也支持。用来替代 -Xms 和 -Xmx:
`-XX:InitialRAMPercentage=50.0 # 初始堆占可用内存 50%
-XX:MaxRAMPercentage=75.0 # 最大堆占可用内存 75%
`
有个坑很多人踩:百分比必须带小数点。
`-XX:MaxRAMPercentage=60 ❌ 纯整数,启动直接报错
-XX:MaxRAMPercentage=60.0 ✅ 必须写成浮点格式
`
四、几种场景怎么配
物理机单 Jar 部署
初始堆给 25%,最大堆给 50%:
`java -XX:InitialRAMPercentage=25.0 -XX:MaxRAMPercentage=50.0 -jar app.jar
`
物理机多实例共存
别用百分比,老老实实写固定值。所有 Java 进程的 Xmx 加起来别超过物理内存的 70%:
`java -Xms2g -Xmx2g -jar app.jar
`
另外,Xmx ≤ 2G 的场景,建议直接 -Xms=-Xmx,启动就把堆分配满,省掉运行时扩容的开销。
Docker 容器部署(现在最常见的形态)
用百分比最方便,初始 50%,最大 75%:
`java -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=75.0 -jar app.jar
`
想还原 JDK 原生默认比例(1/64 ≈ 6.25%)也行:
`java -XX:InitialRAMPercentage=6.25 -XX:MaxRAMPercentage=25.0 -jar app.jar
`
五、查配置的命令
看 JDK 默认的 Xms/Xmx(没启动应用时):
`java -XX:+PrintFlagsFinal -version | grep -iE 'HeapSize'
`
看正在跑的进程实际用了什么参数(PID 换成你的):
`jcmd <PID> VM.flags
`
说白了就几条:
裸机看物理内存,容器看 cgroup 限制,JDK8u191 是条分界线。百分比参数好用但记得带 .0。单机多实例用固定值,容器单实例用百分比,小堆直接 Xms=Xmx 省得扩容。