容器 OOMKilled 但 Java 堆没满：一次堆外内存撞穿 memory limit 的预算复盘

结论先行

-Xmx 只约束了 Java 堆，可 cgroup 的 memory.limit 约束的是整个进程 RSS——堆、Metaspace、线程栈、DirectByteBuffer、JIT 代码缓存、glibc arena，全都算在内。当我们把容器内存设成 -Xmx + 一点余量 时，等于给「堆外那一堆」只留了个零头，结果就是：JVM 自己觉得「我堆才用了 70%」，内核却已经把容器 OOMKilled 了。这就是我要讲的这次事故。

一、现象：heap dump 看着挺健康，Pod 却 4 小时被杀 3 次

上周给我们一个网关服务（JDK 17.0.9，G1，Kubernetes 1.28.9 + containerd 1.7.13）做稳定性巡检，发现一个 4C8G 的 Pod 在 4 小时内被 OOMKilled 了 3 次，kubectl describe pod 里 reason 全是 OOMKilled、exit code 137。

最反直觉的是：我们抓到的 heap dump（约 2.9GB）显示堆只用了 -Xmx 4g 的 72%，GC 日志里 Young GC 平均停顿 3ms、没有 Full GC，看起来「内存很健康」。按常规思路「堆没满 = 没内存问题」，这案子根本立不住。

影响面：3 次被杀导致该节点 5 个实例里 1 个掉线约 40s，网关侧 499 错误涨了 0.8%，QPS 峰值在 3200 左右——不算 P0，但一周内反复复现，必须根因化。

二、根因：JVM 不知道「容器」的存在，堆外被挤到墙角

把内存拆成一张账本（单位 GB，容器 limit=8G）：

| 区域 | 配置/实际 | 说明 | |---|---|---| | Java 堆 | -Xmx 4.0，稳态占用 ~2.9 | G1 不会真吃满 4g | | Metaspace | MaxMetaspaceSize 未设，涨到 ~0.9 | 类多 + 反射代理，缓慢爬升 | | 线程栈 | 620 线程 × 1MB ≈ 0.62 | 默认 -Xss1m | | DirectBuffer | Netty 直连，峰值 ~0.7 | 堆外，不受 Xmx 管 | | JIT CodeHeap + glibc arena 等 | ~0.5 | 杂项 | | 合计 RSS | ~5.6，峰值冲到 8.1 | 撞穿 8G limit |

机制上讲清楚三点：

1. cgroup v1 的 OOM 判定看的是 cgroup 的 memory.usage_in_bytes，它统计的是该容器所有进程的物理页（RSS + 页缓存等），跟 JVM 内部的 Xmx 完全是两套坐标系。JVM 觉得「堆 72%」，内核看到的是「这坨进程吃了 8.1G，超了，杀」。
2. Metaspace 默认不设上限会无限涨。我们 MaxMetaspaceSize 压根没配，一个加载了大量动态代理/反射类的网关，Metaspace 从 200MB 爬到 900MB 用了 3 天，正好撞上流量高峰，把本来「刚好够」的余量吃穿了。
3. DirectByteBuffer 是堆外，Netty 的 io.netty.maxDirectMemory 默认是 -XX:MaxDirectMemorySize 缺省值（约等于 Xmx），它完全不进 Java 堆，却实打实占 RSS，是「堆看着没事、容器先崩」的头号贡献者。

打个比方：-Xmx 只是给「客厅」划了 4 平米，可房子总面积（memory.limit）只有 8 平米，厨房、阳台、走廊（堆外）加起来要 4 平米——你客厅只住了 2.9 人，但整栋房已经挤爆被房东（内核）赶出去了。

三、具体做法：先量再配，给堆外留出「走廊」

第 1 步：把账本量出来，别猜。

# 容器内看进程 RSS（cgroup v1）
cat /sys/fs/cgroup/memory/memory.usage_in_bytes
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
# cgroup v2
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.max

