僵尸进程是已终止但父进程未调用wait回收的子进程，仅保留task_struct元数据，处于z状态；根本原因是父进程“活着但失职”，kill -9无效，须父进程主动回收或改用sigchld忽略、信号处理、双fork等预防机制。
僵尸进程（Zombie Process）本质是已终止但尚未被父进程回收的子进程。它不占CPU、不执行代码，只在进程表中保留一个极小的结构体（task_struct），含PID、退出码、运行时间等元数据——关键点在于：只要父进程没调用 wait() 或 waitpid() 读取并释放这些信息，它就一直卡在 Z 状态。
根本原因：父进程没“收尸”
子进程调用 exit() 后会向父进程发送 SIGCHLD 信号，并进入僵死等待态；父进程必须主动调用 wait 类系统调用，才能让内核清理该条目。若父进程完全忽略、阻塞未处理、或 handler 中漏掉 wait 调用，僵尸就持续存在。
- 常见疏忽：C/Python 等语言中 fork 后忘记加 wait，或只在特定分支里调用
- 阻塞型父进程：长期忙于计算、sleep、或阻塞 I/O，无轮询机制检查子进程状态
- SIGCHLD handler 不完整：注册了信号处理函数，但里面没调 wait，或调用后未检查返回值（如被中断导致 EINTR）
特殊场景：父进程提前退出
如果父进程在子进程之前终止，子进程会变成孤儿进程，随后被 init（PID 1）接管。init 会自动 wait 所有子进程，因此这类孤儿进程通常不会滞留为僵尸——除非 init 自身异常（极罕见）。
- 注意：这不是僵尸的主因，而是常被误认为诱因的情况
- 真正风险在于父进程“活着但失职”，而非“死了不管”
为什么 kill -9 对僵尸无效？
僵尸进程早已脱离调度队列，没有内存上下文、不响应信号、也不再拥有可操作的执行实体。kill 命令依赖进程的 task_struct 中的 signal 结构和状态字段，而僵尸的 state 字段已是 EXIT_ZOMBIE，内核直接跳过信号投递逻辑。你不是杀不死它，而是它早已“不可杀”。
- 唯一有效方式：让父进程调用 wait；若父进程已崩溃或设计缺陷，只能重启父进程或整个服务
- 极端情况下，若父进程 PID 无法获取或拒绝响应，系统级干预（如 systemd 重启服务单元）更可靠
如何预防僵尸产生
核心思路是确保子进程退出后，总有机制触发资源回收。有几种成熟实践：
- 显式 wait：fork 后在合适位置同步调用 waitpid(-1, &status, WNOHANG)，避免阻塞
- 忽略 SIGCHLD：signal(SIGCHLD, SIG_IGN)，内核会自动回收子进程，适用于不关心子进程退出细节的场景
- 异步信号处理：注册 SIGCHLD handler，在其中循环调用 waitpid(..., WNOHANG) 直到无子进程可收
- 双 fork 技巧：父进程 fork 子进程，子进程再 fork 孙进程后立即 exit；孙进程成为孤儿，由 init 收割——适合守护进程场景
