僵尸进程不占cpu和内存但占用pid，需通过父进程正确处理sigchld并调用waitpid()预防；应监控僵尸数量、检查父进程状态，并在容器/systemd中适配init行为。
僵尸进程不会占用CPU或内存，但会持续占据进程表项，长期积累可能耗尽PID资源，导致新进程无法创建。真正需要关注的不是“清理僵尸”，而是阻止其产生——关键在于父进程正确处理子进程退出信号。
理解僵尸进程的成因
当子进程结束，内核保留其退出状态，等待父进程调用wait()或waitpid()读取。若父进程未处理，该子进程就变成僵尸（状态为Z）。常见场景包括：服务程序未注册SIGCHLD信号处理器、fork后忘记wait、使用了双fork但忽略了中间进程回收。
编写健壮的子进程管理逻辑
在服务主循环中，应主动、非阻塞地回收已终止子进程：
- 注册SIGCHLD信号处理器，内部调用waitpid(-1, &status, WNOHANG)，避免阻塞主流程
- 若使用多线程，注意SIGCHLD只由一个线程接收，建议在主线程统一处理
- 对每个fork()调用，确保有对应waitpid()路径；若子进程交由其他模块管理，需明确责任边界
- 避免简单忽略SIGCHLD（如signal(SIGCHLD, SIG_IGN)），虽可自动回收，但丢失退出状态，不利于错误诊断
监控与兜底机制设计
即使逻辑完备，仍需防御性监控：
- 定期扫描ps aux | awk '$8 ~ /^Z$/ {print $2,$11}'，记录僵尸进程的PID和命令名
- 检查其父进程是否仍在运行（ps -o ppid= -p $ZOMBIE_PID），若父进程已退出，该僵尸将被init（PID 1）收养并自动清理；若父进程存在却长期不回收，说明存在bug
- 可设置阈值告警（如连续5分钟存在≥3个僵尸），触发人工介入或服务重启
- 不推荐用kill -9尝试“杀死”僵尸——它早已终止，kill无效且可能误杀父进程
容器与systemd环境下的特殊考量
在现代部署环境中，需适配运行时特性：
- Docker默认以/sbin/init为PID 1，若应用作为PID 1运行，必须自行处理SIGCHLD；否则建议使用tini等init容器作为入口
- systemd服务可通过RestartPreventExitStatus=配合StartLimitIntervalSec限制崩溃重启频率，避免反复fork失败累积僵尸
- 启用Delegate=yes并配置TasksMax，防止PID耗尽前无提示
