Linux进程控制：fork、exit与wait/waitpid实战详解

写后台服务、跑批量任务的时候，肯定遇到过这种情况：程序fork出来的子进程退出了，但ps一看还挂着几十个状态为Z的条目，父进程不管它，系统里就飘着一堆僵尸进程。要弄懂这类问题，绕不开Linux进程控制里最基础的三板斧：进程创建、进程终止、进程等待。

这篇就围绕这三个点展开。fork负责创建子进程，exit和_exit负责结束进程，wait和waitpid负责回收子进程资源。这三件事看着简单，真正写起来全是坑：fork之后缓冲区为什么会重复输出？子进程退出了父进程怎么判断它是正常退出还是被信号杀掉的？为什么waitpid在信号处理函数里要加循环？文章里我会把这些机制的原理、代码样例和实际操作中的排查经验一起讲清楚，适合刚接触Linux系统编程的读者，也适合工作中经常跟多进程程序打交道、想补一补底层细节的人。

1. 先把三件事的关系理清楚

1.1 进程控制到底在控制什么

每个进程在内核里都对应一个task_struct结构体，也就是PCB（进程控制块），里面存着pid、父进程pid、进程状态、打开的文件描述符表、信号处理设置、内存映射信息、当前工作目录等等。进程控制做的事情，简单说就是围绕这个PCB做生命周期管理：创建时分配PCB并初始化，运行中维护PCB里的状态，终止时回收PCB占用的所有资源。

创建进程用的是fork，它做的事情是复制当前进程的PCB，生成一份几乎一模一样的副本，再给这个副本分配新的pid、建立新的内存映射。进程终止的入口是exit或者_exit，前者会做一些C库层的收尾工作，后者直接陷入内核态清理资源。进程等待用的是wait或者waitpid，让父进程阻塞起来，等某个子进程终止之后，把它的退出状态取出来，同时回收子进程残留的PCB，这一步是防止僵尸进程的关键。

这里要注意，创建和等待是成对出现的。只创建不等待，子进程终止后它的task_struct不会被释放，慢慢堆积成僵尸进程。只等待不创建，那这个等待大概率就是个bug。所以学习进程控制，最好把创建、终止、等待当成一条流水线来理解，而不是三个孤立的知识点。

1.2 为什么把三件事放在一个体系里学

单独看fork，很容易停留在"创建一个子进程"这个表层理解上，面试问一句"fork之后父子进程共享什么、拷贝什么"就露馅。单独看exit，又会忽略退出码的传递链：子进程exit(3)，父进程怎么拿到这个3？答案在wait返回的状态里。这三个系统调用是一条完整的链路，子进程怎么来的、怎么走的、父进程怎么确认它走了，构成了进程生命周期的主干。

理解了这条主干，后面再学exec系列、信号、进程间通信，会顺畅很多。比如exec是创建完进程后加载新程序，信号里SIGCHLD会打断阻塞的wait，管道通信的另一端其实就是wait回收的子进程。这篇按"创建、终止、等待"的顺序走，每一步都配代码和踩坑记录，最后一节用一个小型多进程任务管理器把整条链路串起来。

2. 进程创建：fork背后的机制

2.1 fork的返回值为什么那么反直觉

fork最反直觉的地方在于：调用一次，返回两次。父进程里fork返回子进程的pid，子进程里fork返回0，失败时返回-1。不是"复制了一个进程然后各自继续跑"这么简单，而是fork返回后，父进程和子进程都从fork调用之后的下一行代码开始执行，只是各自拿到的返回值不同。

为什么设计成返回两次？因为父进程和子进程要做的事情通常不一样。父进程拿到子进程pid，可能要继续创建更多子进程，或者记下这个pid用于后续管理；子进程拿到0，说明自己是子进程，可以去执行另一段逻辑。用返回值作为分支依据，是区分"我是父进程"还是"我是子进程"的唯一内置手段。

fork的底层实现不是把父进程整个内存复制一遍。早期确实做过完全复制，后来改成了写时拷贝（Copy-on-Write，COW）：fork时父子进程共享同一份物理内存页面，页表项都标记为只读。任何一方试图写入某个页面时，才触发缺页异常，内核把这一页单独复制一份再允许写入。这样设计的好处是，fork之后子进程大概率马上调用exec加载新程序，前面复制的数据页根本用不上，COW能省掉大量内存拷贝的开销。

2.2 最小可运行的fork示例

