深夜告警：某个 Java 服务毫无征兆地被杀，进程直接消失，日志里却找不到崩溃栈。OOM Killer（Out-Of-Memory Killer）正是 Linux 内核在物理内存与交换分区全部耗尽时，主动挑选并强制终止占用内存最高的进程，以保全系统不整体死锁。理解它的触发逻辑与排查手段，是每一位运维与后端工程师的必修课。
一、什么是 OOM Killer
当应用申请内存而内核无法满足，且开启了内存过量分配（overcommit）时，内核并不会立刻拒绝，而是寄希望于进程“用多少才真的占多少”。一旦所有可回收页（文件缓存、匿名页、swap）都被吃光，内核的“内存分配失败兜底机制”便会启动——这就是 OOM Killer。它会遍历所有进程，按 oom_score 打分，分数最高者被 SIGKILL，且这个信号无法被捕获或忽略，进程瞬间消失。
为什么内核要“杀进程”而不是直接返回分配失败？因为现代应用大多假设内存申请总会成功（尤其 C 库的 malloc、Java 的堆分配）。如果内核在关键时刻拒绝分配，大量进程会集体崩溃，反而造成更不可控的雪崩。与其让整个系统陷入不确定状态，内核选择牺牲一个进程来换取整体的存活。这是一个典型的“两害相权取其轻”的设计取舍。
二、内存过量分配：overcommit 的三种模式
OOM 能不能发生，和内核的 vm.overcommit_memory 配置强相关。它有三个取值，决定了内核面对内存申请时的态度：
# 查看与调整过量分配策略
sysctl vm.overcommit_memory
cat /proc/sys/vm/overcommit_memory
# 0 = 启发式（默认）：允许适度超卖，激进申请会被拒
# 1 = 总是允许：任何 malloc 都返回成功，最容易触发 OOM
# 2 = 严格：不允许超过 swap + overcommit_ratio% 的物理内存
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=90 # 允许超卖物理内存的 90%| overcommit_memory | 行为 | OOM 风险 |
|---|---|---|
| 0（默认） | 启发式超卖，过度申请会被拒 | 中 |
| 1（总是允许） | 任何申请都成功 | 高，最易触发 |
| 2（严格） | 受 swap+ratio 硬约束 | 低，但 malloc 会直接失败 |
绝大多数发行版默认是 0，这已经能在内存真正枯竭时引出 OOM Killer。如果你的服务对分配失败极其敏感（例如数据库），可以考虑设为 2 并用 ratio 精确控制上限，但这要求你对真实内存峰值有准确把握，否则业务会频繁拿到 NULL 而崩溃。
三、为什么会被 OOM Kill
内存并非只有“你申请的那部分”。一个进程实际占用包含：匿名内存（堆、栈、malloc）、文件映射、共享库，以及内核为其缓存的页。当下列情况叠加，系统可用内存触底：
- 单进程内存泄漏或缓存无上限（常见于未限制堆的 JVM、失控的本地缓存）。
- 容器或 cgroup 内存限额设置过小，宿主机还有余量但容器内已超限。
- swap 被关闭或过小，无法兜底瞬时峰值。
- 文件页缓存被大量业务读盘挤占，可回收空间骤减。
判断“还差多少就爆”最直接的入口是 /proc/meminfo 的 MemAvailable 字段——它估算了在不触发 OOM 的前提下，还能分给新进程的内存量。运维巡检时盯住它比死盯 free 的 used 更准：
grep -E "MemTotal|MemFree|MemAvailable|Buffers|Cached" /proc/meminfo
# MemAvailable: 812344 kB ← 这是真正的安全余量
free -m
# 关注 available 一列，而非单纯的 free四、如何确认进程是被 OOM Kill 的
进程被 SIGKILL 通常不会留下业务日志，但内核 ring buffer 与系统日志会记录。首选 dmesg 查看最近一次 OOM 事件：
dmesg -T | grep -i "killed process"
# 输出类似：
# [Tue Oct 27 03:11:02 2026] Out of memory: Killed process 8812 (java) # total-vm:8453120kB, anon-rss:6210040kB, file-rss:120kB, shmem-rss:0kB
若 dmesg 已滚动覆盖，可在系统日志里翻找（发行版路径不同）：
grep -i "out of memory" /var/log/syslog
grep -i "oom" /var/log/kern.log
# systemd 主机也可直接查 journal：
journalctl -k | grep -i "killed process"在 cgroup v2 体系中，还可以直接读取内存事件的计数器，它比翻日志更结构化，适合写进监控：
# cgroup v2：被 OOM 杀掉的累计次数
grep oom_kill /sys/fs/cgroup/your-group/memory.events
# oom_kill 12 ← 该 cgroup 已被杀 12 次
# cgroup v1：
cat /sys/fs/cgroup/memory/your-group/memory.oom_control下面这张对照表能帮你快速区分“真 OOM”与其他进程消失原因：
| 现象 | 排查命令 | 指向 |
|---|---|---|
| 进程消失，内核有 Killed 记录 | dmesg -T | grep -i killed | OOM Killer 所为 |
| 进程退出码 137 | echo $?（容器 inspect） | SIGKILL，多因 OOM/cgroup |
| 无 Killed 记录但退出 | journalctl _PID=PID | 业务主动退出/崩溃 |
| 磁盘满导致写失败 | df -h | 非内存问题 |
五、读懂 oom_score 与 oom_score_adj
每个进程在 /proc/<pid>/ 下都有三个关键文件：oom_score（内核实时打分，越高越先被杀）、oom_score_adj（−1000~1000 的可调权重）、oom_adj（旧接口，已废弃）。排查某进程是否“高危”可直接读取：
cat /proc/8812/oom_score # 当前分数，越大越危险
cat /proc/8812/oom_score_adj # 管理员调整值，-1000 表示永不被杀
cat /proc/8812/oom_adj # 旧接口，建议只看前两者
# 保护关键进程（如数据库）不被误杀：
echo -500 > /proc/$(pidof mysqld)/oom_score_adj注意 oom_score_adj=-1000 等同于完全免疫 OOM，但滥用会让真正的内存泄漏无处释放，最终拖垮整机，请只对真正不可替代的核心进程使用。一个常见的误区是给所有“重要”进程都设 −1000，结果泄漏进程永远不死，内存被一点点吃光，最后连设了 −1000 的进程也因为整机无内存可申请而卡死——因为 −1000 只保证“不被选作祭品”，却不能凭空变出内存。
六、真实案例：Java 服务半夜被 Kill
某次线上一个批处理 Java 服务在凌晨被反复 Kill。排查链路如下：先用 dmesg 确认是 OOM（Killed process 指向 java，anon-rss 高达 6GB）；再看 JVM 启动参数发现 -Xmx 未设上限，且批处理把全量数据读进内存；进而对比宿主机发现并非整机内存不足，而是该进程自身无界增长。临时止血是把 oom_score_adj 调低并加 swap，根治则是给 JVM 设 -Xmx4g 并改为流式处理。
复盘时我们列了一个时间线：23:50 监控告警内存使用率突破 95%；00:10 该服务响应变慢（GC 频繁，Young 区被快速填满）；03:11 内核触发 OOM，服务进程被杀；03:12 守护进程（systemd 的 Restart=always）将其拉起，但几分钟后再次因同样原因被杀，形成“被杀—重启—再被杀”的循环。最终定位到是批处理把整张千万级订单表一次性 load 进 List，堆随数据量线性膨胀。修复后改用游标分页流式处理，峰值内存从 6GB 降到 400MB。
这类“进程莫名消失”的坑，和 Docker 磁盘空间爆满、Nginx 504 网关超时 一样，都属于典型的线上突发故障，建议纳入巡检清单。如果是跑在 Docker 容器 里的服务，记得把内存上限写进 -m 参数，爆炸半径才可控。
七、防护与调优手段
防护的核心思路是“让该死的死、不该死的活”，并给内存峰值留出缓冲：
# 1) 整机策略：内存耗尽时宁可 panic 重启，也不乱杀（谨慎使用）
sysctl -w vm.panic_on_oom=1
# 2) 容器层面硬性限额，把爆炸半径锁在容器内
docker run -d -m 512m --memory-swap=512m myapp:latest
# 3) Kubernetes 通过 resources.limits 约束
# resources:
# limits:
# memory: 1Gi
# 4) 保留适量 swap 兜底瞬时峰值（不要完全关 swap）
swapon -s
sysctl -w vm.swappiness=10不同防护手段的适用场景对照：
| 手段 | 作用 | 适用场景 |
|---|---|---|
| oom_score_adj 调低 | 降低被杀优先级 | 保护 DB/核心守护进程 |
| cgroup 内存限额 | 隔离爆炸半径 | 容器、多租户主机 |
| 保留 swap | 兜底瞬时峰值 | 内存偶尔抖动的服务 |
| panic_on_oom=1 | 整机重启而非乱杀 | 无状态可自动拉起集群 |
八、把 OOM 纳入监控告警
等进程被杀再去翻日志永远是被动救火。把 OOM 信号接入监控，才能在内存逼近红线时提前干预。最轻量的做法是用 node_exporter 暴露的 node_vmstat_oom_kill 指标，或在 cgroup 里读 memory.events 的 oom_kill 计数，配一条阈值告警即可：
# Prometheus 示例：检测 OOM 发生次数增长
increase(node_vmstat_oom_kill[5m]) > 0
# 或基于 cgroup v2 的 oom_kill 计数（容器场景更准）
# 用 textfile collector 暴露：
grep oom_kill /sys/fs/cgroup/.../memory.events | awk '{print "oom_kill_total " $2}' > /var/lib/node_exporter/oom.prom更前置的预警是盯住 MemAvailable 占 MemTotal 的比例，低于 10% 就告警，通常能比 OOM 早十几分钟发现问题，给扩容或限流留出窗口。配合 Redis 缓存 与限流、以及在 Docker 运维 中固化巡检脚本，能把这类“半夜救火”的发生概率压到最低。
九、运维速查清单
- 进程神秘消失先跑
dmesg -T | grep -i killed确认是否 OOM。 - 看
/proc/<pid>/oom_score判断谁是下一个“祭品”。 - 核心进程用
oom_score_adj加权保护，勿滥用 −1000。 - 容器/服务务必设内存上限，避免单进程拖垮整机。
- 保留少量 swap，给峰值留缓冲，别把 swap 全关。
- 盯住
MemAvailable比例做前置预警，而非等 OOM 发生。 - 应用层根治才是王道：修复泄漏、设堆上限、改流式处理。
OOM Killer 不是敌人，它是内核在极端情况下的最后一道保险。真正该做的是在它出手之前就看见内存的红线和增长的趋势——理解打分逻辑、配好防护权重、接上监控告警，让“半夜被杀”变成“白天已扩容”。更多自动化排查可参考 Docker 运维实战 与 CI 巡检实践，把命令固化进流水线，才算真正闭环。
