我的 Java 服务在容器里跑着跑着就被干掉重启,kubectl 显示 OOMKilled,可服务器明明有几十 G 内存,排查发现是 JVM 根本不知道自己被关在了一个小盒子里:一次容器内存限制与 JVM 堆的深度复盘

那个反复重启是监控告警"Pod 重启次数蹭蹭涨"才暴露的:我的 Java 服务跑在 K8s 里,给容器设了 memory limit: 512Mi。可线上它跑着跑着就被杀掉重启,kubectl describe pod 里写着刺眼的 Reason: OOMKilled(被内存溢出杀手干掉)。我一开始很困惑:我们的宿主机有几十 G 内存啊,我这小服务怎么会内存不够被杀?而且 JVM 自己也没抛 OutOfMemoryError(不是 JVM 堆满了的那种 OOM)。我查到底,才看明白,后背发凉:问题出在 JVM 没有"感知"到它所在容器的内存限制。在老版本 JVM(或没配置好时),JVM 启动时决定"堆最大能用多少(-Xmx)"的依据,是它看到的"机器总内存"——可它看到的,是宿主机的几十 G,而不是容器被 cgroup 限制的那 512Mi;于是 JVM 自作主张地把最大堆设成了好几个 G(按宿主机内存的 1/4 默认值算),它以为自己有好几个 G 可用,撒开了用;可它实际被关在一个 512Mi 的"小盒子"(容器 cgroup 限制)里;当 JVM 真的去申请超过 512Mi 的内存时,Linux 内核的 OOM Killer 发现这个容器超了它的内存 limit,二话不说就把整个进程杀掉(SIGKILL);所以是"容器外的内核"杀了它,而不是 JVM 自己堆满报错——这就是为什么没有 OutOfMemoryError、却是 OOMKilled。根本原因是:JVM(容器里的进程)不知道容器给它的真实内存边界,按宿主机的大内存来规划自己的用量,结果超出了容器 limit,被内核 OOMKilled。问题的根,是进程没感知容器的资源限制(cgroup)、按宿主机资源来用,超出容器 limit 被内核杀。这篇就把这次"容器内存限制与 JVM 堆"的坑,从头到尾复盘一遍。

故障现场:容器被 OOMKilled,JVM 却没报 OOM

问题在于 JVM 按宿主机内存设堆、超过了容器的小 limit、被内核杀:

# ✗ 出问题的部署: 容器限制512Mi, 但JVM不知道, 按宿主机内存设堆
resources:
  limits:
    memory: "512Mi"     # 容器被cgroup限制最多用512Mi
# 启动: java -jar app.jar   # ✗ 没指定-Xmx, JVM自己决定最大堆

# 现象:
# - Pod 跑着跑着被杀重启; kubectl describe pod 显示 Reason: OOMKilled;
# - JVM日志里【没有】OutOfMemoryError(不是JVM堆满报的错);
# - 宿主机内存明明很充裕(几十G)。

# 为什么? JVM没感知容器的内存限制(cgroup):
# 1. JVM启动时要决定"最大堆-Xmx"; 没显式指定时, 它按"机器总内存的一个比例(默认约1/4)"自动设;
# 2. 老JVM(JDK8早期等)读到的"机器总内存", 是【宿主机的】(几十G), 不是容器cgroup限制的512Mi;
#    → JVM以为有几十G, 把最大堆设成了好几个G(远超512Mi!);
# 3. JVM运行中真的去申请内存、堆涨到超过512Mi时:
#    → Linux内核的OOM Killer发现这个容器(cgroup)的内存用量超了limit;
#    → 直接给进程发SIGKILL把它【杀掉】(不是JVM自己抛OOM, 是内核从外面杀);
# 4. → 表现为 OOMKilled(容器被内核杀), 而非 JVM 的 OutOfMemoryError。