看一段最小代码：

#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("子进程: pid=%d, 父进程=%d\n", getpid(), getppid()); _exit(0); } printf("父进程: pid=%d, 子进程=%d\n", getpid(), pid); wait(NULL); return 0; }

编译运行后，父进程和子进程都会打印一行。子进程用getppid()拿父进程pid，这里拿到的是父进程调用fork时的pid。有个细节：如果父进程先退出了，子进程的getppid()会变成1，因为孤儿进程被pid为1的init进程收养。在bash里直接跑这个程序，父进程一般不会先于子进程退出，但放到更复杂的服务框架里，这个孤儿进程的ppid漂移现象很常见。

fork之后父子进程的执行顺序是不确定的。父进程先打印还是子进程先打印，完全看调度器，不能假设谁先谁后。如果对顺序有要求，需要自己通过管道、信号或者共享内存去同步，光靠fork的语义是保证不了的。

2.3 fork前printf，输出会多出一份

一个很经典的fork面试题：下面这段代码，最后会输出几行？

#include <stdio.h> #include <unistd.h> #include <sys/wait.h> int main(void) { printf("hello "); fflush(stdout); fork(); wait(NULL); return 0; }

如果把fflush(stdout)去掉，输出会变成两行hello，而不是一行。原因是printf写的是标准C库的缓冲区，数据还在用户态缓冲区里没刷到内核，fork复制进程时把这个缓冲区也复制了一份，于是父子进程各持有一份"hello "，等程序正常退出时各自刷新缓冲区，就输出了两遍。

实际开发中这事经常引发诡异现象：日志打到一半，fork之后日志就重复了。规避方法很直接：fork之前确实有未刷新的输出，就显式调用fflush，或者保证fork之后立即exec、不依赖之前的缓冲状态。这个问题放在博客里反复讲，因为它是把fork的"复制"性质暴露得最彻底的一个场景。

2.4 fork失败的常见原因与fork炸弹的教训

fork返回-1，通常有两种原因：一是系统进程数达到上限，可以用ulimit -u查看当前用户的进程数限制；二是内存不足，COW虽然省内存，但创建task_struct、复制页表这些操作仍然需要分配内核内存。

fork还有个极端的反面用例：fork炸弹。不断fork自己，短时间内把系统进程表撑爆，会让整个机器卡死。我自己只在受控的虚拟机里见过一次演示，生产环境千万别尝试。限制用户最大进程数、用systemd或容器限制进程数，都是防止这类情况的常用手段。这个例子放在这里也算提醒：fork是个强大的系统调用，但用之前得想清楚它的代价。

3. 进程终止：exit与_exit的差别

3.1 exit是收尾，_exit是直接走

进程终止的入口有两个：exit(int status)和_exit(int status)。两者最终都会进入内核的do_exit，但exit在前面多做了三件事：

• 执行通过atexit注册的钩子函数
• 刷新并关闭所有标准C库的stdio缓冲区
• 调用底层清理，最终进入内核态

