一次 Docker 容器 OOM 排查：cgroup 内存限制与 JVM 的相爱相杀

凌晨两点收到告警：容器重启 17 次。日志里只有一行 Kill，进程凭空消失——这是 OOM Killer 的签名。复盘这次排查，把容器内存的隐蔽机制讲清。

一、现象与直觉的偏差

容器 limit 设了 4G，JVM 堆设了 3G，看着有 1G 余量。但 JVM 除了堆还有：元空间、直接内存、线程栈、CodeCache、GC 结构。RSS 轻松冲破 limit。

二、容器看到的内存和宿主机不一样

Java 8u191 之前，JVM 读的是宿主机物理内存，MaxRAMPercentage 按机器 64G 算——容器视角的 4G 完全被无视。新版本 JVM 意识到 cgroup，但直接内存仍要自己管。

三、定位三步

1. docker inspect 确认 Memory 配置与 OOMKilled 标志位

2. 容器内 cat /sys/fs/cgroup/memory/memory.usage_vs_limit（v1）或 memory.current / memory.max（v2）——这是内核视角的真实水位，比 free 准

3. jcmd VM.native_memory summary 看非堆分配分布

四、修复方案

- 显式设 -XX:MaxDirectMemorySize，别默认等于堆大小

- 容器 limit 调到 堆 + 非堆预估的 1.3 倍

- -XX:+UseContainerSupport 确认开启（新版本默认开）

- 关键指标接监控：container_memory_working_set_bytes，告警阈值 85%

五、预防清单

把 memory.max、JVM 各区上限、实际 RSS 三者画在一张图上。当 RSS 稳定接近 memory.max 而 JVM 堆远未到顶，就是非堆在吃内存——这类问题 90% 是直接内存或元空间泄漏。

容器不是虚拟机，内存账本由 cgroup 记。读懂 cgroup 的账本，比给 JVM 加堆靠谱得多。