1. OOM Killer 概述
OOM Killer（Out-Of-Memory Killer）是 Linux 内核在系统物理内存耗尽时启动的最后一道保护机制。当内核无法通过常规内存回收（如 kswapd、直接回收、页面换出）满足新的内存分配请求时，OOM Killer 会强制终止一个或多个进程，以释放内存并恢复系统的可用性。
1.1 什么是 OOM Killer
OOM Killer 不是一个常驻的守护进程，而是嵌入在 Linux 内核 mm/oom_kill.c 中的一组决策与执行逻辑。它在以下调用路径中被触发：
- 直接回收失败：
__alloc_pages_slowpath()中所有回收尝试均告失败。 - 水位线检查：分配请求无法满足最低水位线
min_free_kbytes的要求。 - 无可用页面：所有内存节点（NUMA node）均无空闲页面可分配。
关键事实：OOM Killer 是内核内存管理的最后防线，它的存在意味着系统已经处于极端内存压力状态。调优的目标是尽可能避免触发 OOM Killer，而不是优化它杀进程的效率。
1.2 OOM Killer 在 Linux 内存管理中的角色
Linux 内存管理采用分层回收策略，OOM Killer 位于最底层。下表展示了内存回收的完整层级：
| 层级 | 机制 | 触发条件 | 影响范围 |
|---|---|---|---|
| 1 | kswapd 后台回收 | 空闲内存低于 pages_low 水位线 |
全局，异步，无感知 |
| 2 | 直接回收（direct reclaim） | 分配路径中水位线不足 | 当前进程阻塞等待 |
| 3 | 页面换出（swap） | 匿名页可换出至交换分区 | I/O 延迟增加 |
| 4 | 内存压缩（compaction） | 需要连续大页（order > 0） | CPU 开销上升 |
| 5 | OOM Killer | 所有回收手段均失败 | 进程被终止，数据丢失 |
从架构角度看，OOM Killer 是内存管理子系统中与页面分配器（page allocator）直接交互的组件。以下 SVG 图展示了 OOM Killer 在内存分配路径中的位置：
1.3 为什么需要 OOM Killer
OOM Killer 的存在基于以下三个核心理由：
- 防止内核崩溃：如果内存分配请求永远无法满足，内核可能进入无限循环或触发 kernel panic。OOM Killer 提供了一种可控的降级手段。
- 保障系统整体可用性：牺牲一个或少数进程，换取整个操作系统继续运行的能力。在服务器场景中，这意味着 SSH 连接、监控代理等关键服务可以存活。
- 处理内存泄漏与超卖：应用程序的内存泄漏、cgroup 内存限制配置不当、虚拟机/容器内存超卖（overcommit）都可能导致物理内存耗尽。OOM Killer 是应对这些异常的最后手段。
调优视角：在生产环境中，OOM Killer 触发通常意味着内存配置存在根本性问题。调优的目标不是让 OOM Killer 更“聪明”地杀进程，而是通过合理设置
vm.overcommit_ratio、vm.min_free_kbytes、cgroup 内存限制和 swap 策略，将 OOM Killer 的触发概率降到最低。
1.4 OOM Killer 的触发条件与决策流程
OOM Killer 的触发并非瞬间完成，它遵循严格的检查与决策流程。以下 SVG 图展示了完整的触发链路：
1.5 OOM Killer 与内存超卖的关系
内存超卖（Memory Overcommit）是 OOM Killer 最常见的触发场景之一。Linux 内核默认允许进程申请比物理内存更多的虚拟内存（vm.overcommit_memory=0），这种设计在以下情况下会直接导致 OOM：
| 场景 | 描述 | OOM 风险 |
|---|---|---|
| 容器/虚拟机超卖 | 宿主机上所有容器承诺内存总和 > 物理内存 | 高 |
| 内存泄漏应用 | 进程持续分配但不释放，逐渐耗尽系统内存 | 中高 |
| fork() 写时复制 | 父进程 fork 子进程时，内核乐观分配但不实际占用 | 中 |
| 大页配置不当 | hugetlb 预留过多，导致普通页面不足 | 中 |
实战警告：在内存超卖环境中，单纯依赖 OOM Killer 来回收内存是极其危险的做法。正确的做法是使用 cgroup 的
memory.limit_in_bytes 和 memory.oom_control 进行容器级内存隔离，并配合 vm.overcommit_ratio 控制全局超卖比例。后续章节将详细讲解这些参数的调优方法。