_exit则跳过所有C库层的收尾，直接陷入内核做资源回收。区别集中体现在缓冲区上。看这段代码：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> void bye(void) { printf("bye called\n"); } int main(void) { atexit(bye); printf("data without newline, pid=%d ", getpid()); // exit(0); // 情况1 _exit(0); // 情况2 }

情况1用exit(0)，atexit注册的bye会被调用，printf的缓冲区也会被刷新，所以日志完整输出。情况2用_exit(0)，atexit不执行，缓冲区不刷新，"data without newline"直接丢失。如果你在子进程里用_exit，父进程通过wait拿到的退出状态是一致的，但日志和清理钩子的行为完全不同。

多进程程序里有个常见搭配：fork出来的子进程，建议用_exit而不是exit。原因是子进程通常复制了父进程的缓冲区内容，如果用exit刷新缓冲区，可能导致重复输出；而且exit还会执行父进程注册的atexit钩子，这些钩子可能是为父进程准备的，子进程执行一遍纯属多余。

3.2 退出码到底怎么传递

进程的退出码是一个8位的整数，范围0到255。main函数里return 3和调用exit(3)最终效果一样，都走C运行时的退出流程。退出码的传递依赖wait这类系统调用：子进程退出时，内核把退出状态记录在task_struct里，父进程通过wait回收时，这个状态被提取出来。

重点来了：退出状态不是单纯的一个退出码，而是一个打包的整数。取这个整数时要用一组宏拆解，常用的有：

• WIFEXITED(status)：子进程是否正常退出（通过exit或return）
• WEXITSTATUS(status)：正常退出时，取出退出码（低8位）
• WIFSIGNALED(status)：子进程是否被信号终止
• WTERMSIG(status)：被哪个信号终止
• WIFSTOPPED(status)：子进程是否处于暂停状态
• WSTOPSIG(status)：暂停是由哪个信号触发

这么设计的原因是父进程需要区分"子进程正常结束，退出码是几"和"子进程被信号杀掉，是哪个信号"。如果不拆开，这两类信息混在一个int里，根本没法用。后面讲waitpid时会看到这些宏的实际用法。

3.3 孤儿进程与僵尸进程

进程终止后，父进程如果还没调用wait，那子进程的task_struct会带着退出状态一直留在内核里，进程状态标记为Z（zombie，僵尸）。僵尸进程不占CPU、不占内存数据页，但占着一个pid和一份PCB，一直不回收，进程表就会被慢慢塞满。

和僵尸相对的是孤儿进程：父进程先退出，子进程还没退出。此时子进程会被pid为1的init进程收养，init会在合适的时候主动wait这些孤儿进程，替它们收尸。所以对孤儿进程本身，内核有一整套自动接管机制，不需要开发者操心。真正需要开发者操心的，恰恰是父进程还活着，却不调用wait，任由子进程变成僵尸。

理解这两类进程的关键在于：僵尸是子进程死了但没人收尸，孤儿是父亲走了但孩子还活着。处理僵尸的唯一正解，就是父进程调用wait或waitpid，配合好终止和等待这两步。

4. 进程等待：wait与waitpid

4.1 wait是最省事的等待方式

wait(int *status)的功能是：阻塞当前进程，直到有一个子进程终止。返回终止子进程的pid，同时把退出状态写到status指向的位置。如果调用wait时没有任何子进程，直接返回-1，errno设为ECHILD。

注意"任意一个子进程"。如果父进程创建了4个子进程，调用一次wait只能回收其中最先终止的那个，剩下的3个还需要继续调用wait。这是很多初学的人写多进程程序时容易漏的地方。

status可以传NULL，意思是父进程不关心子进程退出状态，只想收尸。但如果想判断子进程怎么退的，就需要传入一个int变量，后面用宏拆解。简单示例：

#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("子进程退出前的最后日志\n"); exit(42); } int status; pid_t ret = wait(&status); if (ret < 0) { perror("wait"); exit(1); } if (WIFEXITED(status)) { printf("子进程%d正常退出，退出码=%d\n", ret, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("子进程%d被信号%d终止\n", ret, WTERMSIG(status)); } return 0; }

4.2 waitpid解决两个问题

wait有两个明显的痛点：只能阻塞等待、只能等"任意一个"子进程。waitpid就是为了解决这两个问题而存在的。

pid_t waitpid(pid_t pid, int *status, int options);

第三个参数options是重点，它可以取0、WNOHANG、WUNTRACED等值。0表示阻塞等待；WNOHANG表示非阻塞，如果没有子进程退出，立即返回0，父进程可以继续干自己的事。

第一个参数pid的取值规则：

• pid > 0：等指定pid的那个子进程
• pid == -1：等待任意一个子进程，等同于wait
• pid == 0：等所有和调用者同进程组的子进程
• pid < -1：等指定进程组里的子进程

实际开发中最常用的组合是waitpid(-1, &status, WNOHANG)配合循环：非阻塞地轮询，直到所有子进程都退完。这个组合在信号处理函数里尤其常见，后面会单独说明。

4.3 循环回收多个子进程

假设父进程创建了3个子进程，正确回收方式是循环多次调用waitpid：

#define CHILD_NUM 3 for (int i = 0; i < CHILD_NUM; i++) { int status; pid_t ret = waitpid(-1, &status, 0); if (ret < 0) { perror("waitpid"); break; } printf("回收了子进程 %d\n", ret); }

这里用waitpid(-1, &status, 0)，语义和wait(&status)一样，都是阻塞等任意一个子进程。循环次数定为3，是因为我们明确知道创建了3个子进程，每回收一个，循环变量加1，直到全部收完。

如果改用waitpid(pid, &status, 0)绑定具体子进程pid，就得考虑多个子进程退出的先后顺序。比如子进程B先退，父进程却等子进程A，那父进程会阻塞到A退出为止，B的退出状态虽然在内核里，但没人取，B就暂时成了僵尸。所以除非有明确的业务需要，否则回收多个子进程时用-1等任意一个是更省事的选择。

4.4 非阻塞轮询的场景

非阻塞模式适合父进程要边干活边管孩子的情况。比如父进程自己有一个持续运行的事件循环，同时还需要监控几个子进程的状态，这时候就不能阻塞在wait上。可以用：

int status; pid_t ret; while ((ret = waitpid(-1, &status, WNOHANG)) > 0) { printf("回收子进程 %d\n", ret); } // ret == 0 说明当前没有子进程退出 // ret == -1 说明所有子进程都已回收完毕

代码里while退出后，ret为0表示"没有子进程恰好在这轮退出"，不是出错；ret为-1时需要看errno，最常见的错误码是ECHILD，表示没有子进程了。这个区分是很多人容易搞混的点。

4.5 用SIGCHLD配合waitpid实现自动回收

子进程终止时，内核会自动向父进程发送SIGCHLD信号。如果父进程不处理这个信号，默认行为是忽略它，子进程仍然可能变成僵尸。常见做法是注册一个信号处理函数，在里面用非阻塞waitpid循环回收：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> #include <sys/wait.h> static void sigchld_handler(int sig) { int status; pid_t pid; while ((pid = waitpid(-1, &status, WNOHANG)) > 0) { printf("信号处理中回收子进程 %d\n", pid); } } int main(void) { signal(SIGCHLD, sigchld_handler); for (int i = 0; i < 3; i++) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid == 0) { printf("子进程 %d 开始\n", getpid()); _exit(0); } } // 父进程假装继续干活 pause(); return 0; }

关键点在于信号处理函数里必须用循环，不能只调用一次waitpid。因为SIGCHLD信号可能会丢失：多个子进程几乎同时退出，内核可能只给父进程发一次信号，如果处理函数只回收一个子进程，剩下的就没人管了。用while + WNOHANG + waitpid(-1)循环，直到返回0或-1，才能把这一批退出的子进程全部回收干净。

5. 实战：把创建、终止、等待串成一个任务管理器

5.1 场景设定

假设要写一个小型任务调度器：父进程创建4个子进程，每个子进程模拟一个不同耗时的任务（比如压缩、上传、校验、清理）。父进程负责任务下发和结果汇总，等所有子进程结束后统计正常完成数和异常退出数。

这个场景覆盖了进程创建、进程终止、进程等待三块内容：fork创建子进程、子进程exit返回退出码或被信号终止、父进程用waitpid逐个回收并解析状态。

5.2 代码实现

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> #define TASK_COUNT 4 int main(void) { pid_t children[TASK_COUNT]; for (int i = 0; i < TASK_COUNT; i++) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid == 0) { // 子进程：按编号模拟不同任务 printf("任务%d号子进程开始，pid=%d\n", i, getpid()); switch (i) { case 0: sleep(3); break; case 1: sleep(1); break; case 2: sleep(2); break; case 3: sleep(1); break; } if (i == 2) { // 模拟2号任务异常：被信号终止 abort(); } _exit(0); } children[i] = pid; } // 父进程：逐个回收子进程 int ok_count = 0; int fail_count = 0; for (int i = 0; i < TASK_COUNT; i++) { int status; pid_t ret = waitpid(-1, &status, 0); if (ret < 0) { perror("waitpid"); continue; } if (WIFEXITED(status)) { printf("任务子进程pid=%d 正常完成，退出码=%d\n", ret, WEXITSTATUS(status)); ok_count++; } else if (WIFSIGNALED(status)) { printf("任务子进程pid=%d 被信号%d终止\n", ret, WTERMSIG(status)); fail_count++; } } printf("汇总：正常完成 %d 个，异常终止 %d 个\n", ok_count, fail_count); return 0; }

运行后能看到不同任务以不同顺序退出，2号子进程因为abort触发SIGABRT被终止，父进程通过WIFSIGNALED和WTERMSIG识别出来。这个汇总逻辑放到真实系统里，就相当于任务调度系统的"结果回收"模块。

5.3 扩展成非阻塞巡检版本

上面的版本父进程全程阻塞等待，如果父进程还想同时处理自己的业务，可以改成轮询模式：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> #define TASK_COUNT 4 int main(void) { int remaining = TASK_COUNT; for (int i = 0; i < TASK_COUNT; i++) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid == 0) { sleep(1 + i); _exit(i); } } while (remaining > 0) { int status; pid_t ret = waitpid(-1, &status, WNOHANG); if (ret > 0) { if (WIFEXITED(status)) { printf("子进程 %d 完成了，退出码=%d\n", ret, WEXITSTATUS(status)); } remaining--; } else if (ret < 0) { perror("waitpid"); break; } else { // ret == 0: 本轮没有子进程退出，父进程继续忙自己的事 printf("父进程继续处理其他业务...\n"); usleep(500000); } } printf("所有子进程已回收完毕\n"); return 0; }

这种方式适合父进程本身是一个事件循环的场景。注意轮询间隔不能太短，否则白白烧CPU，按业务容忍度，几百毫秒到一秒钟比较常见。

5.4 实战中容易踩的两个问题

第一个问题是回收次数和子进程数不匹配。比如父进程在循环里fork，子进程return出去后，又接着进下一轮循环继续fork，导致子进程数量比预期多很多。解决办法是先想清楚fork之后子进程的流向，子进程分支里一定要_exit或者exec，不能让子进程掉回父进程的执行路径。

第二个问题是子进程退出状态没有及时取。哪怕调用了waitpid，但只调了一次，在多个子进程同时退出的情况下，也会剩下一部分僵尸。用信号处理时更要坚持"循环回收"原则。排查方法很简单：ps -o pid,ppid,stat,cmd，看到一堆Z状态进程，基本就是wait相关代码写漏了。

6. 常见问题与排查技巧实录

6.1 僵尸进程的现场排查

遇到僵尸进程，第一步是确认它的父进程是谁。命令：

ps -o pid,ppid,stat,cmd

STAT列出现Z，就说明该进程是僵尸。再往前找父进程pid，确认父进程是否还活着。如果父进程活着，说明父进程没有正确调用wait回收；如果父进程已经退出了，僵尸进程应该已经被init接管并回收，短时间内不可能一直存在。

实战里还有一种常见情况：父进程是一个长期运行的守护进程，它一边fork子进程处理任务，一边自己跑主循环。如果回收代码写的是一次性waitpid，而不是循环，只要某批子进程同时退出，就会漏掉几个，僵尸慢慢积累。排查时先看进程数目有没有持续上升，再用ps确定僵尸的父进程pid，去查对应代码逻辑。

6.2 常见问题速查表

问题现象	可能原因	解决方法
大量僵尸进程堆积	父进程没有调用wait/waitpid，或信号处理里只回收了一个子进程	用while循环+WNOHANG+waitpid(-1)回收，或检查父进程逻辑
waitpid返回-1且errno=ECHILD	没有可以等待的子进程	确认fork是否成功，确认子进程是否已经被回收过
fork之前printf的输出重复	父进程stdio缓冲区被复制给了子进程	fork前调用fflush(stdout)，或在子进程里改用_exit
子进程退出码总是-1或255	可能没有拆解status，直接把status当退出码用了	用WIFEXITED/WEXITSTATUS/WIFSIGNALED拆解status
父进程阻塞在wait上不返回	等待的子进程还没退出，或等待的pid写错了	确认子进程是否卡死，用WNOHANG轮询代替阻塞等待
信号处理函数只回收了部分子进程	一个SIGCHLD信号对应多个子进程退出，处理函数调用了一次waitpid	用while循环回收，直到waitpid返回0或-1

6.3 避坑心得

调试多进程程序时，强烈建议先画一张"谁创建谁、谁等谁"的关系图。进程控制的问题，大部分不是系统调用本身写错，而是对父子关系、回收职责划分不清。

实际项目中，我习惯把"创建子进程"和"回收子进程"放在同一层代码里，不让它们分散到不同模块。一个函数负责fork并记录子进程pid，另一个函数负责批量回收并上报状态，中间用pid数组关联。这样即使以后改成信号驱动回收，改动面也只在回收模块内部。

再补充一个小细节：如果父进程注册了SIGCHLD信号处理函数，同时又在主逻辑里用阻塞waitpid，两者会相互干扰。信号到达时waitpid被打断，返回-1并设置errno为EINTR。处理办法是检查errno，如果是EINTR就继续调用waitpid，或者干脆只在信号处理函数里回收，主逻辑不再调用waitpid，两种方案选一种，不要在一条链路里混用。