必须加-XX:+UseContainerSupport，否则-XX:MaxRAMPercentage等参数全失效；JDK 8u191+默认未启用，不加则JVM按宿主机内存估算堆大小，极易OOMKilled。
必须加 -XX:+UseContainerSupport，否则其他参数全失效
从 JDK 8u191 开始，-XX:+UseContainerSupport 是启用容器感知的开关，它默认是关闭的。不加这个参数，-XX:MaxRAMPercentage、-XX:InitialRAMPercentage、-XX:MaxRAMFraction 全部被忽略，JVM 仍按宿主机内存计算堆大小——哪怕你跑了 --memory=512m 的容器，JVM 也可能分配出 2GB 堆，直接触发 cgroup OOMKilled。
旧版本（如 8u131–8u190）要用 -XX:UnlockExperimentalVMOptions -XX:UseCGroupMemoryLimitForHeap 替代，但这两个参数在 JDK 10+ 已废弃，强行使用会报 warning 甚至拒绝启动。
-XX:MaxRAMPercentage 设多少才不炸
这个值不是“越高越好”，而是要给非堆内存留足空间。实测中：
- 设
90.0→ 堆占满，Metaspace、DirectByteBuffer、线程栈无处可放 → 容器被 OOMKilled - 设
40.0→ 堆太小，GC 频繁，吞吐暴跌，CPU 利用率虚高 - 生产推荐
70.0 ~ 75.0，再配-XX:InitialRAMPercentage=70.0避免启动期堆扩容抖动
注意：-XX:MaxRAMPercentage 只对堆生效，不控制 Metaspace 或 DirectBuffer；它算的是容器实际可用内存（cgroup memory limit），不是宿主机总内存。
为什么 -Xmx 不能硬写，尤其不能写成容器内存上限
容器内存限制（如 --memory=2g）是整个 Java 进程的硬上限，但 -Xmx2g 只管堆，不管：
-
-Xss× 线程数（默认每线程 1MB，100 个线程就是 100MB） - Metaspace（类元数据，默认无上限）
- CodeCache（JIT 编译缓存）
- DirectByteBuffer（Netty/NIO 堆外内存）
- JVM 自身线程开销（GC、JIT、Signal Dispatcher 等）
实测表明：-Xmx 超过容器内存的 75%，就极容易被 cgroup 杀掉，尤其在 GC 后大量对象晋升或突发 DirectBuffer 分配时。
验证是否真生效：别只信配置，要看运行时行为
进容器后执行以下命令确认 JVM 是否真正感知到容器限制：
-
jstat -gc <pid></pid>→ 查看max列是否接近容器内存 × 0.75（比如容器 2G，这里应≈1536M） -
jinfo -flag MaxRAMPercentage <pid></pid>→ 确认输出是MaxRAMPercentage = 75.0 -
jinfo -flag UseContainerSupport <pid></pid>→ 必须是true，否则前面全白配
最容易被忽略的是：Kubernetes 中若用 env 注入 JAVA_OPTS，要确保该变量在 java 命令中被正确展开（比如 java $JAVA_OPTS -jar app.jar），否则参数根本没传进去。
