核心是启用-XX:+UseContainerSupport并用-XX:MaxRAMPercentage=75.0动态分配堆内存，同时限定-XX:MaxMetaspaceSize、-Xss和-XX:MaxDirectMemorySize，为堆外内存预留空间，避免OOMKilled。
在 Docker 容器里限制 JVM 内存，核心不是“把 -Xmx 写死成容器内存大小”，而是让 JVM 正确感知容器的内存上限，并为堆外内存（Metaspace、线程栈、Direct Buffer 等）预留空间。否则即使堆只占 512MB，总进程内存也可能突破容器限制，触发 OOMKilled。
启用容器感知并用百分比动态分配堆
JDK 8u191+ 和 JDK 9+ 默认支持容器内存识别，但必须显式启用或确认生效：
- -XX:+UseContainerSupport：强制开启容器资源感知（JDK 8u131 引入，8u191+ 默认 true，但显式写出更稳妥）
- -XX:MaxRAMPercentage=75.0：堆最大占容器内存限制的 75%（注意必须带 .0，整数会报错）
- -XX:InitialRAMPercentage=50.0：初始堆设为容器内存的 50%，减少启动期扩容 GC
例如容器启动时加 docker run -m 1g，JVM 堆将自动设为约 768MB，而非按宿主机 64GB 算出的 16GB。
硬性限制非堆内存，防止元空间或线程撑爆
堆只是内存的一部分。以下参数必须显式设置，否则 Metaspace 可能涨到 300MB+，线程栈默认 1MB/个，100 个线程就占 100MB：
立即学习“Java免费学习笔记（深入）”；
- -XX:MaxMetaspaceSize=256m：避免类加载过多导致元空间无限扩张
- -Xss256k：微服务常用，降低单线程栈大小（默认 1MB）
- -XX:MaxDirectMemorySize=128m：Netty、NIO 场景必备，约束堆外直接内存
估算公式参考：容器内存 ≥ 堆上限 × 1.3 + 100MB（含 JVM 自身开销与系统保留）。
确保 JVM 参数真正生效，不被 Docker 启动机制覆盖
Docker 的 ENTRYPOINT/CMD 协作容易丢参数。推荐两种可靠方式：
-
JSON 数组格式 ENTRYPOINT：
ENTRYPOINT ["java", "-XX:+UseContainerSupport", "-XX:MaxRAMPercentage=75.0", "-XX:MaxMetaspaceSize=256m", "-jar", "/app.jar"] -
环境变量 JAVA_TOOL_OPTIONS：
ENV JAVA_TOOL_OPTIONS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0"，JVM 自动读取，但注意它也影响 jstack 等子进程
避免使用 CMD ["-Xmx512m"] 配合 ENTRYPOINT ["java", "-jar", "app.jar"]——CMD 会整体替换 ENTRYPOINT，参数失效。
验证配置是否落地
进容器后执行以下命令确认实际值：
-
java -XX:+PrintFlagsFinal -version | grep -i "maxheapsize\|maxrampercentage"：看 MaxHeapSize 是否接近预期（如 -m 1g → ~768MB） -
jstat -gc <pid> | awk '{print $7,$8,$10}'：分别对应 Metaspace、Compressed Class Space、Direct Buffer 使用量 -
cat /sys/fs/cgroup/memory/memory.limit_in_bytes：确认容器实际内存上限（单位字节）
若日志中出现 Killed process 且堆使用率仅 40%～60%，基本就是非堆内存失控或未启用容器感知。