# 关键区别:
# - JVM的OutOfMemoryError: JVM自己的堆(-Xmx范围内)满了, JVM主动抛错(进程内);
# - 容器OOMKilled: 容器总内存用量超过cgroup limit, 被内核从外部杀掉(进程被SIGKILL)。
# 本文是后者: JVM以为自己有几十G(没感知512Mi限制), 一用超了512Mi就被内核杀。

# 关键: 容器里的进程(如JVM)若不感知容器的cgroup内存限制, 会按宿主机的大内存来规划用量,
#       超出容器limit就被内核OOMKilled(而非进程自己报OOM) —— 进程要感知容器的资源边界。

第一次想明白"原来 JVM 以为自己有几十 G、其实只有 512Mi,是被外面的内核杀的"时,我又懊恼又恍然:"我一直以为给容器设了 limit、JVM 自然就会在 limit 内老实用,完全没想到 JVM 压根'看不见'这个 limit,还按宿主机的大内存撒开了用。"这个坑最隐蔽的地方在于:它表现为 OOMKilled 而非 JVM 的 OutOfMemoryError,容易让人往"JVM 堆配置"之外的方向想;而且偶发(要堆真的涨到超 limit 才被杀),低负载时不发作;还容易误判成"是不是内存泄漏"——其实是根本没把堆限制在容器边界内。下面就来拆解,怎么让容器里的进程正确感知和适配资源限制。

第一件事:搞懂容器资源限制与进程的关系

我顺着这次事故,把容器内存限制、cgroup、JVM 堆的关系彻底理清了。

容器里的进程为什么会"看不见"自己的资源限制? 该怎么办?

【核心: 容器靠cgroup限制资源, 但老进程读的是宿主机总内存、不知道limit; 要让进程感知容器limit(新JVM自动/或显式配-Xmx), 并合理设requests/limits】

1. 容器是怎么限制内存的? —— cgroup
   - K8s的memory limit, 底层是用Linux的cgroup给容器设了一个内存上限;
   - 容器内进程的总内存用量超过这个上限 → 内核的OOM Killer杀掉容器内进程(OOMKilled)。

2. 问题: 进程默认"看"的是宿主机, 不是容器
   - 容器不是虚拟机, 它和宿主机共享内核; 进程通过/proc/meminfo等看到的, 默认是【宿主机】的总内存/CPU;
   - → 进程(尤其会"按可用内存自动调参"的, 如JVM堆、线程池、缓存大小)会按宿主机的大资源来规划;
   - → 远超容器的小limit → 一用超就被OOMKilled。

3. JVM的具体表现:
   - JVM按"机器内存的比例"自动设最大堆(-Xmx); 老JVM读到宿主机内存 → 堆设得过大 → 超limit被杀;
   - 新JVM(JDK8u191+/JDK10+)默认开启容器感知(UseContainerSupport): 能读到cgroup的limit,
     按【容器limit】的比例设堆 → 不再超。

4. 怎么解决(让进程适配容器):
   - ① 升级/启用容器感知: 用支持容器感知的JVM版本(默认已开UseContainerSupport);
   - ② 显式按limit配堆: -XX:MaxRAMPercentage=75.0 (按容器内存的75%设堆) 或直接 -Xmx384m;
   - ③ 给容器设合理的requests和limits: limit别太小(要容纳堆+堆外+元空间+线程栈+JVM自身);
   - ④ 留余量: 容器limit要 > JVM最大堆 + 堆外内存(JVM不只用堆! 还有Metaspace/线程栈/直接内存/JIT等)。

5. 一个常被忽略的点: JVM内存 ≠ 只有堆
   - 容器内存 = 堆(-Xmx) + Metaspace + 线程栈*线程数 + 直接内存 + JIT代码缓存 + JVM自身 + ...;
   - 所以 -Xmx 要明显小于 容器limit(留出堆外的部分), 否则堆没满、但总量超limit也会OOMKilled。

