容器明明限制了 1G 内存,Java 服务却一上线就被 OOMKilled 反复重启:我在 Docker 里栽进 JVM 看不见容器内存限制的那次排查

那次上线,差点把我整不会了。我把一个 Java 服务打包成 Docker 镜像,部署到 Kubernetes 上,给容器设了 limits: memory: 1Gi 的内存限制——我觉得 1G 对这个小服务绰绰有余。可服务一启动,跑不了几分钟,就被杀掉、重启;再跑几分钟,又被杀、又重启,陷入了 CrashLoopBackOff 的死循环。kubectl describe pod 一看,容器的上一次终止原因,赫然写着两个让我心头一紧的字:OOMKilled。

我当时一脸困惑:这服务在我本地、在没有内存限制的测试机上,跑得稳如老狗,内存占用我也观察过,也就几百兆,怎么到了限制 1G 的容器里,反而内存爆了、被 OOM 杀掉?1G 还装不下一个平时只用几百兆的服务?这不科学。我一头扎进排查,最后揪出的真凶,是一个我从没意识到的、容器化部署里极其经典的认知盲区:我那个跑在容器里的 JVM,它根本"看不见"容器 1G 的内存限制——它看到的,是宿主机那几十 G 的总内存,并据此,把自己的堆(Heap)撑到了远超 1G 的大小,结果自然被内核当成"超额使用内存的进程",一刀 OOMKilled。

故障现场:一个"看错了内存"的 JVM

我把现场还原一下。Dockerfile 和 k8s 配置,看起来都平平无奇:

# Dockerfile: 启动 Java 服务, 我没设任何 JVM 内存参数
FROM openjdk:8-jre
COPY app.jar /app.jar
CMD ["java", "-jar", "/app.jar"]   # ← 注意: 没有 -Xmx 限制堆大小!

# k8s deployment: 给容器限制了 1Gi 内存
resources:
  limits:
    memory: "1Gi"      # 容器内存上限 1G
  requests:
    memory: "512Mi"

我钻进容器里,打印了 JVM 实际"以为"自己能用的最大堆内存,结果让我大吃一惊:

# 进到容器里, 看 JVM 认为的最大堆内存
$ docker exec -it  java -XX:+PrintFlagsFinal -version | grep MaxHeapSize
    uintx MaxHeapSize    := 8589934592    # ← 8G!!!
#   ↑ JVM 认为它的最大堆可以用到 8G! 可容器明明只限制了 1G!

# 为什么是 8G? 因为这台宿主机有 32G 内存,
# 而 JVM(Java 8 早期版本)的默认堆大小, 是按"它看到的物理内存"的 1/4 算的:
#   32G / 4 = 8G
# 关键: JVM 看到的"物理内存", 是【宿主机】的 32G, 而不是【容器限制】的 1G!

# 于是: JVM 放心大胆地把堆往 8G 撑,
# 可容器内存一旦超过 1G, 就被内核的 cgroup OOM 机制一刀杀掉 → OOMKilled

真相浮出水面。那个跑在"1G 容器"里的 JVM,它打印出来的最大堆大小,竟然是 8G!它压根不知道自己被关在一个 1G 的"笼子"里,反而以为自己拥有宿主机那 32G 内存的世界,并按照"默认最大堆 = 物理内存的 1/4"这个规则,把自己的堆上限,定在了 32G / 4 = 8G。于是这个 JVM,会心安理得地、随着负载增长,把堆内存一路往 8G 的目标撑;可它所在的容器,内存一旦突破 1G 这条红线,就会被 Linux 内核的 cgroup OOM 机制毫不留情地杀掉。这就是 OOMKilled 反复发生的根源——一个"看错了自己能用多少内存"的 JVM,和一个"真实限制比它以为的小得多"的容器,之间的致命错位。

第一件事:搞懂 JVM 为什么"看不见"容器的内存限制

定位到现象,我必须搞懂背后的原理:为什么容器明明用 cgroup 限制了内存,JVM 却看不见,反而读到了宿主机的内存?查了资料,我把这条因果链彻底理清了。

# 真相: 容器, 本质上不是"虚拟机", 而是宿主机上一组被"隔离"和"限制"的进程。
#   - 隔离(namespace): 让容器有自己独立的进程、网络、文件系统视图
#   - 限制(cgroup): 限制容器能用多少 CPU、多少内存

# 关键问题: 容器的内存限制, 是通过 cgroup 实现的,
#   它记录在 /sys/fs/cgroup/memory/memory.limit_in_bytes 这类文件里。

