核心是JVM必须读取容器cgroup限制而非宿主机内存，退出码137且OOMKilled为true、无OutOfMemoryError日志即典型表现；需按JDK版本启用UseContainerSupport或等效参数，配MaxRAMPercentage=75.0并显式限制Metaspace和DirectMemory。
核心是让 JVM 正确“看清自己被关在多大的房间里”——它不能继续按宿主机内存算堆大小，而必须读取容器的 cgroup 限制。退出码 137、OOMKilled: true 且日志无 OutOfMemoryError，基本就是这个问题。
确认是不是 JVM 感知问题
先快速锁定根源：
- 查容器状态：
docker inspect <cid> | jq '.State.OOMKilled, .State.ExitCode'，确认为true和137 - 看内核日志：
dmesg -T | grep -A2 -B2 "killed process" | grep java，时间是否匹配崩溃时刻 - 进容器检查真实内存用量：
cat /sys/fs/cgroup/memory/memory.usage_in_bytes，对比memory.limit_in_bytes；若接近上限但jstat显示堆只用了几百 MB，说明非堆部分（直接内存、元空间、线程栈等）吃掉了剩余空间
JDK 版本决定解决路径
不同版本启用容器感知的方式和参数不同，不能一概而论：
-
JDK 8u131–u190：需显式加实验性参数
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
注意：-Xmx会覆盖该参数，所以不要同时设-Xmx和这个组合 -
JDK 8u191+ / JDK 10+：默认开启容器支持，但建议仍加
-XX:+UseContainerSupport
并用更精准的占比控制：-XX:MaxRAMPercentage=75.0（留 25% 给非堆） -
JDK 11 及以上（推荐）：用
MaxRAMPercentage替代老旧的MaxRAMFraction，支持小数，例如75.0表示堆占容器内存 limit 的 75% - JDK 8u111 或更老：参数无效，必须升级，没有绕过方案
必须配合的非堆内存控制
光调堆不够，元空间和直接内存同样会突破 cgroup 边界：
- 显式限制元空间：
-XX:MaxMetaspaceSize=256m（防类加载泄漏） - 显式限制直接内存：
-XX:MaxDirectMemorySize=256m（尤其用 Netty、NIO、Oracle JDBC 时） - 禁用自适应策略，避免干扰：
-XX:-UseAdaptiveSizePolicy - 验证是否生效：进容器执行
java -XX:+PrintFlagsFinal -version | grep MaxHeapSize，输出值应接近你预期（如容器-m 1g，则应≈768m）
K8s 配置不能掉链子
JVM 调对了，K8s 配错照样被杀：
-
limits.memory 必须设置：只设
requests.memory不触发 OOM 控制，超限后会被无预警杀死 -
requests ≈ limits：避免调度到碎片多的节点；若需弹性，用
limits - requests的差值做软缓冲 - 确保基础镜像支持：优先选
eclipse-temurin:17-jre-jammy或amazoncorretto:21-alpine-jdk等明确支持容器感知的镜像
