OOM Killer 在__alloc_pages_slowpath()彻底失败且out_of_memory()被调用时触发，非因“内存用光”，而是内核在page cache、swap等回收路径全失败后迫不得已的最后手段。
OOM Killer 是怎么被叫醒的？
它不是靠“内存用光了”才启动，而是内核在分配物理页失败时，走完所有回收路径后被迫触发的最后手段。关键节点是 out_of_memory() 函数被调用——这发生在进程真正写内存（缺页中断）且 __alloc_pages_slowpath() 无法再分配出页的时候。
- 系统先尝试回收 page cache、slab 等可再生内存；
- 若启用了 swap，还会尝试换出匿名页；
- 只有这些都失败，且
vm.panic_on_oom不为 2 时，才会进入 OOM killer 流程。
注意：free -m 显示还有几百 MB “available”，照样可能触发 OOM——因为内核要求保留至少 min_free_kbytes 的空闲页（默认可能高达 1GB），这部分不参与分配，也不计入 available。
谁会被挑中杀掉？看的是 oom_badness() 得分
现代内核（2.6.36+）打分逻辑已大幅简化：badness = (进程当前使用内存 / 其允许使用的内存上限) × 1000 + oom_score_adj。也就是说，不是单纯比谁占得多，而是比“超限程度”。
- 普通进程
oom_score_adj默认为 0； - 容器或 cgroup 里运行的进程，上限就是 cgroup 的
memory.limit_in_bytes，哪怕只用了 199MB，上限设为 200MB，得分也会接近 1000； - 系统关键进程（如
systemd）通常有负的oom_score_adj（比如 -1000），几乎不会被选中。
查某个进程得分：直接读 /proc/；调高保护优先级：写负值到 /proc/（例如 echo -500 > /proc/1234/oom_score_adj）。
cgroup 场景下 OOM 的真实归属容易误判
日志里写着 “Task in /mm_test/2 killed as a result of limit of /mm_test”，说明被杀的进程本身没超限，但它的父 cgroup /mm_test 达到了内存上限。这种嵌套限制下，oom_score 计算的“上限”是父级 limit，而不是进程所在子 cgroup 的 limit。
- 查 cgroup 内存使用：
cat /sys/fs/cgroup/memory/mm_test/memory.usage_in_bytes和memory.limit_in_bytes； - 如果
failcnt在增长（cat /sys/fs/cgroup/memory/mm_test/memory.failcnt），说明该 cgroup 已反复触发内存分配失败； - 别只盯着被杀进程的 RSS，要顺藤摸瓜查整个 cgroup 树的配额和实际用量。
为什么 overcommit_memory 会影响 OOM 触发时机？
这个参数控制内核对“内存申请”的信用额度：overcommit_memory=0（默认）表示按启发式规则判断是否允许过量分配；=1 表示永远允许；=2 表示严格禁止（总申请量 ≤ 物理内存 + swap）。
- 设为 2 后，
malloc()可能直接失败（返回 NULL），应用需自己处理；但好处是几乎不会走到 OOM killer 这步； - 设为 0 时，看似安全，但一旦大量进程同时把虚拟内存“落实”为物理页，就极易集中触发 OOM；
- Java 应用常因
-Xmx设得过大，在overcommit_memory=0下成为 OOM killer 首选目标——它申请了大量虚拟内存，又很快全部触碰。
真正难排查的 OOM，往往不是内存真不够，而是 cgroup 配额卡死、min_free_kbytes 设置失当、或 overcommit 策略与应用行为错配。盯日志里的 gfp_mask 和 limit of 字样，比看 free 输出管用得多。
