OOM Killer 选中你的进程只用了 0.3 毫秒——追踪 oom_badness() 的打分公式和 5 个可调旋钮

一台 64GB 内存的服务器，跑着你的 Java 应用、Redis、MySQL、Nginx。某天凌晨 3:47，java 进程消失了。dmesg里一行冰冷的记录：

[14523.413289] Out of memory: Killed process 3742 (java) total-vm:8234512kB, anon-rss:4182736kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:12048kB score:653

score:653。内核在所有进程里算了一遍分，你的 java 拿了 653 分，最高。从开始扫描进程列表到最终发出 SIGKILL，整个选拔过程在几百微秒内完成。OOM Killer 不犹豫，不商量，不给你 graceful shutdown 的机会。SIGKILL 无法被捕获，无法被忽略。进程直接消失。

这篇拆一件事：OOM Killer 是怎么算出这个分数的，以及你有哪些旋钮可以拧。

OOM Killer 什么时候被触发

OOM Killer 不是一个独立的守护进程，不是一个定时任务，也不是谁手动调用的。它被嵌在内核的内存分配路径里——只有当一次内存分配请求走到了所有回收手段都失败的绝境时，才会被激活。

理解触发时机，要从 Linux 的内存分配入口说起。

从 alloc_pages 到山穷水尽

当内核需要分配物理页面时，调用