写后台服务的人，十有八九都碰过“僵尸进程”这个词。你起了一个守护进程，过一会儿发现系统里多了一堆<defunct>状态的子进程，ps 里一片 Z，杀又杀不掉，重启又怕影响正在跑的任务。当时第一反应可能是“这程序有 bug，子进程没退出”，但查了一圈发现，子进程确实执行完 return 了，问题出在父进程根本没去收尸。要想彻底弄清楚这一整套逻辑，就得把 Linux 进程的完整生命周期掰开看：进程描述符长什么样、fork 时内核做了什么、exit 之后进程为什么还残留、wait 族函数到底负责什么。这篇文章就围绕进程描述符、进程的产生、消亡和释放这三件事，把内核里从 fork 到 exit 再到 wait 的整条链路讲清楚。
先说明一下阅读门槛：这篇文章主要以 Linux 5.x 内核的行为为准，会贴一些源码路径和函数名称，但不会逐行展开内核源码，重点放在“为什么这么设计”和“写代码时应该怎么应对”。适合正在学系统编程、或者做后台服务时被僵尸进程坑过的读者。
1. task_struct：内核给每个进程建的“档案柜”
1.1 为什么内核需要一个进程描述符
“进程”这个概念，说白了就是“运行中的程序的一个实例”。但问题是，内核要管理的实例可能有好几百个，每个实例有自己独立的地址空间、打开的文件、信号状态、当前工作目录、进程 ID……如果内核没有一个统一的数据结构来登记这些东西，调度器根本不知道该调度谁，内存管理也不知道该回收谁的地盘。
这个统一的数据结构就是进程描述符，在 Linux 内核里它的具体实现叫task_struct，定义在include/linux/sched.h。你可以把它理解成每个人在派出所登记的那份“户籍档案”：不管你是普通的 bash 还是 Nginx 的 worker 进程，内核统统给你建一份task_struct，里面记录你这个进程“是谁、在干什么、能访问什么、欠了什么债”。
从内存分配的角度看，task_struct是内核通过 slab 分配器分配的，而不是普通的用户态堆内存。每个进程自己的内核栈里也藏着和这个结构相关的信息，内核通过current宏来获取当前正在执行的进程对应的task_struct。初学者写内核模块时第一件事就是拿current取当前进程信息，就是这个原因。
1.2 档案里到底登记了什么
task_struct非常大，字段超过一两百个，但可以按职责分成几个大类。记住这些分类，后面理解 fork 和 exit 时就容易得多。
标识类字段是最基本的：pid是进程 ID，tgid是线程组 ID。注意这里有个容易混淆的概念——用户态调用getpid()返回的其实是tgid，而每个线程有自己独立的pid。你再想想 Linux 的线程模型：线程不过是共享地址空间和信号处理方式的“轻量级进程”，内核里每个线程都是独立的task_struct，但它们的tgid相同，所以用户态看起来就是同一个进程的不同线程。
状态和调度字段是调度器干活的基础：state表示进程当前状态（运行、可中断睡眠、不可中断睡眠、停止、僵尸），prio、static_prio这些是优先级，se是 CFS 调度器用的调度实体。内存管理字段则是mm和active_mm，指向进程的地址空间描述符mm_struct——注意线程之间共享同一个mm_struct。
文件系统相关字段同样重要：fs记录了进程的根目录、当前工作目录和 umask，files则是文件描述符表，也就是 fd 0、1、2 背后真正指向的struct file数组。信号相关字段里有signal（线程组共享的信号处理设置）、sighand（信号处理函数的表）、blocked（信号掩码）、pending（挂起信号队列）。身份和限制类字段包含cred（UID、GID 等凭据）和rlimit（资源限制）。最后不能忽略的是进程关系类字段：parent指向父进程的task_struct，children是子进程链表的头，sibling用来把兄弟进程串起来，real_parent则记录了真正的父进程，后面讲孤儿进程收养时这两个字段的区别非常关键。
当你ps -el看到那一堆进程时，内核其实就是遍历这些链表和哈希表，逐个读取task_struct的字段来渲染输出。没有进程描述符，ps命令本身都跑不起来。
1.3 进程不是孤岛：链表的联通逻辑
单个task_struct只是一个档案夹，但内核还要解决“怎么快速找到进程”的问题。一个最朴素的需求是：给我一个 PID，我要找到对应的task_struct。内核的做法是维护一个 pid 哈希表，按pid计算出哈希值直接查表；同时，所有进程的task_struct还挂在一个双向循环链表上，内核遍历进程时只要从链表头一路 next 就行，ps遍历进程靠的就是这个。
父子关系也不是一棵严格的树，而是通过children和sibling组成的“孩子链表”结构。举个例子：进程 A fork 出了 B 和 C，那么 B 和 C 各自的parent都指向 A，同时 B 和 C 通过sibling串成兄弟链表，挂在 A 的children头下面。一旦 A 退出，内核要处理 B、C 时，就会沿着 A 的children链表依次“重新认爹”。
理解了这一点，你再看“进程描述符是进程生命周期的基础设施”这句话就容易了：从 fork 创建描述符，到 exit 保留部分描述符，再到 wait 最终释放描述符，整条链路都是围绕这一个对象在做文章。
2. fork背后的生产流水线：从用户态调用到内核copy_process
2.1 一次调用两次返回的魔法
进程产生的唯一入口是fork家族的系统调用。用户态写fork()一次，内核返回两次，一次回到父进程（返回值是子进程 PID），一次回到子进程（返回值是 0）。很多初学者想不通一个函数怎么可能有两个返回值，其实根本不是函数有魔法，而是 fork 复制了一份调用现场，两个执行流各自从 fork 返回。这么说吧：父进程运行到 fork 这条指令时，调用栈、寄存器现场都完整存在，内核在copy_process里把父进程的寄存器快照复制给了子进程，子进程从调度器切入 CPU 时，恢复的就是那个寄存器快照，于是顺着原来的调用链继续“返回”。
这就是为什么 fork 之后父进程和子进程的代码是同一份、但走的分支可能完全不同——靠返回值判断自己是父还是子，是 fork 编程铁律。
2.2 写时拷贝：所谓的“复制”其实是个谎言
教科书上常说“fork 创建子进程时复制父进程的地址空间”，如果 Linux 真的这样实现，每次 fork 都要把几百 MB 的进程内存整体拷贝一遍，性能会惨不忍睹。Linux 的做法是写时拷贝（Copy-On-Write，COW）。
原理一句话总结：fork 时不复制物理内存页，只复制页表，并且把父子进程共享的那些可写页标记为只读。无论父进程还是子进程，谁先尝试写这些页，就会触发缺页异常，内核才会真正分配新的物理页并把内容拷贝过去，然后恢复该页的写权限。没写到的页，大家一直共享同一块物理内存。
这个设计对 fork 的语义产生了深远影响。传统的 fork 语义本来是“完全独立”，但 COW 让父子进程在 fork 后的极短时间内大量共享物理页，只有写操作才逐步拆开。所以很多文章强调“fork 很快”，其实快在了这里。但是你也别以为 COW 永远零成本：如果 fork 之后子进程马上做大量写操作，缺页异常会频繁触发，性能反而不如直接复制。
也正因为 COW，父进程和子进程中那些 fork 之前就已存在的全局变量、堆内存、栈上的数据，初始内容完全相同；fork 之后各自对内存的修改互不可见。基于这个理解，你可以预测一段代码的输出：fork 后父进程把变量 a 改成 100，子进程看到的 a 仍然是 fork 时刻的值。
2.3 fork、vfork、clone：三兄弟的分工
系统编程里还有两个和 fork 沾亲带故的接口：vfork和clone。很多人把它们混为一谈，实际用途差远了。我整理了一个对比表：
| 接口 | 地址空间处理 | 父进程行为 | 典型用途 |
|---|---|---|---|
| fork | 复制页表，COW 按需分离 | 父进程继续运行，与子进程并行 | 创建独立进程 |
| vfork | 子进程共享父进程地址空间，不拷贝页表 | 父进程阻塞直到子进程 exec 或 exit | 早期 fork 太贵的优化手段，现已少用 |
| clone | 通过 flags 精确控制共享哪些资源（内存、文件表、信号等） | 取决于 flags，可按需阻塞 | 创建线程，或创建带有特定隔离的进程 |
vfork的语义非常特殊：子进程和父进程完全共享地址空间，而且父进程会被阻塞，直到子进程调用exec系列函数或_exit。这就是为什么vfork的子进程里绝对不能 return——因为子进程一旦污染了共享栈，父进程恢复执行时会出各种诡异问题。现代内核里vfork基本上是一个兼容性接口，正常情况下你应该用fork或clone。
clone则是 Linux 创建线程的真正入口。glibc 的pthread_create最终就是调用clone，传入CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD等标志，告诉内核“我要和创建者共享地址空间、文件系统信息、文件描述符表、信号处理函数，并且加入同一个线程组”。所以在内核看来，线程和进程没有本质区别，都是一份task_struct。
2.4 从用户态到 copy_process 的内部旅程
用户态调用fork()时，glibc 会封装它进入内核。现在的内核里，fork、vfork、clone最终都汇聚到kernel_clone函数，主流程大致如下：
- 在内核栈上复制一份 pt_regs（用户态的寄存器现场）；
- 调用
copy_process创建新的task_struct并初始化； - 初始化子进程的内核栈、调度实体、内存描述符等；
- 决定子进程先运行还是父进程先运行（通过
fork的标志位控制，比如CLONE_VFORK会让父进程等待）； - 唤醒新进程，准备返回。
copy_process是一个超长函数，里面做了一连串的 copy 操作：copy_mm（创建或共享地址空间描述符）、copy_files（复制或共享文件描述符表）、copy_sighand（复制或共享信号处理表）、copy_signal、copy_fs、copy_creds等等。每种复制都有一个“共享或复制”开关，开关就是clone传入的 flags。看到没有，整个 fork 的核心哲学是：能用指针共享就共享，必须隔离才复制；真正的物理内存又用 COW 推迟到写时再分离。
进程描述符本身在这一步也会被复制，而且task_struct里面那些队列成员（tasks、children、sibling）会重新初始化并挂接进全局链表。从这一刻起，系统里多了一条鲜活的生命，PID 也已经分配好了。
3. 进程退出不等于马上消失：僵尸进程是怎么来的
3.1 exit、_exit、exit_group 的区别
C 程序里最常见的退出方式是调用return，而return最终会触发exit或exit_group。这两个名字看着像一家人，行为还真不一样：
_exit()是系统调用级退出，直接进内核执行退出流程；exit()是 glibc 封装，会先执行atexit注册的钩子函数、刷新 stdio 缓冲区，最后调用exit_group；exit_group才是线程组退出的系统调用，它会让整个线程组的所有线程一起退出。
写多线程程序时，任何一个线程调用了exit()，整个进程都会死掉，这是exit_group的语义导致的。如果只想让当前线程结束而不影响其他线程，应该用pthread_exit，它会触发 pthread 库的清理流程，而不是直接系统调用退出。
还有个容易被忽略的细节：子进程如果用return从main返回，glibc 的启动代码也会帮你调用exit，所以最终都会落到exit_group上。
3.2 do_exit：进入内核后干了什么
用户态的退出最终会在内核里走到do_exit，这是进程消亡的核心函数。它的执行步骤非常清晰：
- 设置
PF_EXITING标志，表示当前进程正在退出； - 处理进程挂起的信号，把不想传递的信号清掉；
- 释放内存管理资源
mm_struct，也就是给进程的地址空间收摊； - 释放文件描述符表、文件系统上下文、信号结构等；
- 向父进程发送
SIGCHLD信号，通知它“你儿子死了”； - 把进程状态设置为
EXIT_ZOMBIE； - 调用
schedule()调度到其他进程，让出 CPU。
注意第 3 步到第 5 步释放的资源主要都是“可以立刻回收”的部分，比如物理内存页、打开的文件、信号队列。但有一个关键对象没释放——task_struct自己。内核故意把描述符留下来，后面细说。
3.3 僵尸进程为什么会存在
进程进入EXIT_ZOMBIE状态之后，它剩下的“尸体”就是一份task_struct，外加几个必要字段。这份描述符之所以要留着，是因为父进程可能随时想调用wait系列函数，来获取子进程的退出状态：到底是正常退出还是被信号杀死？退出码是多少？占用了多少 CPU 时间？
如果没有僵尸状态，子进程一死，这些信息就再也查不到了。所以内核做了一笔交易：子进程可以释放掉绝大多数资源，但必须把自己的“死亡证”挂在进程表里，等父进程验完尸再烧掉。这就是僵尸进程的本质，一个资源占用极少的空壳task_struct。
那为什么系统里动不动就堆出一堆僵尸？因为父进程压根没调用wait。父进程自己活得好好的一直在忙，子进程早就死了，死掉的子进程的task_struct就一直挂着。PID 是有限的资源，僵尸不释放，PID 号就会一直占着，攒多了，新进程 fork 就可能失败。
3.4 亲手制造一个僵尸进程
光看理论不过瘾，我们用一段小代码制造一个僵尸进程，观察它的状态。下面这段程序，父进程 fork 出子进程，子进程立刻退出，父进程故意睡觉 30 秒不调用 wait：
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> int main(void) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid == 0) { printf("child pid=%d exiting now\n", getpid()); exit(0); } printf("parent pid=%d, child pid=%d, sleeping...\n", getpid(), pid); sleep(30); wait(NULL); printf("child reaped\n"); return 0; }编译运行后，另开一个终端执行：
ps -el | grep defunct用ps -l看 STAT 列，你会看到那个子进程的状态是Z，COMMAND 显示<defunct>，僵尸进程就这样现出原形了。等到父进程睡满 30 秒，wait(NULL)执行完，僵尸消失，一切恢复平静。
这段代码的价值在于，它直观地证明了“僵尸不是子进程没退出，而是父进程没回收”。看到Z状态的第一反应不该是去杀子进程——它是杀不掉的，状态已经是 EXIT_ZOMBIE，任何 SIGKILL 都无效。正确的做法是杀父进程，或者让父进程调用 wait。
4. 真正还债的时刻：wait族函数与SIGCHLD回收实战
4.1 wait、waitpid、waitid：三件回收工具
内核负责保留尸体，但最终释放task_struct的工作叫release_task，它必须由父进程通过某种 wait 调用触发。Linux 提供的三件套是wait、waitpid、waitid，底层统一走wait4或waitid系统调用。它们都有一个共同特点：如果调用时子进程还没死，调用方默认会阻塞（除非指定了WNOHANG），直到有子进程退出才返回。
| 函数 | 可指定特定子进程 | 可非阻塞 | 获取详细退出信息 |
|---|---|---|---|
| wait | 否，任意子进程 | 否 | 基础退出码 |
| waitpid | 是，按 PID 精确回收 | 是（WNOHANG） | 基础退出码 |
| waitid | 是，更灵活 | 是 | 详细事件信息 |
waitpid的常见用法是回收所有子进程，用waitpid(-1, &status, 0)等价于wait(&status)；加WNOHANG后变成非阻塞探测，有僵尸就收，没有就立刻返回 0。
退出状态status是一个 int，不能直接看数值，要用宏解析：
#include <stdio.h> #include <stdlib.h> #include <sys/wait.h> #include <unistd.h> int main(void) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid == 0) { exit(42); } int status; pid_t r = waitpid(pid, &status, 0); if (r == pid) { if (WIFEXITED(status)) { printf("child exited with code %d\n", WEXITSTATUS(status)); } if (WIFSIGNALED(status)) { printf("child killed by signal %d\n", WTERMSIG(status)); } } return 0; }WIFEXITED判断是否正常退出，WEXITSTATUS拿退出码；WIFSIGNALED判断是否被信号杀死，WTERMSIG拿信号编号。这套宏是面试和日常工作都躲不开的基础。
4.2 异步回收：SIGCHLD 的正确打开方式
很多后台服务不可能专门在业务循环里插入waitpid，更常见的做法是注册SIGCHLD信号处理器。子进程退出时内核会给父进程发SIGCHLD，处理器里趁热打铁把僵尸全部收掉。这里有一个常见错误：处理器里只调用一次waitpid。如果同一时刻有多个子进程退出，而信号只递达一次，就会漏收。正确做法是循环回收，直到waitpid(-1, &status, WNOHANG)返回 0 或 -1：
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> #include <sys/wait.h> static void on_sigchld(int sig) { int status; pid_t pid; while ((pid = waitpid(-1, &status, WNOHANG)) > 0) { // 全局计数器在这里加一，或者记录退出信息 } } int main(void) { struct sigaction sa; sa.sa_handler = on_sigchld; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART | SA_NOCLDSTOP; sigaction(SIGCHLD, &sa, NULL); pid_t pid = fork(); if (pid == 0) { sleep(1); exit(0); } for (;;) pause(); return 0; }SA_NOCLDSTOP是必须加的，否则子进程被暂停（比如 Ctrl-Z 调试）也会触发 SIGCHLD，到时候你在处理器里一查，子进程还活着，白白空转。另外注意，printf在信号处理器里其实不是异步信号安全的，真正的生产代码应该用write记录日志或者只设置标志位，在主循环里处理。上面的示例只是为了演示结构，放生产环境前请改成write。
4.3 双 fork 与守护进程解耦
系统编程里还有个经典技巧叫“双 fork”。一个进程 fork 出子进程、子进程再 fork 出孙进程，然后父进程和第一个子进程都立刻退出。这样孙进程的父进程变成了 1 号进程（或当前 PID namespace 里的 subreaper），孙进程彻底脱离和原终端的联系，成为真正的后台进程。很多守护进程启动时，就是用这套逻辑把自身和终端会话分离。
写这段逻辑时要特别注意：中间那个子进程退出后也会变僵尸，父进程需要 wait 它一次，所以第一个 fork 之后父进程要wait(NULL)等中间子进程死掉；中间子进程在 fork 孙进程后自己exit(0)，孙进程由 1 号进程收养，后续孙进程退出时，1 号进程会回收它，不劳你操心。
4.4 常见踩坑：僵尸批量堆积
我见过一次真实的事故，挺典型。服务端收到客户端连接后，主进程 fork 子进程去处理业务，子进程跑完就退出，但父进程每次只处理最多一个子进程的回收，而且回收点在某些错误路径上被提前 return，导致大部分僵尸没人管。几万个僵尸攒下来，进程表爆了，新的 fork 直接返回 EAGAIN。
排查方法也简单：先ps -el看 Z 状态数量，再top -H看进程数是不是接近 pid_max。但根因不是“进程太多”，而是“wait 调用没覆盖所有退出路径”。所以我的实践原则是，凡是 fork 了子进程的代码，要么每个子进程退出时都有配套的同步 wait，要么注册一个健壮的 SIGCHLD 处理器，用 while 循环把所有僵尸一次性清干净。宁可在回收上多写几行，也别留死角。
5. 生命周期中的异常与边界：孤儿收养、fork炸弹与信号竞态
5.1 孤儿进程最终被谁收养
父进程比子进程先死，子进程就成了孤儿。孤儿当然不是没人管，内核会在父进程退出时遍历它的children链表，给每个孩子重新指定一个parent。在老版本内核里，这个新父进程通常是 PID 1（init 或 systemd）。引入 PID namespace 和 subreaper 机制之后，情况更细：如果父进程所在线程组里有一个进程设置了成为 subreaper 的资格，那么孤儿会被这个 subreaper 收养，而不是直接上交给 1 号进程。
这个机制保证了一件事：孤儿进程不会一直处于“无父可依”的状态，等到孤儿自己退出时，总有一个进程会接到 SIGCHLD 并负责 wait 回收，避免孤儿变成永久的僵尸。如果你自己写过一个长期运行的服务，并且 fork 出子进程后父进程先退出，而你不想让子进程挂在 1 号进程下，可以考虑设置 subreaper，在应用层接管孙辈进程的回收。Linux 上这个操作通过prctl(PR_SET_CHILD_SUBREAPER, 1)完成。
5.2 fork 炸弹与资源防护
进程产生的另一面是滥用。fork 炸弹的经典形态是进程疯狂 fork 自己，短时间内耗尽进程表。虽然这属于安全话题，但系统编程的人最好知道怎么在代码层面设防：ulimit -u可以限制一个用户的进程数上限，很多生产环境也真的会设这个值。如果 fork 返回EAGAIN，第一个要查的就是/proc/sys/kernel/pid_max和当前用户的 nproc 限制。
另外，写代码时对“无限制 fork”要保持敏感。有些服务会把每个任务都 fork 一个子进程，高峰时瞬间创建几百个进程，再加上子进程退出的回收不及时，系统负载会很难看。一般来说，轻量任务用线程池，重量任务才考虑进程隔离。
5.3 SIGCHLD 的竞态问题
如果既用了 SIGCHLD 处理器，又在主流程里用了waitpid，你可能会遇到一个隐蔽的竞态。SIGCHLD 的递送时机和主流程 waitpid 的调用时机谁先谁后不确定，如果子进程已经退出，主流程waitpid把它收了，稍后内核递送 SIGCHLD，处理器里waitpid(-1, WNOHANG)返回 -1 且 errno 为 ECHILD，表示没有子进程可收。这不是 bug，是正常现象，但新手容易被 ECHILD 吓到，以为系统出问题了。处理器的 while 循环里要把pid == -1 && errno == ECHILD当作正常退出条件。
信号处理还有一个“丢失的唤醒”问题。理论上，如果多个子进程几乎同时退出，内核可能只会给父进程发一个 SIGCHLD，而你的处理器只 wait 一次，漏掉的僵尸就永远留在那了。所以我在 4.2 里强调 while 循环，目的就在这里——不管来了几个信号，一律把当前所有可回收的子进程清空。
5.4 一点个人实践体会
聊点实际经验。我自己写后台服务时，会定一条铁律：所有 fork 的子进程，必须有对应的回收逻辑，要么同步在同一个函数里 wait，要么一进主循环就挂上 SIGCHLD 处理器。代码评审时只要看到 fork 出现，第一句话永远是“回收点在哪”。
调试僵尸进程也有个小套路：不要只盯着 ps 的 STAT 列，可以用cat /proc/<pid>/status看 State 字段，僵尸进程会显示Z (zombie)。/proc文件系统里能看到很多 task_struct 的影子，State、PPid、Uid 都是直接读描述符字段渲染出来的。把/proc/<pid>/status当作 window 到 task_struct 的观察窗，排查问题会快很多。
还有一个习惯，就是写测试代码时故意留一个“忘回收”的 fork 练习，用来观察僵尸产生和 wait 回收的完整过程。这种练习比死记原理印象深多了。我前面那段制造僵尸的代码，建议你都跑一遍，然后尝试在此基础上加 SIGCHLD 处理器，再对比一下 Z 状态的数量变化，整个进程生命周期的逻辑就算彻底打通了。
