OOM killer按cgroup局部决策，oom_score_adj仅在同cgroup内生效；badness得分由实际内存占用（含匿名页等）、cgroup压力系数等加权计算，-1000不等于免疫。
进程被 OOM kill 却已将 oom_score_adj 设为较低值（比如 -1000），仍被选中，往往不是因为配置没生效，而是内核在最终决策时引入了几个**不常被文档强调、但实际起决定性作用的隐藏规则**。
内存压力来源决定“谁该死”的优先级范围
OOM killer 不是全局扫描所有进程挑分最低的，而是先聚焦于**触发 OOM 的内存域（memory cgroup 或 NUMA node）内正在分配失败的进程所属的 cgroup**。即使你把某个后台服务的 oom_score_adj 调到 -1000，只要它恰好运行在当前内存紧张的 cgroup 里，而同 cgroup 内其他进程的分更高，它就可能成为备选——哪怕宿主机上还有大量空闲内存。
- 检查方式：
cat /proc/看进程归属；/cgroup cat /sys/fs/cgroup/memory/查该 cgroup 是否已触发过 OOM/memory.oom_control - 关键点：OOM 是按 cgroup 隔离粒度触发的，
oom_score_adj只在本 cgroup 内有效
实际内存占用 ≠ RSS，内核看的是 badness score 的完整计算逻辑
oom_score_adj 只是 badness 公式中的一个偏移项，真正得分由以下几项加权得出：
-
进程实际使用的内存页数（包括匿名页、文件缓存脏页、swapcached 页等） —— 这比
rss更大，尤其对 mmap 大文件、使用 tmpfs 或有大量 page cache 的进程影响显著 - 进程的 CPU 时间权重（越老的进程权重略低） —— 但影响微弱，通常可忽略
- 是否为 superuser 进程（uid 0）会轻微降低得分
- oom_score_adj 值线性叠加，但有上下限（-1000 到 +1000） —— 设为 -1000 并不等于“免疫”，只是让基础分归零；若其内存占用是同类进程的 10 倍，仍可能高于其他轻量进程
某些内存类型会被“加倍惩罚”
内核对以下两类内存，在计算 badness 时会额外加重计分：
- 不可回收的匿名页（如 malloc 分配、堆栈、mmap(MAP_ANONYMOUS)） —— 因无法写回磁盘，回收代价最高
-
属于 memcg 且超出 memory.high 限制后继续增长的内存 —— 此时该 cgroup 已进入“压力模式”，其内进程的 badness 会被乘以一个增长系数（2x~4x），
oom_score_adj无法抵消该放大效应
例如：一个 Java 进程设了 oom_score_adj = -1000，但它的 heap 和 metaspace 占用 4GB 且全部是匿名页，同时所在 cgroup 已超 memory.high=3G，那么它的实际 badness 很可能远高于一个只占 500MB 但 oom_score_adj = 0 的 Nginx 进程。
确认是否真被 OOM killer 杀掉，而非其他机制
别默认日志里出现 “Killed process” 就是 OOM killer 所为：
- 检查
dmesg -T | grep -i "killed process"输出中是否有Out of memory: Kill process开头的完整行 —— 这才是 OOM killer 日志 - 若只有
Memory cgroup out of memory但无后续 kill 行，可能是 cgroup v2 的memory.oom控制器直接 freeze 进程，而非发送 SIGKILL - 某些容器运行时（如 containerd）或 systemd 服务会拦截 OOM 事件并自行重启/退出，掩盖真实原因
不复杂但容易忽略。
