必须结合cgroup v2的层级建模、权重策略、线程粒度控制和内存分级防护，构建“有优先级、有边界、有缓冲、可追溯”的隔离体系：按业务域划分slice、用cpu.weight+cpu.max实现弹性硬限、设memory.low/memory.high三级水位、通过cgroup.threads精确管控线程。
要实现多容器并发下的计算强隔离，不能只靠基础配额限制，必须结合 cgroup v2 的层级建模、权重策略、线程粒度控制和资源保护机制，构建“有优先级、有边界、有缓冲、可追溯”的隔离体系。
构建分层资源树，明确租户/服务边界
cgroup v2 的统一单树结构是强隔离的前提。避免让所有容器平铺在 /sys/fs/cgroup/docker/ 下——这会导致控制器争抢无序、OOM 杀伤范围不可控。
- 按业务域划分 slice：例如创建
/sys/fs/cgroup/app.slice（核心服务）、/sys/fs/cgroup/batch.slice（离线任务）、/sys/fs/cgroup/monitor.slice（可观测组件） - 在每个 slice 下启用所需控制器：
echo "+cpu +memory +io" > app.slice/cgroup.subtree_control - 容器启动时指定 slice：
docker run --slice=app.slice ...或通过 systemd 模板绑定到对应 unit
这样，CPU 调度、内存回收、IO 延迟都天然按 slice 分组隔离，即使 batch.slice 突发打满 CPU，app.slice 仍能保障基线吞吐。
用 cpu.weight + cpu.max 实现“弹性硬限”
纯权重（cpu.weight）在空闲时无效，纯硬限（cpu.max）又易导致利用率低下。二者组合才是强隔离的关键：
- 对关键服务容器设高权重（如
echo 4000 > app.slice/api-1/cpu.weight），确保争抢时优先获得调度器时间片 - 同时设合理硬限（如
echo "100000 60000" > app.slice/api-1/cpu.max），即每 100ms 最多运行 60ms，防止单请求长期霸占 CPU - 对批处理容器设低权重（
echo 500）+ 宽松硬限（"100000 90000"），既不干扰主线程，又允许其在空闲时充分使用资源
这种“软优先 + 硬兜底”策略，在 LLM 推理等延迟敏感场景中可降低 P99 延迟抖动达 40% 以上。
启用 memory.low 和 memory.high，实现内存分级防护
仅靠 memory.max（硬上限）会直接触发 OOM kill；而 memory.high（软限）配合 memory.low（保护阈值），才能实现真正可控的内存隔离：
-
echo "2G" > app.slice/api-1/memory.high：达到该值后内核开始积极回收其页面，但不杀进程 -
echo "512M" > app.slice/api-1/memory.low：保证至少 512MB 内存不被其他 cgroup 回收，用于缓存或热数据驻留 -
echo "3G" > app.slice/api-1/memory.max：作为最后防线，超限则 OOM
这种三级水位机制，使 Redis 类缓存容器在混部环境下内存命中率稳定在 92%+，且几乎不触发 OOM。
利用 cgroup.threads 精确绑定线程，防止逃逸与干扰
传统 cgroup.procs 只写入线程组 leader PID，子线程可能脱离控制。cgroup v2 的 cgroup.threads 支持逐线程管理：
- 启动后立即写入所有关键线程 ID：
echo $TID > app.slice/api-1/cgroup.threads - 对实时推理容器，禁用非必要线程迁移：
echo "+cpuset" > app.slice/api-1/cgroup.subtree_control，再配置cpuset.cpus绑定专属 CPU 核心 - 监控线程逃逸：
cat app.slice/api-1/cgroup.threads | wc -l应与预期线程数一致；若持续减少，说明有 fork 后未重入 cgroup 的子线程
这对 NUMA 敏感型负载（如 GPU 推理）尤为重要——线程与内存节点绑定错误，会导致跨 NUMA 访存延迟飙升 3–5 倍。
