在 Linux 运维与后端开发面试中，OOM Killer 是一个高频考点。很多候选人对它的理解停留在“内存不够就杀进程”，但真正被追问触发条件、内核评分机制、如何保护关键进程时，往往答不完整。本文从面试题的角度，系统梳理 OOM Killer 的工作机制与实战防护手段。
一、OOM Killer 是什么
OOM Killer（Out-Of-Memory Killer）是 Linux 内核在物理内存和交换空间都严重不足时，为保护系统整体可用性而采取的最后手段：它会根据一套评分算法选择一个“最该被牺牲”的进程并杀死它，从而释放内存，避免系统完全死锁。
需要强调的是，OOM Killer 是“兜底机制”，不是正常的内存管理手段。它的出现通常意味着内存规划或应用本身存在问题。
二、触发条件：内核在什么情况下调用 OOM Killer
面试中最容易被追问的就是“到底什么时候才会触发”。核心判断逻辑是：内存分配请求无法被满足，且内核已尝试回收但失败。
具体来说，触发通常经历以下过程：
- 内存分配失败路径：进程调用
malloc或内核态申请内存时，最终走到__alloc_pages等分配函数。 - 尝试直接回收：内核会先尝试直接内存回收（direct reclaim），包括回收 page cache、slab 等可回收内存。
- 回收失败：如果回收后仍无法满足分配需求，就进入 OOM 判断逻辑。
- 触发 OOM Killer：内核调用
out_of_memory()，开始选择并杀死进程。
触发场景可以归纳为几类：
- 物理内存 + Swap 均耗尽：这是最典型的场景。
- cgroup 内存限制被突破：在容器（Docker/K8s）中，cgroup v1 的
memory.limit_in_bytes或 cgroup v2 的memory.max达到上限时，会触发 cgroup 级别的 OOM Killer，只影响该 cgroup 内的进程。 - NUMA 节点内存耗尽：在 NUMA 架构下，某个节点的内存耗尽也可能触发 OOM。
- 内存碎片导致高阶分配失败：即使总空闲内存看似充足，但无法满足连续大块内存分配时也可能触发。
一个常见误区是“只要 free 显示内存不足就会 OOM”。实际上内核会优先回收缓存，只有当可回收内存也无法满足时才会动手。
三、OOM 评分机制：内核如何选择牺牲者
内核为每个进程维护一个 oom_score，取值范围 0~1000，分数越高越容易被杀。它的计算大致基于：
- 进程占用的内存量：包括 RSS、页表、Swap 等，占用越多分数越高。
- 进程运行时长与权限：通过
/proc/<pid>/oom_score_adj（旧版为oom_adj）进行调整。 - 是否为特权进程：内核通常会给 root 进程一定的“豁免”倾向，但并非绝对。
关键的可调参数是 oom_score_adj：
- 取值范围 -1000 到 1000。
- 设为 -1000 表示该进程几乎完全免疫 OOM Killer。
- 设为 1000 表示最优先被杀。
- 默认值为 0。
最终是否被杀，取决于 oom_score + oom_score_adj 的综合结果，内核会选择得分最高的进程。
四、如何保护关键进程
这是面试的实战落点，回答要分层次。
1. 调整 oom_score_adj
对关键进程（如数据库、核心服务）设置较低甚至 -1000 的值：
# 临时设置
echo -1000 > /proc/<pid>/oom_score_adj
# 查看当前值
cat /proc/<pid>/oom_score_adj
注意：设为 -1000 后该进程基本不会被杀，但如果系统内存真的耗尽，可能转而杀死其他进程甚至导致系统不稳定，因此要谨慎。
2. 使用 systemd 配置
对于 systemd 管理的服务，可在 unit 文件中声明：
[Service]
OOMScoreAdjust=-900
这样服务启动时自动应用，无需手工干预。
3. 容器环境中的保护
在 Docker 中可通过 --oom-score-adj 调整，或使用 --oom-kill-disable 禁用该容器的 OOM Killer（需配合内存限制使用，否则有风险）。在 Kubernetes 中，可通过 Pod 的 oomScoreAdj 字段或 QoS 等级（Guaranteed）来降低被杀概率。
4. 配置 cgroup 内存限制与预留
合理设置 cgroup 内存上限，避免单个容器耗尽宿主机内存。同时为系统关键组件（如 kubelet、sshd）预留足够内存，防止它们被误杀。
5. 从根源上避免 OOM
- 合理规划内存容量，监控内存使用趋势。
- 优化应用内存占用，修复内存泄漏。
- 配置足够的 Swap（但 Swap 不能替代物理内存）。
- 使用
vm.overcommit_memory等参数控制内存分配策略。
五、常见面试追问
- oom_score 和 oom_score_adj 的区别？ 前者是内核计算出的基础分，后者是用户可调的偏移量。
- 为什么我的进程没占多少内存却被杀了？ 可能因为其他进程的 adj 被调低，导致它相对得分最高。
- cgroup OOM 和全局 OOM 有何不同？ cgroup OOM 只影响该控制组内进程，全局 OOM 影响整个系统。
- 如何查看是否发生过 OOM？ 使用
dmesg | grep -i oom或查看/var/log/messages，内核会打印被杀进程的详细信息。
总结
OOM Killer 的触发本质是“内存分配无法满足且回收失败”，其选择逻辑基于 oom_score 与 oom_score_adj 的综合评分。保护关键进程的核心手段是调整 oom_score_adj、借助 systemd 或容器编排平台声明优先级，同时从内存规划、监控和代码优化层面根治问题。面试中若能讲清触发路径、评分机制和分层防护方案，基本就能拿到高分。
未经允许不得转载：任鹏个人博客 » Linux 面试题：OOM Killer 的触发条件与如何保护关键进程