# 而 JVM(尤其是 Java 8u131 之前的老版本)获取"物理内存大小"时,
#   走的是传统的系统调用(如读 /proc/meminfo), 拿到的是【宿主机】的总内存!
#   它【根本没有去读 cgroup 的内存限制】, 所以它对"我被限制了多少", 一无所知。

$ cat /proc/meminfo | grep MemTotal
MemTotal:  32000000 kB    # JVM 读到这个 → 宿主机 32G

$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes
1073741824                # 真实的容器限制 1G, 但老 JVM 不看这个!

# 结论: 老 JVM "感知"内存的方式, 和"容器限制内存"的方式, 是两套体系,
#   JVM 看的是宿主机总内存, 看不见 cgroup 给它划的那道 1G 的线。

原理终于清晰了。核心在于:容器,本质上不是一台独立的"虚拟机",而是宿主机上一组被 namespace"隔离"、被 cgroup"限制"的进程。容器的内存限制(1G),是通过 Linux 的 cgroup 机制施加的,记录在 cgroup 的特定文件里。而老版本的 JVM,在获取"物理内存有多大"时,走的是传统路径——它去读 /proc/meminfo 这类反映宿主机信息的接口,拿到的是宿主机那 32G 的总内存;它压根没有去读 cgroup 的内存限制文件,所以它对"我其实被限制在 1G 之内"这件事,毫无感知。这就造成了那个致命的认知错位:"限制容器内存"用的是 cgroup 这套体系,而"JVM 感知内存"用的是读宿主机信息这套体系,两套体系各说各话——JVM 自信地以为自己有 32G、能开 8G 的堆,殊不知它脚下,早被 cgroup 划了一条 1G 的、它看不见的红线。它一旦越线,就被 OOMKilled。

第二件事:正解——让 JVM "看见"容器限制,或直接显式设堆

搞懂了根因,解法就有了两个方向:要么,让 JVM 学会去读 cgroup 的内存限制(用新版本 JDK 或开启对应参数);要么,干脆别让 JVM 去猜,我直接显式地告诉它"你的堆最多能用多少"。

# 正解1(推荐): 用 Java 10+ (或 Java 8u191+), 并开启容器感知
#   这些版本的 JVM, 默认会去读 cgroup 限制, "看得见"容器内存了。
java -XX:+UseContainerSupport \
     -XX:MaxRAMPercentage=75.0 \
     -jar /app.jar
#   ↑ UseContainerSupport: 让 JVM 感知容器内存限制 (Java 10+ 默认开启)
#   ↑ MaxRAMPercentage=75: 堆最多用"容器限制"的 75% (1G * 75% = 768M)
#   现在 JVM 看到的是 1G, 堆按 1G 的 75% 算, 不会再撑到 8G 了!

# 正解2(最直接、最保险): 显式设置 -Xmx, 别让 JVM 自己猜
java -Xmx700m -Xms700m -jar /app.jar
#   ↑ 直接把最大堆钉死在 700M, 给容器 1G 限制留出足够余量
#   (堆之外, JVM 还要用元空间、线程栈、直接内存等, 所以 -Xmx 要明显小于容器限制!)

# 反例(我踩的坑): 啥都不设, 让老 JVM 自己猜 → 它按宿主机 32G 猜出 8G 堆 → OOMKilled
java -jar /app.jar   # ✗ 危险!

这两个正解,从不同角度根治了问题。正解1(容器感知)是治本的:升级到 Java 10+(或 Java 8u191+),这些版本的 JVM 默认开启了 UseContainerSupport,它们学会了去读 cgroup 的内存限制,从而"看得见"容器那 1G 的真实上限;再配合 MaxRAMPercentage,让堆按"容器限制"的百分比来算,就再也不会撑爆了。正解2(显式设堆)则是最直接、最保险的:-Xmx700m 直接把最大堆钉死,根本不给 JVM "自己猜"的机会。这里有一个极其关键、却常被忽略的细节:-Xmx 一定要明显小于容器的内存限制!因为容器的内存,不只被 JVM 的"堆"占用——堆之外,JVM 还需要元空间(Metaspace)、线程栈、JIT 编译的代码缓存、直接内存(Direct Memory)等"堆外内存"。所以容器 1G,堆绝不能也设成 1G,而要留出 25%~30% 的余量给这些堆外开销——比如设 -Xmx700m,给堆外留 300M。否则,哪怕 JVM 看见了 1G、把堆设成 1G,加上堆外开销,照样会突破 1G 被 OOMKilled。

下面这张图,把"JVM 看不见限制"的坑和"让它看见/显式设堆"的解,画在一起:

