直接结论：容器中Java应用应禁用硬编码-Xmx，改用-XX:+UseContainerSupport配合-XX:MaxRAMPercentage=70.0~75.0动态分配堆内存，否则因-Xss、Metaspace、DirectByteBuffer等堆外内存占用，极易触发cgroup OOMKilled；同时须显式设置GC线程数与容器CPU限制匹配，并限定-XX:MaxMetaspaceSize和-XX:MaxDirectMemorySize。
直接结论：别硬写 -Xmx，优先用 -XX:+UseContainerSupport + -XX:MaxRAMPercentage，否则容器 OOM 是大概率事件。
为什么 -Xmx 直接设成容器内存上限会炸
容器内存限制（如 --memory=2g）是整个 Java 进程能用的总上限，但 -Xmx2g 只管堆，不包括：
-
-Xss× 线程数（每个线程栈默认 1MB，100 个线程就是 100MB） - Metaspace（类元数据，默认无上限，容易撑爆）
- CodeCache（JIT 编译代码缓存）
- DirectByteBuffer 堆外内存（Netty、NIO 常见）
- JVM 自身开销（比如 GC 线程、JIT 线程本身）
实测中，-Xmx 超过容器内存的 75% 就容易被 cgroup 杀掉，尤其在高并发或突发分配时。生产环境推荐比例是 2/3 ~ 3/4，且必须配合 -XX:+UseContainerSupport 启用容器感知。
-XX:MaxRAMPercentage 怎么设才靠谱
这个参数从 JDK 8u191+ 开始支持，让 JVM 根据容器实际可用内存（不是宿主机）动态算堆大小，比硬编码 -Xmx 更健壮。
- 值设太高（如
90.0）→ 堆占满，其他区域没空间 → 容器 OOMKilled - 值设太低（如
40.0）→ 堆浪费，GC 频繁，吞吐下降 - 推荐值：
70.0 ~ 75.0，再配合-XX:InitialRAMPercentage=70.0避免启动期堆扩容 - 必须显式加
-XX:+UseContainerSupport，否则该参数无效（旧 JDK 默认关闭）
示例命令：
java -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=70.0 -jar app.jar
GC 线程数为什么不能信默认值
Docker 默认把宿主机 CPU 核数暴露给 JVM，-XX:ParallelGCThreads 和 -XX:ConcGCThreads 就会按宿主机核数设——比如宿主机 32 核、容器只限 2 核，结果 GC 线程开 32 个，争抢调度、上下文切换爆炸，GC 时间反而翻倍。
- 务必显式指定：
-XX:ParallelGCThreads=2（对应容器--cpus=2） - G1GC 下还要配
-XX:ConcGCThreads=1（一般为 ParallelGCThreads 的 1/4～1/2） - 如果用 ZGC/Shenandoah（JDK 11+），它们对 CPU 敏感度低，但
-XX:ActiveProcessorCount=2仍建议加上
验证是否生效：进容器执行 jstat -gc <pid></pid>，看 GC 线程数是否符合预期；或 jinfo -flag ParallelGCThreads <pid></pid> 直接查。
Metaspace 和堆外内存最容易被忽略
这两个区域不走 -Xmx 管控，但一样吃容器内存：
- Metaspace：Spring Boot 类多、热部署频繁时极易暴涨，必须设上限：
-XX:MaxMetaspaceSize=256m（起步值，视应用调整） - 堆外内存：Netty、Hadoop、Elasticsearch 等大量用
DirectByteBuffer，需监控-XX:MaxDirectMemorySize（默认等于-Xmx，但实际可能不需要这么大） - 额外建议：
-XX:+AlwaysPreTouch提前触内存页，避免运行时 Page Fault 拖慢响应（适合稳定长周期服务）
检查是否溢出：OOM 后用 jcmd <pid> VM.native_memory summary</pid> 查 native 内存分布，重点关注 Internal 和 Direct 区域。
真正难的不是参数组合，而是每次改完都得验证——jstat 看 GC 频率、docker stats 看 RSS 峰值、jcmd 看 native 内存，三者缺一不可。容器里 JVM 不像裸机那样“试错成本低”，一次 OOMKilled 就可能触发服务雪崩。
