oom_score_adj写入后未生效的根本原因是cgroup v2已启用而操作仍按v1设计：必须先将进程移入目标cgroup，再写入该cgroup内才有效，否则仅作用于默认root cgroup且不参与OOM决策。
为什么 oom_score_adj 写入后没生效？
直接写 /proc/$PID/oom_score_adj 看似成功，但进程仍被误杀，根本原因常是 cgroup v2 已启用，而你的操作逻辑还按 v1 设计。cgroup v2 下，oom_score_adj 的作用范围被严格限制在 leaf cgroup 内，且仅对该 cgroup 内的 direct children 进程有效；父 cgroup 的设置不继承，更不会影响已存在的、未被显式移动进该 cgroup 的进程。
cgroup v1 和 v2 对 memory.oom_control 和 oom_score_adj 的处理差异
v1 中：memory.oom_control 是开关，配合 oom_score_adj 共同决定是否触发 OOM killer；v2 废弃了 memory.oom_control，改用 memory.low / memory.high / memory.max 分级管控，并把 OOM 判定逻辑下沉到内核 memory controller，oom_score_adj 仅用于同一 cgroup 内多个进程间的相对优先级排序，不再参与“是否该 OOM”的决策。
- v1：可全局调优单个进程的 OOM 抵抗力，靠
oom_score_adj偏移值 - v2：必须先将进程 move 到目标 cgroup（如
/sys/fs/cgroup/memory/myapp/），再写oom_score_adj，否则写入无效或被忽略 - v2 中若 cgroup 设置了
memory.max为有限值，且内存超限，内核会直接 kill 该 cgroup 中任意一个进程（选oom_score_adj最低者），不查全局/proc/*/oom_score_adj
迁移时最常踩的三个坑
从 v1 迁移到 v2，光改路径不够，行为逻辑已变。
- 误以为
echo -1000 > /proc/$PID/oom_score_adj仍能保命 —— v2 下它只在进程所属 cgroup 内起相对作用，无法覆盖 cgroup 级别的内存硬限 - 忘记将进程 move 到目标 cgroup：
echo $PID > /sys/fs/cgroup/memory/myapp/cgroup.procs缺失，导致oom_score_adj写入的是默认 root cgroup，完全不生效 - 混用 v1/v2 挂载点：系统启用了 v2（
mount | grep cgroup显示type cgroup2），但脚本还在读写/sys/fs/cgroup/memory/xxx/下的 v1 接口（如memory.limit_in_bytes），这些文件已不存在或返回ENOENT
验证 oom_score_adj 是否真在起作用
不能只看写入是否成功，要确认进程当前归属的 cgroup 及其 memory 控制策略。
- 查进程所在 cgroup：
cat /proc/$PID/cgroup | grep memory，确认输出类似0::/myapp（v2）而非memory:/myapp（v1） - 查该 cgroup 是否设了
memory.max：cat /sys/fs/cgroup/myapp/memory.max，若为max表示无硬限，若为数值（如512M），OOM 就由它触发，oom_score_adj仅影响 kill 顺序 - 对比同 cgroup 内多进程的
oom_score_adj值：for p in $(cat /sys/fs/cgroup/myapp/cgroup.procs); do echo "$p $(cat /proc/$p/oom_score_adj 2>/dev/null)"; done | sort -k2n，观察排序是否符合预期
真正关键的不是调高某个进程的分数，而是确保它在正确的 cgroup 里、且该 cgroup 的 memory.max 设置合理。否则 oom_score_adj 就像给即将沉船的乘客调换舱位。
