僵尸进程是已终止但父进程未调用wait/waitpid回收的子进程，仅保留pid和退出状态等轻量条目，状态为z；其产生源于父子进程异步协作失效，核心在于父进程未响应sigchld或未执行回收，累积会导致pid耗尽、系统无法创建新进程。

僵尸进程不是在运行的异常程序，而是已经终止、但父进程还没来得及“收尸”的子进程。它不占CPU、不耗内存，只在内核进程表里留一个轻量级条目（PID + 退出状态），状态标记为 Z。问题核心不在“活没活”，而在“该清没清”。

僵尸进程是怎么产生的

根本机制是父子进程间的异步协作失效：

• 子进程调用 exit() 或自然结束时，内核释放其大部分资源，但保留进程控制块（PCB）等待父进程读取退出码
• 内核随即向父进程发送 SIGCHLD 信号，提醒“孩子已退场，请调用 wait() 或 waitpid() 来拿走状态并释放PID”
• 若父进程：未注册 SIGCHLD 处理器、处理器里只调一次 waitpid() 却有多个子进程退出、用了阻塞式 wait() 卡在其他逻辑中、或压根没写回收代码——僵尸就产生了
• 注意：父进程先退出，子进程会变成孤儿进程并被 init（PID=1）接管，init 通常会自动回收；但若子进程在父进程还活着时就退出，而父进程又没处理信号，那僵尸已在父进程名下生成，init 不会插手

看似安静，实则危险

单个僵尸几乎无感，但累积效应会从底层卡死系统：

• PID 资源枯竭：Linux 默认最大 PID 数通常为 32768（可通过 /proc/sys/kernel/pid_max 查看）。僵尸占着 PID 不放，一旦接近上限，fork() 失败，ls、ssh、日志轮转、systemd 定时器全会报 “Resource temporarily unavailable”
• 内核遍历变慢：ps、top、htop 等工具需线性扫描整个进程表。几千个僵尸会让命令明显卡顿，干扰运维判断
• 掩盖父进程缺陷：持续出现僵尸，往往说明父进程存在设计漏洞——比如信号被屏蔽、死锁、循环中漏掉回收逻辑。不解决根源，可能引发更严重的连锁故障

怎么定位和清理僵尸进程

先确认是否存在，再分场景处置：

• 查看方法：ps aux | grep -E 'Z|defunct' 可直接筛选出 Z 状态进程；top 启动后顶部会显示 zombie: N 计数，按 f 添加 STAT 字段、再按 O 按状态排序，Z 进程一目了然
• 常规清理方式：
  • 让父进程主动调用 wait() 或 waitpid() —— 最干净，需修改代码或脚本逻辑
  • 在父进程中捕获 SIGCHLD 并在信号处理函数里调用非阻塞 waitpid(-1, &status, WNOHANG) 循环回收，适合多子进程场景
  • 终止父进程本身：父进程退出后，其遗留的僵尸子进程会被 init 接管并立即回收（前提是父进程已死，而非挂起）
  • 重启相关服务：适用于父进程是守护进程（如 nginx、自研后台服务）的情况，重启可重置进程树，由 init 清理残留僵尸
• 容器环境特别注意：Docker/Kubernetes 中，每个容器有独立 PID 命名空间，且容器内 PID=1 的进程（如应用本身）若未正确处理 SIGCHLD，就无法回收子进程，导致僵尸在容器内堆积。推荐在 Dockerfile 中使用 tini 或 dumb-init 作为 PID1，它们专为转发信号和收割僵尸设计

能不能彻底避免

技术上可以，但依赖开发规范：

• 所有调用 fork() 的父进程，必须配套实现回收逻辑——要么同步 wait()，要么异步处理 SIGCHLD
• 避免简单 fork() 后直接 exec() 却忽略子进程生命周期管理，尤其在 shell 脚本或 C 程序中
• 在容器化部署中，默认启用轻量 init 进程（如 tini），不把信号处理责任甩给业务代码
• 监控告警联动：定期检查 zombie 数量，超过阈值触发告警，避免问题滞后暴露