compose多服务长周期运行后cgroup资源残留引发软死锁，本质是内核未释放cgroup导致“假活”：容器状态为running但cpu节流、内存oom、进程d状态卡顿；需通过inspect、oom_control、cpu.stat等定位残留，手动清理cgroup路径并重启相关服务，预防需用down --remove-orphans、显式资源限制及升级cgroupv2。
Compose多服务长周期运行后出现Cgroup资源残留引发的软死锁，本质是内核级资源未被彻底释放导致的“假活”状态——容器进程看似正常，但CPU或内存受限严重，响应迟滞、日志写入卡顿、健康检查失败，甚至触发OOMKilled却状态仍显示running。这不是应用代码问题，而是Docker Compose在频繁启停、异常中断或配置不当场景下，对cgroup子系统清理不完整所致。
确认是否为Cgroup残留引发的软死锁
先排除网络、磁盘、应用层故障，聚焦内核资源层面：
- 执行
docker inspect <container-id> | grep -A 5 "CgroupParent\|Memory\|Cpu"</container-id>，查看cgroup路径是否指向已销毁的旧命名空间（如/docker/abc123.../但宿主机/sys/fs/cgroup/下该目录已不存在） - 检查对应cgroup内存控制器状态：
cat /sys/fs/cgroup/memory/docker/<short-id>*/memory.oom_control</short-id>，若under_oom: 1且oom_kill_disable: 0，说明内存已被内核标记为OOM但主进程尚未退出 - 查CPU节流：
cat /sys/fs/cgroup/cpu/docker/<short-id>*/cpu.stat | grep throttled</short-id>，若throttled_time持续增长（尤其>10s/min），表明CPU配额长期耗尽，进程被反复冻结又唤醒 - 运行
ps auxf | grep -A 5 -B 5 "D "，查找处于不可中断睡眠（D状态）的进程，常见于等待cgroup资源释放的内核线程
清理残留cgroup路径与强制回收
Linux内核不会自动回收被遗弃的cgroup路径，需手动干预：
- 定位残留路径：
find /sys/fs/cgroup -path "*/docker/*" -maxdepth 2 -type d -name "*$(echo $CONTAINER_ID | cut -c1-12)*" 2>/dev/null - 尝试安全卸载：
for p in $(find /sys/fs/cgroup -path "*/docker/*$(echo $CONTAINER_ID | cut -c1-12)*" -type d); do rmdir "$p" 2>/dev/null || echo "busy: $p"; done - 若提示
Device or resource busy，说明仍有内核对象引用：用lsof +D /sys/fs/cgroup/或cat /proc/*/cgroup | grep docker找出残留进程PID，再kill -9 $PID（谨慎操作，优先选非主进程） - 重启
systemd-cgmanager（如有）或临时重载cgroup子系统：sudo systemctl restart systemd-cgroups-agent（仅限支持该服务的发行版）
预防性配置：让Compose启动时避免残留
从源头减少cgroup泄漏概率，关键在启动方式与配置收敛：
- 统一使用
docker compose down --remove-orphans --volumes替代简单down，确保网络、卷、cgroup关联项一并清理 - 在
docker-compose.yml中显式声明资源限制，避免默认无限继承宿主机cgroup：deploy: { resources: { limits: { memory: 512M, cpus: '1.0' } } } - 禁用
dockerd的--cgroup-parent全局设置，改由Compose按服务粒度控制，防止跨服务cgroup污染 - 对长期运行服务，启用
restart: unless-stopped并配合healthcheck，减少人工up/down频次
替代方案：绕过cgroup依赖的轻量级编排
若业务允许且软死锁高频发生，可考虑降级编排层级：
- 将核心服务拆出Compose，改用
systemd单元管理（每个服务一个.service文件），直接绑定cgroup v2路径，生命周期更可控 - 对日志、监控等辅助服务，改用
docker run --rm一次性容器，避免持久化cgroup占用 - 升级至Docker Engine 24.0+并启用
cgroupv2=unified启动参数，其资源回收比v1更健壮，Compose v2.20+对此支持更完善
