容器内存限制与 JVM 堆参数的协同：一次 OOMKilled 排查记录

问题现象

上周一个 Java 服务在预发环境频繁重启，事件记录里只有一行 OOMKilled，但 JVM 日志中没有出现 OutOfMemoryError。这类“容器被杀、JVM 却没报错”的情况，通常不是堆溢出，而是容器内存上限与 JVM 堆外内存之和发生了冲突。

先区分两种 OOM

第一种是 JVM 堆内 OOM，堆对象无法分配，JVM 会打印 java.lang.OutOfMemoryError: Java heap space 并生成 hprof。第二种是容器级 OOM，内核的 cgroup 内存控制器在整组内存超过 limit 时直接杀掉进程，JVM 来不及做任何事。前者的排查入口是堆转储，后者要看 dmesg 和 cgroup 计数。

现场取证

先确认容器是否真的被内核杀死：

kubectl describe pod svc-api-7c9f-2xk4l | grep -A3 "Last State"
dmesg -T | grep -i "killed process"
cat /sys/fs/cgroup/memory.events

如果 oom_kill 计数在增长，就可以确定是容器级 OOM。接着看内存构成：

cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.stat | egrep "anon|file|slab"
jcmd 1 VM.native_memory summary

这次现场的数据是：limit 2GiB，堆上限 -Xmx1536m，堆实际使用约 1.2GiB，但 memory.current 已经到 1.98GiB。差额主要来自 Metaspace、线程栈、DirectByteBuffer 和 glibc 的 arena 缓存。

参数怎么改

只调 -Xmx 是拍脑袋。更稳妥的做法是让 JVM 感知容器限额，并给堆外留出固定余量：

-XX:MaxRAMPercentage=65
-XX:InitialRAMPercentage=65
-XX:MaxMetaspaceSize=256m
-XX:ReservedCodeCacheSize=128m
-XX:NativeMemoryTracking=summary
-XX:+ExitOnOutOfMemoryError

65% 不是万能值。若服务大量使用 Netty 直接内存，应把 -XX:MaxDirectMemorySize 显式写出来，并把它计入堆外预算；若线程数很多，每个线程默认 1MiB 栈也要预留。经验公式是：容器 limit ≈ 堆 + Metaspace + 直接内存 + 线程栈 + 代码缓存 + 10% 安全余量。

验证与回归

改完后不要只看“没有重启”。用 jcmd VM.native_memory summary 连续采样，确认 committed 稳定；同时压测到接近峰值，观察 memory.current 的包络线是否仍低于 limit。最后把 memory.events 的 oom_kill 计数接入告警，避免下次只看到“Pod 重启”而不知道根因。

小结

容器时代的 JVM 调优，核心不是把 -Xmx 调大，而是把容器限额当作总预算，给堆内和堆外分别列账。先判断 OOM 的类型，再用量化数据分配预算，最后用压测和监控闭环验证，比反复试参数可靠得多。