一句话: 容器靠cgroup限内存, 但进程默认看的是宿主机总内存、不知道limit, 会按宿主机大内存规划而超limit被OOMKilled;
   要让进程感知容器limit(新JVM自动/或-XX:MaxRAMPercentage/-Xmx显式配), 且容器limit要留出堆外内存的余量。

这套认知,是整个坑的根。容器靠 cgroup 限制内存——K8s 的 memory limit 底层是 cgroup 给容器设的上限,超了就被内核 OOM Killer 杀。进程默认看的是宿主机不是容器——容器和宿主机共享内核,进程通过 /proc/meminfo 默认看到宿主机的总内存,会按宿主机的大资源规划(JVM 堆、线程池、缓存),远超容器小 limit。JVM 的表现:老 JVM 按宿主机内存比例自动设堆、过大被杀;新 JVM(8u191+/10+)默认开启容器感知(UseContainerSupport),按容器 limit 比例设堆。怎么解决:升级/启用容器感知、显式 -XX:MaxRAMPercentage=75 或 -Xmx、设合理 requests/limits、limit 要留出堆外内存余量。JVM 内存 ≠ 只有堆:容器内存=堆+Metaspace+线程栈+直接内存+JIT+JVM 自身,-Xmx 要明显小于 limit,否则堆没满总量超 limit 也 OOMKilled。一句话:容器靠 cgroup 限内存,但进程默认看的是宿主机总内存、不知道 limit,会按宿主机大内存规划而超 limit 被 OOMKilled;要让进程感知容器 limit(新 JVM 自动/或 -XX:MaxRAMPercentage/-Xmx 显式配),且容器 limit 要留出堆外内存的余量。

第二件事:正解——让 JVM 感知容器 limit、按 limit 配堆、留堆外余量

搞懂了原理,正解就清晰了:用支持容器感知的 JVM(默认已开),或显式用 -XX:MaxRAMPercentage/-Xmx 按容器 limit 配堆;给容器设合理的 requests/limits,且 limit 要留出堆外内存的余量。

# ====== 正解: 设合理limit + 让JVM按容器limit配堆 ======
resources:
  requests:
    memory: "512Mi"      # 请求(调度依据)
  limits:
    memory: "512Mi"      # 上限(超了OOMKilled)
# 启动命令: 让JVM按容器内存的比例设堆, 并留出堆外余量
# java -XX:MaxRAMPercentage=75.0 -jar app.jar
#   → 堆最大约 512*0.75 ≈ 384Mi, 留 ~128Mi 给Metaspace/线程栈/直接内存/JVM自身;
# 或显式: java -Xmx384m -jar app.jar

# ====== 配置要点 ======
# 1. 用容器感知的JVM: JDK 8u191+ / JDK 10+ 默认开启 UseContainerSupport, 自动读cgroup limit设堆;
#    (老JDK8可显式: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap)
# 2. 按limit比例配堆: -XX:MaxRAMPercentage=75.0 (容器化推荐, 比写死-Xmx更灵活, 改limit堆自动跟着变);
# 3. ★ 留堆外余量: 容器limit要 > 最大堆 + 堆外内存; 别把-Xmx设成等于limit(堆外会顶爆);
#    经验: -Xmx或MaxRAMPercentage留出20%~30%给堆外(Metaspace/线程栈/直接内存/JIT等);
# 4. 设 requests 和 limits: requests影响调度, limits是硬上限; 内存通常 requests=limits(内存不可压缩);
# 5. 真OOMKilled还频繁: 排查是否有内存泄漏(堆dump分析)、线程数过多、直接内存(Netty等)失控;
# 6. 其他运行时同理: Node(--max-old-space-size)、Go(GOMEMLIMIT)等也要适配容器内存。

# ====== 区分两种OOM, 对症下药 ======
# - OOMKilled(容器被内核杀): 容器总内存超limit → 调limit/配堆/查堆外/查泄漏;
# - OutOfMemoryError(JVM堆满抛错): JVM堆(-Xmx)不够 → 调大堆(在limit允许下)或查堆内泄漏。
# 先看是哪种, 别混着治。