这张图的三条路径,清晰地呈现了问题与解法:红色那条,是老 JVM"读错了内存"导致堆撑爆、OOMKilled;两条绿色路径,要么靠新 JVM 的容器感知"看见"真实限制,要么靠显式 -Xmx 直接钉死堆大小——殊途同归,都是让"JVM 实际会用的内存",牢牢地控制在容器限制之内。

第三件事:这不只是 JVM 的坑,是"容器里的程序看错资源"的通病

填平了 JVM 这个坑,我意识到一件更普遍的事:"程序在容器里,看到的是宿主机的资源、而非容器限制"——这个问题,绝不只发生在内存、也绝不只发生在 JVM 身上。它是一类通病,几乎所有"会根据‘可用资源’自动调整行为"的程序,在容器里都可能踩。我顺藤摸瓜,排查了其它几个常见的"亲戚坑":

# 亲戚坑1: CPU 核数——程序看到的是宿主机的核数, 而非容器 CPU 限制
#   很多程序按"CPU核数"决定线程池大小、并行度:
#   - Java 的 ForkJoinPool、GC 线程数, 默认按 Runtime.availableProcessors()
#   - Go 的 GOMAXPROCS 默认 = 机器核数
#   容器限制了 1 核, 但程序看到宿主机 32 核 → 开了 32 个线程/协程并行 → 上下文切换爆炸
#   正解: 新 JVM 容器感知 / 显式设线程数; Go 用 uber/automaxprocs 读 cgroup

# 亲戚坑2: Node.js 的内存——同理, --max-old-space-size 不设也可能不匹配容器
node --max-old-space-size=512 app.js   # 显式限制, 别让它按宿主机猜

# 亲戚坑3: 各种"自动探测资源"的中间件/连接池
#   一些连接池、缓存库, 会按"可用内存/CPU"自动配置容量, 同样会被宿主机资源误导

# 根本认知: 容器是"隔离+限制", 不是"虚拟机";
#   程序如果用"老办法"探测资源, 探到的是宿主机的, 而非自己被限制的那份。

这一排查,让我对这个坑的本质有了全局认识。它的根源,是一个对"容器到底是什么"的普遍误解:很多人(包括曾经的我)下意识地把容器当成一台"轻量级虚拟机",以为容器里的程序,看到的就是这台"虚拟机"被分配的资源。可事实是,容器不是虚拟机——它只是宿主机上一组被 namespace 隔离、被 cgroup 限制的普通进程;而程序如果用"传统的、面向物理机的方式"去探测 CPU、内存等资源,它探到的,往往是宿主机的资源,而不是 cgroup 给它划定的那一份。亲戚坑1(CPU 核数)尤其常见且隐蔽:程序按"看到的核数"决定线程池、并行度、GC 线程数,容器限了 1 核它却看到 32 核,于是开出 32 路并行,反而因为疯狂的上下文切换而性能暴跌。所以,真正要建立的认知是:在容器里,凡是"程序会根据可用资源自动调整行为"的地方,都要警惕它有没有‘看错’资源——要么用支持容器感知的新版本,要么干脆显式地、明确地告诉它"你只有这么多 CPU、这么多内存",别让它自己去猜。

第四件事:OOMKilled 排查,要分清"谁杀了谁"

这次事故也让我把"容器内存相关的故障到底怎么排查"系统地理了一遍。我发现,内存问题在容器里其实有好几种"死法",而它们的根因和解法各不相同,分不清就会误诊:

# 排查内存问题, 先分清是"谁"在喊内存不够、"谁"动的手:

# 死法1: 容器被 cgroup OOMKilled (本文的坑)
#   特征: kubectl describe pod 显示 State.Reason = OOMKilled, ExitCode 137
#   是【内核 cgroup】发现容器总内存超限, 杀了容器里的进程
kubectl describe pod  | grep -A3 "Last State"
#   根因: 容器实际用的内存(堆+堆外+其它) > limits.memory
#   解法: 调大 limits, 或调小 -Xmx / 减少内存使用

# 死法2: JVM 自己抛 java.lang.OutOfMemoryError
#   特征: 应用日志里有 OutOfMemoryError: Java heap space 堆栈
#   是【JVM 内部】发现堆不够用了, 自己抛异常 (容器内存可能还没满)
#   根因: -Xmx 设太小, 或真有内存泄漏
#   解法: 调大 -Xmx(在容器限制内), 或排查内存泄漏(dump 分析)

# 死法3: 容器内存没超, 但宿主机整体内存不足
#   特征: 宿主机 OOM, 可能杀掉"评分最高"的进程(不一定是你)
#   解法: 排查宿主机超卖、给容器设合理 requests

