Linux中可通过Cgroups v1/v2对多线程应用实施内存硬限制，需将整个进程（含所有线程）统一纳入同一cgroup并配置memory.limit_in_bytes（v1）或memory.max（v2），同时禁用swap以确保真正硬限。
Linux 中可以通过 Cgroups v1 或 v2 对多线程应用实施内存硬限制，关键在于将整个进程（含所有线程）统一纳入同一个 cgroup，并启用 memory controller 的硬限机制（如 memory.limit_in_bytes 或 memory.max），而非依赖单个线程的资源控制——因为线程共享进程地址空间，内核按进程粒度统计内存用量。
确保线程归属同一 cgroup
多线程程序的所有线程默认继承主线程所属 cgroup。但若程序在运行中通过 clone() 或 pthread_create() 创建新线程后，又主动调用 setpgid()、unshare(CLONE_NEWPID) 或手动写入其他 cgroup 路径，可能导致线程脱离原组。稳妥做法是：
- 启动前创建好目标 cgroup，并将主进程 PID 写入
cgroup.procs（v2）或tasks（v1）； - 避免在程序中调用
setns()或修改/proc/self/cgroup相关接口； - 验证：运行后检查
/proc/<pid>/cgroup</pid>和所有/proc/<tid>/cgroup</tid>，确认路径一致。
正确配置内存硬限制
Cgroups v1 和 v2 行为略有差异，需注意：
- v1：写入
memory.limit_in_bytes（如512M）即启用硬限；超出时触发 OOM killer 杀死该 cgroup 内任一进程（通常选内存占用最大者）； - v2：写入
memory.max（如512M），同时建议设置memory.swap.max=0关闭交换，才能实现真正硬限；不设 swap 限会导致内存+swap 总量超限才触发 OOM； - 禁用
memory.soft_limit_in_bytes（v1）或memory.low（v2）干扰判断，它们只影响内存回收优先级，不构成硬边界。
验证限制是否生效
仅看配置文件不等于生效，需实测确认：
- 用
stress-ng --vm 1 --vm-bytes 1G --timeout 30s启动内存压测，观察是否在达到限额时被杀（dmesg | tail查 OOM 日志）； - 监控实时用量：
cat /sys/fs/cgroup/myapp/memory.current（v2）或memory.usage_in_bytes（v1）； - 检查是否因未启用 controller 导致无效：v1 确认挂载时含
memory，v2 确认mount | grep cgroup2且/sys/fs/cgroup/cgroup.controllers中memory处于 enabled 状态。
注意事项与常见陷阱
多线程场景下容易忽略的细节：
- 动态链接库或子进程（如 fork/exec）可能继承 cgroup，也可能因 setuid/setgid 重置，需统一管控；
- JVM、Go 等运行时有自身内存管理（堆外内存、mmap 区域），必须确保其分配行为受 cgroup 约束（如 JVM 加
-XX:+UseCGroupMemoryLimitForHeap）； - 内核 4.6+ 默认启用
memory.pressure，可用于提前预警，但不能替代硬限； - 容器环境（如 Docker）已封装 cgroup 配置，直接使用
--memory=512m即可，无需手动操作底层接口。
