必须加-xx:+usecontainersupport，否则jvm按宿主机内存估算堆大小，导致容器内存超限被oomkilled；jdk 8u191+默认关闭该参数，需显式启用并配合-xx:maxrampercentage=70.0~75.0使用。
这个问题很典型：JVM 运行在 Kubernetes 容器里，但没启用容器感知支持（-XX:+UseContainerSupport），结果它把宿主机的总内存当成了自己的可用内存，堆参数（如 -Xmx）按宿主机配置设得过大，而实际容器内存 limit 很小——最终触发 Linux OOM Killer 杀掉进程，日志里却看不到 Java 的 OutOfMemoryError，只有 Killed 或 OOMKilled 事件。
确认是否缺失 UseContainerSupport
检查 JVM 启动参数中是否包含 -XX:+UseContainerSupport（JDK8u191+ / JDK10+ 默认开启，但旧版本或显式禁用时会失效）。常见误配包括：
- 使用 JDK8u131 等老版本，未手动加该参数
- 显式关闭了它：
-XX:-UseContainerSupport - 虽加了参数，但被其他 JVM 参数（如
-XX:+UnlockExperimentalVMOptions缺失）导致忽略 - 通过 Spring Boot 的
JAVA_OPTS注入，但环境变量未正确传入容器
验证 JVM 实际识别的内存上限
进入容器执行以下命令，对比「JVM 认为的内存」和「容器实际 limit」：
- 查 JVM 堆上限：
java -XX:+PrintFlagsFinal -version | grep MaxHeapSize（输出单位是字节） - 查容器内存 limit：
cat /sys/fs/cgroup/memory/memory.limit_in_bytes - 查 cgroup v2（若启用）：
cat /sys/fs/cgroup/memory.max
如果前者远大于后者（比如 JVM 显示 8G，而 cgroup limit 是 1G），基本可断定未正确感知容器限制。
检查 OOM 类型与日志线索
区分是 Java 层 OOM 还是系统层 OOMKilled：
- Java 堆溢出：日志含
java.lang.OutOfMemoryError: Java heap space，且进程通常仍在运行（或生成了 heap dump） - 系统级 OOMKilled：容器状态为
OOMKilled（kubectl get pod查看），kubectl describe pod中有Exit Code 137，dmesg -T | grep -i "killed process"可见内核日志明确指出因内存超限杀掉 java 进程 - 注意：即使开了
-XX:+HeapDumpOnOutOfMemoryError，也**不会**在 OOMKilled 场景下生成 dump，因为 JVM 没来得及触发异常就已被强制终止
快速修复与长期建议
临时修复（不改镜像）：
- 在容器启动命令或
env中显式设置-XX:+UseContainerSupport - 同时指定合理堆上限，例如：
-Xmx512m，避免依赖自动推导
长期建议：
- 升级到 JDK8u191+ 或 JDK11+，并确保未显式关闭该特性
- 在基础镜像中统一注入
-XX:+UseContainerSupport -XX:+PrintGCDetails等安全默认项 - 监控层直接读取
/sys/fs/cgroup/memory/memory.usage_in_bytes和memory.limit_in_bytes，比依赖 JVM 自报更可靠
