僵尸进程的根源追踪：锁定代码逻辑缺陷

僵尸进程根源在于父进程未回收子进程退出状态，表现为占用进程表项；常见原因包括忽略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，在回收处打印回收结果，通过日志交叉比对是否遗漏