僵尸进程根源在于父进程未回收子进程退出状态，表现为占用进程表项；常见原因包括忽略sigchld、回收逻辑缺失、多线程回收失败、父进程提前退出及同步等待缺陷。
僵尸进程本身不占用CPU或内存资源，但它会持续占据一个进程表项，并持有退出状态信息，直到父进程调用 wait() 或 waitpid() 回收。因此，根源不在子进程，而在父进程——父进程未正确回收子进程的退出状态。
父进程忽略 SIGCHLD 信号
当子进程终止时，内核会向父进程发送 SIGCHLD 信号，默认处理动作是忽略。若父进程未显式安装信号处理器，也未在主循环中主动轮询子进程状态，就会漏掉回收时机。
- 常见于使用
fork()创建子进程但未配套处理回收逻辑的服务程序 - 信号处理器中仅调用
signal(SIGCHLD, handler)不够，必须在 handler 内调用waitpid(-1, &status, WNOHANG)循环回收，否则可能丢失多个子进程的退出通知 - 注意：
sigaction()比signal()更可靠，可避免信号中断系统调用后未重试的问题
父进程阻塞或长期不调用 wait 类系统调用
有些程序采用同步等待模型，例如在关键路径中直接调用 wait()，但因逻辑错误导致该调用永远不被执行；或使用非阻塞 waitpid() 却未在合适位置反复检查。
- 典型场景：子进程已退出，但父进程因条件判断错误跳过了回收分支
- 多线程环境下，只有创建子进程的线程（或其所在线程组）能成功回收该子进程，其他线程调用
wait()会失败（返回 -1，errno=ECHILD） - 若父进程用
waitpid(pid, &status, 0)等待特定子进程，而该子进程已提前退出且被其他逻辑误回收，后续再等将永久阻塞
父进程提前退出，遗留子进程被 init 收养但未及时回收
若父进程在子进程之前终止，子进程会被 init（PID 1）收养。init 会自动回收其子进程，但这个过程不是即时的——尤其在高负载或 init 实现较简陋的嵌入式系统中，可能出现短暂僵尸态。
- 这不是 bug，而是预期行为，但若频繁发生，说明业务逻辑存在父子生命周期错配
- 可通过
ps aux | grep 'Z'观察僵尸进程的 PPID 是否为 1，确认是否属此情况 - 根本解法是调整进程结构：避免让长生命周期父进程依赖短生命周期子进程；或使用
prctl(PR_SET_CHILD_SUBREAPER, 1)让中间进程充当子收割者
调试与验证方法
定位问题不能只看 ps 输出的 Z 状态，要结合进程关系与代码路径分析。
- 用
ps -eo pid,ppid,stat,comm,args --forest查看进程树，确认僵尸进程的父进程 PID 及其运行状态 - 对疑似父进程做
strace -p $PPID -e trace=wait,waitpid,wait4,sigreturn，观察是否调用回收系统调用及返回值 - 检查父进程源码中所有
fork()调用点，确认每个分支都有对应回收逻辑（包括出错分支和异常跳转路径） - 在 fork 后打印子 PID，在回收处打印回收结果，通过日志交叉比对是否遗漏
