僵尸进程不消耗cpu或内存但占用pid和内核表项，超限（默认32768）会导致新进程创建失败；可用top查zombie数、ps aux | grep 'z\|defunct'定位具体僵尸进程。
僵尸进程本身不消耗CPU或内存，但会持续占用PID资源和内核进程表项。当数量积累到系统上限（默认32768），新进程无法创建——此时ls、ssh、docker run等基础命令全部失败，服务看似“活着”，实则已丧失响应能力。
怎么确认是僵尸进程惹的祸
两个命令快速验证：
-
看总数：运行
top，顶部 Tasks 行中若显示zombie: X（X > 0），说明存在僵尸进程 -
找具体进程：执行
ps aux | grep 'Z\|defunct'，输出中STAT列为Z或命令列含<defunct></defunct>的即为僵尸进程
关键要揪出它的父进程
僵尸进程无法被 kill，真正需要干预的是它的父进程。操作分三步：
- 用
ps -o ppid= -p [僵尸PID]获取父进程 PID - 用
ps -p [父PID] -o pid,comm,cmd查看父进程是谁、是否还在运行 - 若父进程是业务主程序（如 node、java、python 脚本），大概率它存在回收逻辑缺陷；若父进程已僵死或异常，僵尸就卡住了
常见诱因与对应解法
不同场景下，成因和处理方式差异明显：
-
Docker 容器内大量僵尸：主进程（PID 1）未实现子进程回收。Node.js 或 Bash 直接作为 PID 1 时不会自动 wait 子进程。推荐使用
tini作为容器 init 进程，或在 Dockerfile 中添加ENTRYPOINT ["tini", "--"] -
Java 应用伴随 tail 日志时出现僵尸：不是 tail 本身的问题，而是启动脚本中误用
ctrl+z挂起而非ctrl+c终止，导致 Java 进程变成后台作业，父 shell 未收到 SIGCHLD 或未正确处理，最终子进程退出后滞留为僵尸 -
Puppeteer 类服务高频生成子进程：Chrome 启动大量渲染子进程，若主进程未监听
SIGCHLD或未调用waitpid(-1, &status, WNOHANG)，极易堆积数千僵尸。需在代码中显式回收，或改用支持自动回收的运行时封装
临时缓解与长期预防
线上紧急情况下可快速止损，但不能替代修复：
- 若父进程可安全重启，直接
kill -9 [父PID]——父进程退出后，僵尸会被 init（PID 1）接管并清理 - 检查
/proc/sys/kernel/pid_max，确认当前 PID 上限；若接近耗尽，可临时调高（需评估影响） - 所有多进程服务，必须确保父进程注册
SIGCHLD信号处理器，并在其中循环调用waitpid()回收已退出子进程