# 关键: ExitCode 137 = 128 + 9(SIGKILL), 常见于 OOMKilled;
#       ExitCode 1 + 日志里 OutOfMemoryError, 则是 JVM 自己 OOM。
docker inspect  --format='{{.State.ExitCode}} {{.State.OOMKilled}}'

这套排查思路的核心,是分清"内存不足"这件事,到底是"谁"察觉的、又是"谁"动的手。死法1(cgroup OOMKilled)就是我这次踩的——是内核的 cgroup 发现容器总内存(堆 + 堆外 + 其它进程)超过了 limits.memory,从外部把容器进程 SIGKILL 掉,特征是 ExitCode 137 和 OOMKilled 标记。死法2(JVM 自己 OOM)则不同——是 JVM 内部发现自己的堆不够用了,主动抛出 OutOfMemoryError 异常,这时容器总内存甚至可能还没满,根因往往是 -Xmx 设小了或真有内存泄漏。死法3是宿主机层面的内存不足。这三种"死法"的现象相似(都和内存有关),根因和解法却南辕北辙——分不清,就会犯"明明是 cgroup 把堆撑爆杀的、却去查堆内存泄漏"这种南辕北辙的错。把这几种内存"死法"整理成一张诊断表:

第五件事:把"容器资源配置"沉淀成一份检查清单

这次事故,让我把"把一个应用容器化部署时,关于资源该检查什么"沉淀成了一份清单。它的核心,是确保"应用以为自己能用的资源"和"容器实际限制的资源"严丝合缝地对上:

# 容器资源配置检查清单:

# 1. JVM 应用: 用容器感知 或 显式设堆, 且 -Xmx 明显小于 limit
#    java -XX:MaxRAMPercentage=75 ... (新版)  或  -Xmx700m (1Gi limit)

# 2. 同时设 requests 和 limits, 且 limit 给足"启动峰值 + 运行余量"
resources:
  requests: { memory: "512Mi", cpu: "500m" }
  limits:   { memory: "1Gi",   cpu: "1" }
# 3. -Xmx(堆) + 堆外(元空间/栈/直接内存) 的总和, 要 < limits.memory
#    经验: -Xmx 取 limit 的 50%~70%, 留足堆外空间

# 4. CPU 敏感的应用, 显式设并行度(线程池/GOMAXPROCS), 别让它按宿主机核数猜
# 5. 配置存活/就绪探针, 但 initialDelaySeconds 给足启动时间, 别启动慢就被误杀
livenessProbe:
  initialDelaySeconds: 60   # 给应用足够启动时间, 避免启动慢被反复重启
# 6. 上线后实际观测内存/CPU 曲线(如 Prometheus), 验证配置是否合理, 别拍脑袋
# 7. 镜像基础环境用支持容器感知的版本(JDK 11+ / 带 automaxprocs 的 Go 等)

这份清单的灵魂,是一句话:让"应用对自己资源的认知",和"容器对它的真实限制",严丝合缝地对齐。我这次的事故,本质就是这两者错位了——应用以为有 32G,容器实际只给 1G。清单里的每一条,都是在消除某一处可能的"错位":第 1、3、4 条,确保应用感知的内存/CPU 和容器限制一致;第 2、5 条,确保容器给的限制本身合理(给足启动峰值、给足启动时间);第 6 条,则用真实的监控数据,去验证这种对齐是否真的成立,而非凭感觉。我尤其想强调第 5 条——它是这次坑的一个"近邻":存活探针(liveness probe)如果 initialDelaySeconds 给得太短,一个启动较慢的应用,会在还没启动完时就被探针判定为"不健康"而杀掉重启,同样陷入 CrashLoopBackOff,现象和 OOMKilled 很像、却是另一个根因。把容器化部署的常见配置陷阱汇总成一张表:

一张"容器内 JVM 内存怎么配"的决策图

把这次踩坑沉淀成一张图。每当你要把一个 JVM 应用容器化部署时,照着它走:

这张图的主线是:新版 JDK 靠容器感知 + MaxRAMPercentage 自动对齐;老版 JDK 必须显式 -Xmx 且明显小于容器限制。无论哪条路,最终都要保证"堆 + 堆外 < limit",并用上线后的真实监控去验证。还在 OOMKilled,就回到第四步,分清是 cgroup 杀的还是 JVM 自己 OOM,对症下药。

我立下的几条容器化部署规矩

这次"1G 容器装不下几百兆服务"的乌龙事故后,我给自己立了几条规矩:

