使用 --init 参数启用 tini 作为 PID 1，可正确回收僵尸进程、转发信号；需配合 exec 启动方式、SIGTERM 优雅关闭、资源限制及兼容 init 的基础镜像。
解决Docker镜像内因进程管理不当引发的容器僵死与资源占用，核心在于让容器具备可靠的进程生命周期管理能力——尤其要确保 PID 1 进程能正确响应信号、回收子进程、避免僵尸堆积。
用 --init 启动容器，启用轻量级 init 系统
默认情况下，Docker 容器没有真正的 init 进程，主应用直接作为 PID 1 运行。一旦它不处理 SIGCHLD 或忽略子进程退出，就会产生僵尸进程；也不响应 SIGTERM，导致 docker stop 失效。
添加 --init 参数可自动注入 tini（一个专为容器设计的 init 系统），它会：
- 作为真正的 PID 1，持续调用 waitpid() 清理所有僵尸子进程
- 将接收到的信号（如 SIGTERM）正确转发给主应用进程
- 避免因子进程泄漏耗尽宿主机 pid 数量（尤其在长期运行或高并发 fork 场景下）
使用方式示例：
docker run --init -d --name myapp nginx
确保应用自身适配容器环境
即使用了 --init，若应用启动方式不规范，仍可能绕过信号传递或阻塞退出流程。
- 避免使用
sh -c "myapp &"启动，这会让 shell 成为 PID 1，而 myapp 变成后台子进程，无法接收信号 - 推荐用 exec 形式启动：在 Dockerfile 中写
ENTRYPOINT ["exec", "myapp", "--flag"]或脚本末尾用exec "$@" - 检查应用是否捕获 SIGTERM 并执行优雅关闭逻辑（如关闭连接池、刷写缓冲区）
限制并监控关键资源，防止隐性卡死
进程管理问题常与资源失控交织。例如内存超限触发 OOM Killer，强制 kill 进程后未清理状态，造成“假运行真僵死”。
- 始终设置
--memory和--memory-swap，避免容器吃光宿主机内存 - 对高并发服务，额外限制
--pids-limit（如--pids-limit 256），防止单容器耗尽 pid 资源 - 用
docker stats持续观察实时 CPU/内存/IO，结合docker top查看内部进程树，识别异常长时休眠或零 CPU 占用进程
构建阶段就规避风险：选用带 init 的基础镜像
部分基础镜像（如 phusion/baseimage 或官方支持 --init 的 alpine/nginx 镜像）已内置 tini 或兼容 init 行为。
- 在 Dockerfile 开头指定
FROM phusion/baseimage:latest，再通过RUN /sbin/my_init启用完整 init 功能 - 或直接使用支持 init 的发行版镜像，如 Ubuntu 22.04+ 官方镜像已默认兼容 tini 行为
- 避免基于极简 scratch 或无 shell 的镜像自行拼凑进程管理逻辑，容易遗漏信号处理和僵尸回收