# 核心: 让容器里的JVM感知容器内存limit(用容器感知JVM/-XX:MaxRAMPercentage), 按limit比例配堆并留堆外余量;
#   设合理requests/limits; 区分OOMKilled(超容器limit被内核杀)和OutOfMemoryError(JVM堆满)对症处理。

修复的核心,是"让 JVM 感知容器 limit、按 limit 配堆、留堆外余量"。正解:设合理 limit + JVM 按容器内存比例配堆——-XX:MaxRAMPercentage=75.0(堆≈limit 的 75%,留余量给堆外)或显式 -Xmx384m。配置要点:用容器感知 JVM(8u191+/10+ 默认开)、按 limit 比例配堆(比写死 -Xmx 灵活)、留堆外余量(limit > 堆 + 堆外,别把 -Xmx 设成等于 limit)、设 requests/limits、频繁 OOMKilled 排查泄漏/线程数/直接内存、Node/Go 等也要适配。区分两种 OOM:OOMKilled(容器超 limit 被内核杀)→ 调 limit/配堆/查堆外;OutOfMemoryError(JVM 堆满抛错)→ 调大堆或查堆内泄漏;先看是哪种。归根结底:让容器里的 JVM 感知容器内存 limit(用容器感知 JVM/-XX:MaxRAMPercentage),按 limit 比例配堆并留堆外余量;设合理 requests/limits;区分 OOMKilled 和 OutOfMemoryError 对症处理。

第三件事:容器化部署中其他容易踩的资源/环境坑

排查后我把容器化部署中其他容易踩的资源、环境相关坑也系统梳理了一遍。

容器化部署的其他常见坑

# 1. 进程没感知内存limit(本文): 按宿主机内存设堆, 超limit被OOMKilled。→ 容器感知/按limit配。

# 2. 没感知CPU limit: 线程池/GC线程按宿主机CPU核数设, 过多。→ 同理适配容器CPU。

# 3. 没设limits/requests: 容器无限用资源, 挤垮节点/调度不合理。→ 都设上。

# 4. limit设太小: 频繁OOMKilled/CPU被限流(throttle)。→ 压测定容量, 留余量。

# 5. 容器时区是UTC: 日志/定时任务时间不对。→ 挂时区/设TZ环境变量。

# 6. 日志写容器内文件不轮转: 撑爆容器磁盘/节点。→ 日志输出到stdout由平台收集。

# 7. :latest镜像(同344篇): 不可复现。→ 固定版本tag。

# 8. 健康检查配错(同548篇): 没readiness/liveness太敏感。→ 按职责配探针。

# 共同根源: 容器给进程营造了一个"看似独占一台机器"的假象, 但它其实是被cgroup限制了资源、共享宿主机内核的;
#   进程若用"独占整机"的假设(按宿主机资源规划)去运行, 就会和"容器的真实限制"冲突 → 被杀/被限流/出错。

# 核心: 容器里的进程必须"感知并适配容器的资源边界"(内存/CPU limit), 而非按宿主机资源来用;
#   设好requests/limits、让运行时(JVM/Node/Go)感知容器限制、适配时区和日志; 别让进程活在"独占整机"的幻觉里。

排查让我把容器化部署的其他坑也梳理清了。一、进程没感知内存 limit(本文)。二、没感知 CPU limit(线程/GC 按宿主机核数)。三、没设 limits/requests。四、limit 设太小(频繁 OOMKilled/CPU 限流)。五、容器时区是 UTC。六、日志写容器内不轮转撑爆磁盘。七、:latest 镜像。八、健康检查配错。它们的共同根源是:容器给进程营造了一个"看似独占一台机器"的假象,但它其实是被 cgroup 限制了资源、共享宿主机内核的;进程若用"独占整机"的假设(按宿主机资源规划)去运行,就会和容器的真实限制冲突——被杀/被限流/出错。核心是:容器里的进程必须"感知并适配容器的资源边界"(内存/CPU limit),而非按宿主机资源来用;设好 requests/limits、让运行时(JVM/Node/Go)感知容器限制、适配时区和日志;别让进程活在"独占整机"的幻觉里。下面这张图,是这次 OOMKilled 坑的成因与解法:

