cgroups v2 中通过 memory.max 设置内存硬上限（如 echo 1G > /sys/fs/cgroup/myapp/memory.max），超限时内核阻塞分配；OOM 仅限本 cgroup 内触发，配合 memory.oom.group=1 可批量终止同进程线程。
cgroups v2 中设置内存上限并控制 OOM 行为，核心在于正确配置 memory.max 和 memory.oom.group，同时理解内核如何触发 OOM killer 及其作用范围。
内存硬上限：用 memory.max 严格限制用量
在 cgroups v2 中，memory.max 是唯一生效的硬性内存上限（单位可为 bytes、KB、MB、GB，如 512M）。超出该值时，内核会阻塞新内存分配（即“throttle”），直到内存回落至限额内或被回收。这不同于 v1 的 memory.limit_in_bytes，v2 不再支持 soft limit 或 swap 限额独立控制（swap 统一由 memory.swap.max 管理）。
- 写入示例：
echo 1G > /sys/fs/cgroup/myapp/memory.max - 设为
max表示无限制（等同于不设限） - 设为
0会被拒绝，最小有效值是4096（一页） - 该限制对所有子 cgroup 生效，除非子组显式覆盖
OOM 发生条件与默认行为
当 cgroup 内存使用达到 memory.max，且无法通过 page reclaim（如文件页回收、swap out）快速释放足够内存时，内核会触发 OOM killer。此时它只在该 cgroup 内部选择进程终止——这是 cgroups v2 的关键改进：OOM 隔离按层级进行，不会波及父组或其他兄弟组。
- 被 kill 的进程满足：属于该 cgroup、非 init 进程、非 kernel thread、有可杀标志（
PF_KTHREAD等除外） - 评分依据包括内存占用比例、运行时间、oom_score_adj 值（用户可调）
- 日志可通过
dmesg查看，含 cgroup 路径和被杀进程名
精细化 OOM 控制：启用 memory.oom.group
默认情况下，OOM killer 每次只杀一个进程。若希望更激进地保障整体稳定性，可开启 memory.oom.group（写入 1）：一旦触发 OOM，内核将杀死该 cgroup 下所有同属一个 memory cgroup 的线程组（即同一进程的所有线程），避免残留内存占用者继续拖累。
- 适用场景：容器中运行单体应用（如 Java 服务），多个线程共享堆内存
- 启用后仍遵循 cgroup 边界，不会跨组杀进程
- 注意：若应用依赖多进程协作（如主从进程模型），启用可能破坏逻辑，需结合业务评估
辅助观测与调试手段
仅设限不够，还需监控是否频繁触限或 OOM。关键接口位于 /sys/fs/cgroup/<path>/memory.*</path>：
-
memory.current：当前实际使用量（含 page cache、anon、swap） -
memory.stat：细分统计（pgpgin/pgpgout、pgmajfault、workingset_refault等） -
memory.events：记录关键事件次数（low、high、max、oom、oom_kill） -
memory.pressure：提供轻量级压力信号（low/medium/critical），适合 Prometheus 抓取
建议在部署时定期采集 memory.events 中的 oom_kill 计数，作为容量预警指标。