1. 容器里别让 JVM 自己猜内存:要么用支持容器感知的 JDK(10+/8u191+)+ MaxRAMPercentage,要么显式 -Xmx,绝不裸跑 java -jar。
2. -Xmx 明显小于容器 limit:堆只取 limit 的 50%~70%,给元空间、线程栈、直接内存等堆外开销留足余量。
3. CPU 并行度也要显式控制:线程池、GC 线程、GOMAXPROCS 别按宿主机核数猜,按容器 CPU 限制显式设。
4. 记住容器不是虚拟机:它是 namespace 隔离 + cgroup 限制的进程;凡"按可用资源自动调整"的程序,都要警惕它看错资源。
5. 分清内存"死法":OOMKilled(cgroup 杀)和 OutOfMemoryError(JVM 自己抛)根因不同,看 ExitCode 137 还是异常堆栈来区分。
6. 探针给足启动时间:liveness 探针 initialDelaySeconds 给足,别让启动慢的应用被误杀成 CrashLoop。
7. 上线后看监控验证:用真实的内存/CPU 监控曲线验证资源配置,而非拍脑袋设了就不管。

这几条里,第一条和第四条是根本。而贯穿所有规矩的那条主线,是对"容器到底是什么"的正确理解。我这次栽跟头,根子上是我心里对容器有一个错误的模型——我把它想象成了一台"被分配了 1G 内存的小虚拟机",以为里面的程序看到的就是这 1G。可容器根本不是虚拟机,它是宿主机上一组"被 cgroup 限制了资源、但很多时候还能透过限制看到宿主机真实资源"的进程。正是这个错误的心理模型,让我对"JVM 会看到宿主机的 32G 而非容器的 1G"这件事,毫无预判。当我把心理模型纠正成"容器 = 隔离 + 限制的进程,而非虚拟机"后,这一整类'容器里程序看错资源'的坑,就都变得可以预见、可以防范了。一个正确的底层心理模型,是避开这类坑的根本。

写在最后:你脑中的"模型"对不对,决定了你能不能预见坑

这次被容器内存坑到的经历,让我对"心理模型(mental model)"这件事的重要性,有了极深的体会。我们每个人,在使用一项技术时,脑子里都会不自觉地建立起一个关于"它是怎么工作的"的简化模型——而这个模型的准确程度,几乎直接决定了我们能不能预见到那些隐藏的坑。一个准确的模型,会让你对各种边界情况了然于胸、提前防范;而一个虽然"好用"、却在关键处失真的模型,则会让你在它失真的地方,毫无防备地一脚踏空。我把容器理解成"轻量虚拟机",这个模型平时用着也没大错、还挺顺手;可恰恰在"容器里的程序如何感知资源"这个关键点上,它是失真的——而我这次,就精准地栽在了这个失真点上。

想通这一点,我对"建立准确的底层心理模型"这件事,变得格外上心。很多时候,我们学一项技术,满足于学会"怎么用它的 API、怎么配它的参数",却很少去深究"它在底层到底是怎么运作的、它真实的样子是什么"。这种停留在"会用"层面的学习,会给我们一个粗糙的、甚至失真的心理模型——它在常规场景下够用,却会在某个我们没料到的边界,暴露出它的不准确,把我们坑得措手不及。而那些真正的高手,他们脑中关于各种技术的心理模型,往往要准确、要接近本质得多——正因如此,他们才能在别人一脸懵的地方,一眼看穿问题的根源,甚至在写代码时,就提前预判并避开那些隐藏的坑。心理模型的准确度,是区分"会用"和"精通"的一道隐形分水岭。

所以,如果你也想成为能"预见坑"而非总是"踩了坑才知道"的工程师,我想把这次踩坑最想说的话送给你:对你所使用的每一项核心技术,都努力去打磨一个尽可能准确、尽可能接近本质的心理模型。别满足于"我会用它"——去追问它底层到底是什么、它真实的工作方式是怎样的、它和你脑中那个粗糙的类比(比如"容器就是虚拟机")之间,有哪些关键的、不容忽视的差异。因为你脑中那个关于技术的模型有多准确,你就有多大的能力去预见它的行为、防范它的坑;很多让人猝不及防的事故,追根溯源,都是因为我们脑中那个'自以为对'的模型,在某个关键处,其实是错的。那个把 1G 容器撑爆的 JVM,最终教给我的,正是这份对"心理模型准确性"的重视——它让我明白,真正的技术功力,不只在于你会用多少工具,更在于你脑中关于这些工具的图景,究竟有多清晰、多真实、多接近它本来的样子。

—— 别看了 · 2026