第四件事:OOMKilled vs OutOfMemoryError 对比表

这次踩坑后,我把"容器 OOMKilled"和"JVM OutOfMemoryError"这两种容易混淆的 OOM 对比成一张表。

这张表把两种 OOM 钉清了。核心是:这两种 OOM名字都带 OOM、却是两个不同层面的事——OutOfMemoryError 是"进程内部"的问题(JVM 自己管的堆满了,它自己报错);OOMKilled 是"进程外部"的问题(容器这个'外壳'的总配额超了,外面的内核把它杀了);它俩的"边界"不同(一个是 JVM 堆的边界 -Xmx,一个是容器 cgroup 的边界 limit),要从不同层面去看、去治。它给我的最大启发是:同一个症状("内存不够/被 OOM"),在系统的不同层次(进程内的堆、进程的虚拟内存、容器的 cgroup、宿主机的物理内存)上,有不同的含义、不同的边界、不同的元凶;排查这类问题, 必须先搞清"是哪一层的'内存不够'",再去那一层找原因——在错的层面找,永远找不到。这给了我一种排查分层系统问题的清醒:面对一个"跨越多个层次"的系统(应用→运行时→容器→OS→硬件)出的问题,要有"分层定位"的意识——先确定"问题出在哪一层"(是 JVM 堆?容器 limit?还是宿主机?),不同层有不同的观测手段(JVM 看堆 dump、容器看 kubectl/cgroup、OS 看 dmesg);"先把问题归到正确的层次, 再在那一层深入",是高效排查分层系统问题、不在错的层面瞎找的关键。认清同一症状在不同层次含义不同、排查要先分层定位再深入——是这个坑带给我的认知。

第五件事:这次事故暴露的"沙盒幻觉"

这次让我反思更深一层:JVM 之所以出错,是因为它误以为自己独占了整台机器。我把"容器给进程的幻觉"和"容器的真实"对比成表。

这张表道出了问题的本质。核心是:容器技术的精妙之处,是给进程营造了一个"我独占一台干净机器"的隔离幻觉(自己的文件系统、网络、进程空间);可这个幻觉是"不完整"的——在资源(内存/CPU)这件事上,进程默认看不到加在自己身上的限制(limit),还以为自己能用宿主机的全部;于是 JVM 这个"没被告知真实边界"的进程,就按幻觉里的"大机器"去规划,撞上了真实的"小盒子"墙。它给我的深刻启发是:任何"隔离/虚拟化/抽象"营造出的"独占/无限"幻觉,都不是真的无限,背后总有真实的、有限的物理约束;"感受不到限制" 不等于 "没有限制"——限制可能只是暂时没让你撞到、或没让你看到;而当你"仗着幻觉、毫无节制地索取"时,迟早会撞上那堵真实的墙(被 OOMKilled、被限流、被拒绝)。这给了我一种身处"受限环境"的清醒:在任何"看似资源充裕/无限"的环境里运行(容器、云、共享集群、Serverless),都要主动去了解"我真实的资源边界在哪",并让我的程序'感知并尊重'这个边界——而不是被"看起来很多"的幻觉麻痹、无节制地用;"认清并主动适配自己真实的资源边界、不被独占的幻觉误导",是让程序在受限的、共享的真实环境里稳定运行的根本前提。认清隔离营造的独占幻觉背后是真实有限的约束、主动感知并尊重真实资源边界——是这个 OOMKilled 坑带给我的工程态度。