# JVM 侧看堆外各块
jcmd <pid> VM.native_memory summary   # 需开 -XX:NativeMemoryTracking=summary
jcmd <pid> VM.direct_buffers          # 看 DirectBuffer 总量
jcmd <pid> VM.metaspace               # 看 Metaspace 实占

第 2 步：给每个堆外区设硬上限，别让它「自由生长」。

# 启动参数（JDK 17）
java -Xms4g -Xmx4g \
     -XX:MaxMetaspaceSize=512m \
     -XX:ReservedCodeCacheSize=256m \
     -XX:MaxDirectMemorySize=512m \
     -Xss512k \
     -XX:+UseG1GC \
     -XX:+HeapDumpOnOutOfMemoryError \
     -XX:NativeMemoryTracking=detail \
     -jar gateway.jar

第 3 步：用「预算法」反推 limit，而不是「Xmx + 一点」。

limit = Xmx + MaxMetaspaceSize + 线程数×Xss + MaxDirectMemorySize
        + CodeCache + 安全余量(建议 10%~15%)
      = 4.0 + 0.5 + 0.3 + 0.5 + 0.25 + ~0.6 ≈ 6.15g
# 我们最终把 limit 从 8g 的「假安全」改成 request=6g / limit=7g，
# 并把实例数从 5 提到 6，冗余拉回来

第 4 步：加一条「快死前的告警」，别等 137。 在 Prometheus 里对 container_memory_working_set_bytes / container_spec_memory_limit_bytes > 0.85 配 warning，这次事故里该比值在 OOM 前 20 分钟就摸到过 0.91——如果当时有告警，我们能提前缩流而不是事后翻尸体。

四、踩过的坑 & 反直觉之处

• 坑 1：看到 OOMKilled 就以为 Java 堆爆了。 其实 137（SIGKILL）绝大多数是内核杀的，跟 OutOfMemoryError（JVM 自己抛的、exit 码通常不是 137）是两回事。这次 heap dump 健康就是铁证：137 ≠ 堆满。
• 坑 2：-Xmx 设成 limit 的 75%~80% 是「裸奔」。 这个经验值只在「堆外很小」的老式服务上成立；上了 Netty、大量反射、多模块（Spring 全家桶）之后，堆外轻松吃掉 1.5G+，75% 的堆直接没给堆外留地方。
• 坑 3：Metaspace「不设上限」在很多团队是默认习惯，因为「设小了会 Metaspace OOM」。但正确的姿势是「设一个够用的上限 + 监控」，而不是裸奔到撞墙。
• 坑 4：NMT 的 overhead。 -XX:NativeMemoryTracking 本身有 5%~10% 的 CPU/内存开销，线上常开要斟酌，建议只在排障窗口开 detail，平时用 summary 或关掉。
• 反直觉：limit 调大不是解药。 我们一度想把 8G 提到 16G「一劳永逸」，但根因是 Metaspace 无上限在缓慢泄漏式增长——不修上限，只是把「4 小时杀一次」变成「2 天杀一次」，等于把定时炸弹换了个闹钟。

五、结论与可复用清单

容器里跑 JVM，内存规划的对象是「进程 RSS」，不是「Java 堆」。可复用清单：

1. OOMKilled(137) 先怀疑堆外，别急着调 Xmx；先 cat memory.usage_in_bytes 对比 limit。
2. 给 Metaspace、DirectMemory、CodeCache 全部设上限，杜绝「自由生长」区。
3. 用预算法反推 limit：Xmx + 各堆外上限 + 10~15% 余量，而不是 Xmx + 一点。
4. 对 working_set/limit > 0.85 配告警，把「被杀」变成「提前缩流」。
5. NMT 只在排障窗口开 detail，线上常开注意 overhead。
6. Metaspace 无上限是隐性定时炸弹，务必设上限 + 监控增长斜率。

一句话收尾：-Xmx 管的是客厅，memory.limit 管的是整栋房——只量客厅面积就搬进去的人，迟早被房东（内核）请出去。