第六件事:把应用部署进容器时,我现在的自检习惯

现在每当我要把一个应用部署进容器,我都会先按这张图问自己:

这张图的精髓,是"设好 limits、让运行时感知容器内存、给堆外留余量"。设 requests/limits、运行时感知容器 limit、配堆留堆外余量、还 OOM查泄漏或调大 limit。这套习惯,让我从"设了 limit 就以为万事大吉"变成了"让进程感知 limit、按 limit 配堆留余量"——核心始终是:容器里的进程要感知并适配容器内存 limit(用容器感知 JVM/-XX:MaxRAMPercentage),按 limit 配堆并留堆外余量,别按宿主机内存用而被 OOMKilled。

我立下的几条规矩

这场"服务在容器里反复被 OOMKilled"的事故,换来了我做容器化部署时,刻进骨子里的几条铁律:

1. 容器靠 cgroup 限内存,超 limit 被内核 OOMKilled(不是进程自己报 OOM)。
2. 进程默认看到的是宿主机内存,不是容器 limit。容器和宿主机共享内核。
3. JVM 要用容器感知版本(8u191+/10+),或 -XX:MaxRAMPercentage 按 limit 配堆。
4. 容器 limit 要大于"堆 + 堆外内存",-Xmx 别设成等于 limit。留 20%~30% 余量。
5. JVM 内存 ≠ 只有堆,还有 Metaspace/线程栈/直接内存/JIT/JVM 自身。
6. 区分 OOMKilled(超容器 limit)和 OutOfMemoryError(JVM 堆满),对症处理。
7. 分层系统的问题先分层定位,再在正确的层深入。

写在最后

回头看,这场由"JVM 没感知容器内存限制"引发的、反复 OOMKilled 的事故,真正教给我的,远不止"设 -XX:MaxRAMPercentage"这一个技巧。它让我对"一个个体, 若不了解'自己被置于一个什么样的、有着真实边界的环境中', 仍按'过去那个更大的世界'的习惯去索取和行动, 就会撞上新环境的墙",有了一次刻骨的体会。我栽跟头,是因为那个 JVM(以及写它的我)没意识到"它已经从一台大机器, 搬进了一个 512Mi 的小盒子"——它还带着"我有几十 G 内存可用"的旧认知,大手大脚地规划自己的堆;它不是恶意的、也不是算错了,它只是用一个'对当前环境不再成立'的旧前提'在行动;而新环境(容器)那真实的、远比它以为的小的边界,就那么冷冰冰地立在那儿,它一撞上去,就被无情地杀掉了。这让我领悟到一个关于"个体与其所处环境"的深刻认知:一个个体(进程、组件、乃至人)能否正常运转,不仅取决于"它自己的逻辑对不对",还极大地取决于"它对'自己所处环境的真实约束'的认知是否准确";"带着对旧环境的认知, 进入新环境",是一类极其普遍的错误来源——因为旧认知里"理所当然成立"的前提(资源充裕),在新环境里可能根本不成立。这给了我一种适应环境的根本清醒:当我的程序(或我自己)被置于一个"新的、有着不同约束的环境"中时(从物理机到容器、从单机到云、从内网到公网、从小流量到大流量),第一件事应该是主动地、清醒地去认知"这个新环境的真实边界和约束是什么",并据此调整自己的行为和预期——而不是惯性地沿用旧环境的假设;"主动认知并适配所处环境的真实约束、不被旧环境的惯性假设误导",是一个个体(或系统)在新环境中存活并良好运转的根本前提。认清个体运转取决于对所处环境约束的认知、进入新环境要主动认知并适配其真实约束——这,是我用一次 OOMKilled 的事故,换来的、关于容器化、也关于如何在受限环境中正确运转的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次把应用塞进容器时,记得给运行时配上容器感知、按 limit 留好余量,那我对着那反复重启的 OOMKilled 排查的这段时间,就值了。

—— 别看了 · 2026