fork、wait、exec，这三个系统调用是Linux进程控制的基石。无论你是做嵌入式开发、写后台服务、维护运维脚本，还是准备Linux岗位的面试，都绕不开它们。这篇文章我会从最基础的概念讲起，用手写C代码的方式，把进程创建、回收、替换这三个核心环节彻底拆开，每一段代码都给注释、给原理、给坑点。没有废话，每一节都是可以直接拿去用的实操内容。适合刚接触Linux编程的新手，也适合复习进程相关面试题的开发者对照查漏。
1. 先搭好进程的底层认知框架
1.1 进程不是程序，而是"运行中的上下文"
很多入门资料一上来就扔fork，但我始终认为，在写第一行fork之前，得先把"进程到底是什么"这件事弄清楚。程序是磁盘上的二进制文件，是一堆指令和数据的静态集合；进程是程序被加载到内存、开始执行之后，内核为它维护的一整套运行时状态。
这套状态具体包括什么？页表映射、文件描述符表、信号处理函数表、当前工作目录、环境变量、资源限制、累计CPU时间、进程ID（PID）和父进程ID（PPID）等等。你可以把进程理解成"程序在运行中的快照 + 上下文"。
举一个生活化的例子：程序就像一本菜谱，静态地躺在抽屉里；进程则是你照着菜谱在灶台上炒菜的全过程——火候、油温、加了哪几样调料、当前炒到第几步，这些就是"上下文"。同一本菜谱可以开两个灶台同时炒，对应同一个程序可以运行多个进程，彼此互不干扰。理清这一点，后面理解fork、exec就会顺畅很多。
1.2 进程控制的三个核心动作：创建、等待、替换
Linux下的进程控制，表面上看系统调用很多，但归纳起来就是三个核心动作：
- 创建子进程：用
fork()（或者更现代的posix_spawn）。它让一个进程分裂成两个几乎一模一样的进程。 - 等待子进程结束：用
wait()或waitpid()。父进程负责"收尸"，回收子进程的退出状态和资源。 - 替换进程映像：用
exec家族函数。它在不创建新进程的前提下，把当前进程正在运行的代码替换成另一个程序，PID不变，但干的事完全不同。
三者通常协同工作：父进程先fork()一个子进程，子进程内部调用exec去加载一个全新程序，父进程则用wait等待子进程结束并检查它的退出状态。这就是Shell执行外部命令的底层逻辑，也是所有多进程服务的基本套路。
搞清楚这三件事，Linux下面90%的进程相关代码你都能看懂了。下面开始逐一拆解。
2. fork：一次调用，两次返回的魔法
2.1 fork的基本行为：复制当前进程
先看最经典的fork代码：
#include <stdio.h> #include <unistd.h> int main(void) { pid_t pid = fork(); if (pid < 0) { perror("fork error"); return 1; } else if (pid == 0) { printf("我是子进程，PID=%d，父进程PID=%d\n", getpid(), getppid()); } else { printf("我是父进程，PID=%d，子进程PID=%d\n", getpid(), pid); } return 0; }编译运行后，屏幕上会输出两行内容：一行属于父进程，一行属于子进程。这里的核心知识点是：fork()调用一次，却返回两次。父进程接收的返回值是子进程的PID，子进程接收的返回值是0。至于谁先执行，由调度器决定，不要假设任何顺序。
为什么是这种设计？因为返回值的差异是进程区分"我是父还是子"的唯一途径。父进程拿到子进程PID，才能在下文执行waitpid(pid)精准等待；子进程拿到0，则知道自己是被复制出来的那个，通常会直接进入exec替换掉自己。
fork成功之后，子进程几乎是父进程的"克隆体"：代码段、数据段、堆、栈、文件描述符表、环境变量、信号处理设置全部复制。但注意几个不会被复制的关键点：子进程有自己的PID、自己的父进程ID（即创建它的父进程）、自己的挂起信号队列、自己的时间计数器。这些细节在面试里常被考，记住它们比背一堆概念有用。
2.2 写时复制机制：fork为什么没那么贵
很多初学者以为fork就是完整地把父进程的内存复制一份给子进程。如果父进程占用了2GB内存，fork一次就要复制2GB，这显然太浪费了。实际上的Linux实现是写时复制（Copy-On-Write，简称COW）。
fork刚完成时，父子进程的物理内存页面还是同一份，页表也都指向这些共享页面，但被标记为"只读"。当任何一方尝试写入某个页面时，触发缺页异常，内核才把这一页真正复制一份，并更新对应的页表映射。这样一来，fork的开销大大降低：没有写操作时，几乎不复制内存，只复制页表和描述进程的内核数据结构。
这个机制告诉我们一个实战结论：fork本身并不贵，贵的是父子进程各自大量改写内存。所以"先fork再exec"的组合拳在性能上是非常合理的——fork几乎没有复制成本，紧接着exec直接把子进程的地址空间整个替换掉，前面的"复制"根本不会发生。这也是为什么vfork()在现代Linux上已经很少需要用了，COW已经把它的优势吸收殆尽。
2.3 实操：用fork写出第一个多进程程序
光看不练等于白看。我们写一个父进程和两个子进程并行干活的例子：
#include <stdio.h> #include <unistd.h> #include <sys/wait.h> static void do_work(const char *name, int loops) { for (int i = 0; i < loops; i++) { printf("%s: 第%d次干活\n", name, i + 1); usleep(200000); // 模拟耗时操作 } } int main(void) { pid_t pid1 = fork(); if (pid1 < 0) { perror("fork1"); return 1; } if (pid1 == 0) { do_work("子进程1", 3); return 0; } // 父进程继续创建第二个子进程 pid_t pid2 = fork(); if (pid2 < 0) { perror("fork2"); return 1; } if (pid2 == 0) { do_work("子进程2", 3); return 0; } // 父进程等待两个子进程 waitpid(pid1, NULL, 0); waitpid(pid2, NULL, 0); printf("父进程：两个子进程都干完了\n"); return 0; }这里面有几个值得注意的细节。第一，子进程里千万不要继续调用fork去生一大堆后代，除非你明确要做进程树，否则容易养成混乱的习惯。第二，子进程的return 0和exit(0)在这里效果类似，但在更深层的代码里，子进程应该用_exit()可能更安全，因为它不会冲刷父进程复制过来的stdio缓冲区。第三，父进程在fork之后创建的变量、打开的文件，子进程看不到——因为子进程是fork那个瞬间的复制品，之后两者各走各的路。
3. wait与waitpid：别让子进程变成僵尸
3.1 僵尸进程是怎么来的
先了解一个Linux进程的生命周期。子进程退出时，内核并不会立刻把它的task_struct等数据全部销毁，而是让它进入Z状态——僵尸态。之所以保留这些数据，是因为父进程（或之后的init进程）需要读取子进程的退出状态码，判断它到底是正常退出、被信号杀死，还是被信号停止。只有父进程调用wait()或waitpid()成功回收之后，僵尸进程残存的最后一点数据才会被彻底释放。
如果一个父进程创建了子进程，却从不调用wait，子进程退出后就会一直停留在僵尸状态。僵尸进程不占CPU、不占内存，但它会占用内核进程表中的槽位。如果僵尸进程积累太多，进程表被填满，系统就没法再创建新进程了——这是生产中非常典型的事故现场。
举个例子，一个常驻后台的服务程序，每来一个请求就fork一个子进程处理，但忘了wait。高峰期产生几百个请求，就留下几百个僵尸进程。如果服务运行几年不重启，进程表满后fork直接返回失败，服务就"卡死"了。所以我平时排查线上问题时，看到ps输出里成片的Z状态进程，第一反应就是去检查父进程的wait逻辑。
3.2 wait与waitpid的参数和对比
先看最简单的wait()：
#include <sys/wait.h> pid_t wait(int *status);它阻塞当前进程，直到任意一个子进程退出，然后返回那个子进程的PID，同时把退出状态写入status指向的变量。wait()的问题是：它没法指定等谁，也不知道到底有几个子进程还没退出。于是更精确的waitpid()出场了：
pid_t waitpid(pid_t pid, int *status, int options);pid参数的三种典型用法：
pid > 0：等待PID等于该值的特定子进程。pid == -1：等待任意子进程，等价于wait。pid == 0：等待与调用进程同组的任意子进程。
options参数最常用的是WNOHANG：如果没有任何子进程退出，立即返回0而不是阻塞。这是实现非阻塞回收、配合事件循环的标配。
重点学习如何解析status。status不是简单的退出码，它是一个位掩码，必须用宏来解析，千万别自作聪明地直接打印。我见过不少新手把status当int直接printf，结果看到一串莫名其妙的数值，其实那是信号编号和退出码的"拼接体"。推荐记得最常用的三个宏：
WIFEXITED(status)：子进程是否正常退出（通过exit或return）。WEXITSTATUS(status)：正常退出时拿到退出码，只在WIFEXITED为真时有意义。WIFSIGNALED(status)：子进程是否被信号终止。
3.3 实操：循环回收所有子进程
如果一个父进程fork了多个子进程，简单调用两次wait不一定靠谱，因为你不知道子进程退出的先后顺序。最稳妥的写法是循环wait，直到返回-1：
#include <stdio.h> #include <unistd.h> #include <sys/wait.h> int main(void) { for (int i = 0; i < 5; i++) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return 1; } if (pid == 0) { // 子进程做点事然后退出，退出码和循环下标挂钩 _exit(i + 1); } } // 父进程循环回收 int status; pid_t child; while ((child = wait(&status)) != -1) { if (WIFEXITED(status)) { printf("子进程 %d 正常退出，退出码 %d\n", child, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("子进程 %d 被信号 %d 杀死\n", child, WTERMSIG(status)); } } perror("wait"); // 此时errno是ECHILD，表示没有子进程了 return 0; }这段代码有个小知识点：最后那个perror("wait")一定会执行，因为循环退出的唯一条件就是wait返回-1，而这里没有子进程时errno会被设为ECHILD。所以"errno==ECHILD"在业务代码里不应该当成错误，它是正常终止循环的条件。这也是面试里常考的细节：如何判断所有子进程都已经回收完毕。
4. exec家族：让进程"换一个程序"运行
4.1 exec六兄弟：l、v、p、e都是什么意思
exec不是一个单独的函数，而是一族函数的总称，标准的有六个：execl、execlp、execle、execv、execvp、execv。后四个加上execvpe是GNU扩展。
记忆方法就两个字：字母决定参数形式。
- 带
l（list）：参数以列表形式逐个传入，最后一个必须用NULL结束。execl("/bin/ls", "ls", "-l", NULL)。 - 带
v（vector）：参数以字符串数组传入。char *argv[] = {"ls", "-l", NULL}; execv("/bin/ls", argv); - 带
p（path）：表示会在环境变量PATH中自动搜索命令路径。比如execlp("ls", "ls", "-l", NULL)，不需要写全路径。 - 带
e（environ）：可以自定义环境变量数组传给新程序，通常和v组合成execve。
这六个函数底层都归结到同一个系统调用：execve()。其余五个都是它的包装。这里要特别提醒：不要用execvp("ls", argv)就默认万事大吉，因为带p的版本在找不到命令时会按PATH逐个目录尝试，如果同时传了自定义环境变量要格外小心，避免环境变量污染新程序的行为。
exec家族函数有一个非常反直觉的特征：它们几乎不可能返回成功。如果exec执行成功，当前进程的代码、堆、栈、数据段全部被新程序替换，控制流直接跳进新程序的入口，永远回不到exec调用点。所以exec一旦"返回"了，返回的必然是-1，是一个失败信号。写代码时，exec调用之后的那几行，基本全是错误处理：
execl("/bin/ls", "ls", "-l", NULL); // 走到这里说明exec失败了 perror("execl"); exit(127); // 127在shell中表示"命令找不到"的惯例4.2 exec的几个大坑
第一个坑是路径问题。使用不带p的exec族时，如果传的是相对路径，比如execl("ls", "ls", NULL)，它会直接在当前工作目录找ls，而不是去PATH里找。正确做法要么写绝对路径/bin/ls，要么用execlp。
第二个坑是argv和程序名的关系。Unix的传统是argv[0]通常是程序自身的名字，但这个值是可以伪造的。比如你执行execl("/bin/echo", "nice", "hello", NULL)，程序虽然跑的是echo，但它看到的argv[0]是"nice"。很多命令行工具会根据argv[0]改变行为（比如busybox就是这样），这个特性既是灵活也是坑。
第三个坑是文件描述符。exec成功后会关闭FD_CLOEXEC标志的文件描述符，没设置该标志的描述符会被新程序继承。这会导致新程序意外持有你不希望它持有的打开文件、socket连接，带来严重的安全和资源泄漏问题。实操建议很明确：所有不需要继承给子进程的fd，从创建那一刻就设置O_CLOEXEC或FD_CLOEXEC。比如socket()、open()带有O_CLOEXEC标志，或者之后用fcntl(fd, F_SETFD, FD_CLOEXEC)。
4.3 实操：fork+exec组合拳
下面的例子模拟一个"父进程指挥子进程执行外部命令"的完整流程。父进程创建子进程，子进程exec/bin/echo输出一段文本，父进程负责回收并检查退出码：
#include <stdio.h> #include <unistd.h> #include <sys/wait.h> #include <stdlib.h> int main(void) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return 1; } if (pid == 0) { // 子进程：直接换程序 execl("/bin/echo", "echo", "hello from exec", NULL); // 如果走到这里说明exec失败了 perror("execl"); _exit(127); } // 父进程：等待子进程结束 int status; if (waitpid(pid, &status, 0) == -1) { perror("waitpid"); return 1; } if (WIFEXITED(status)) { printf("子进程正常退出，退出码=%d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("子进程被信号%d杀死\n", WTERMSIG(status)); } return 0; }这段代码我在实际项目中反复使用，几乎可以当成模板。核心要点：子进程里exec失败后要_exit而不是return，因为子进程可能已经改写了文件描述符、缓冲区的状态，直接return可能导致父进程环境被污染。另外，父进程的waitpid不要用wait()代替，明确指定pid才能确定回收的是哪个子进程，避免多个子进程时张冠李戴。
5. 综合实战：一个稳定的进程控制模板
5.1 完整代码与逐步解读
把上面几个知识点组合成一个稍微完整的例子：父进程fork一个子进程，子进程用execvp执行一个用户指定的命令，父进程回收并汇报退出状态。这段代码可以直接作为写命令行工具时的骨架：
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> #include <string.h> int run_command(char *const argv[]) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return -1; } if (pid == 0) { // 子进程执行命令，failure时立即退出 execvp(argv[0], argv); perror("execvp"); _exit(127); } // 父进程等待 int status; if (waitpid(pid, &status, 0) == -1) { perror("waitpid"); return -1; } if (WIFEXITED(status)) { return WEXITSTATUS(status); } else if (WIFSIGNALED(status)) { fprintf(stderr, "进程被信号 %d 终止\n", WTERMSIG(status)); return 128 + WTERMSIG(status); // 模拟shell的退出码惯例 } return -1; } int main(int argc, char *argv[]) { if (argc < 2) { fprintf(stderr, "用法: %s 命令 [参数...]\n", argv[0]); return 1; } // argv结构：argv[1]是命令名，argv[1:]是它的参数 char **cmd = &argv[1]; int ret = run_command(cmd); printf("捕获到 [%s] 的退出码: %d\n", cmd[0], ret); return ret; }这里面有个隐藏亮点：char **cmd = &argv[1]直接把命令行参数"借给"execvp用，不用再造数组。因为execvp要求的就是以程序名开头、NULL结尾的argv结构，而C main的argv天然就是这样的结构，只是多了argv[0]是当前程序名。这种复用argv的写法简洁又不容易出错，推荐给读者收藏。
信号终止时返回128+信号编号也是Shell的约定。比如一个进程被SIGKILL（信号9）杀死，shell通常报137。我在脚本里处理子进程退出状态时，用这个约定能跟shell行为对齐，排查问题少绕很多弯。
5.2 面试高频题与易错点
作为经常整理面试题的人，我把Linux进程控制这个主题下的高频考点列一下，对着复习效率很高。
- fork返回值的完整语义：为什么父进程收到子进程PID、子进程收到0，以及如何使用返回值分流控制流。
- fork之后变量是否共享：答案是"初始相同、物理独立"，父子的内存是复制关系不是共享关系，改一方不影响另一方。如果要共享必须用共享内存或mmap。
- fork与缓冲区的经典坑：如果父进程在fork前已经向stdout写入了内容但没冲刷（比如printf没加换行），复制到子进程的缓冲区里也有一份，子进程exit时会把它再输出一遍，导致内容重复。我实测过的解决方法是：fork前
fflush(NULL)刷新所有输出流。 - exec成功不返回的原理：地址空间已经替换，原进程的返回路径不存在了。
- 僵尸进程vs孤儿进程：僵尸进程是已退出但未被wait回收的进程；孤儿进程是父进程先退出，而被init或子reaper收养的进程。别把两者混为一谈。
- wait与waitpid的WNOHANG配合：如何在不阻塞的情况下查询子进程状态，这是实现事件驱动服务的关键。
面试答题有个通用套路：先说定义，再说代码层面怎么用，最后说生产中遇到过什么问题。把上面每一点都配上"我实际遇到过"的经历，比死记硬背有效得多。
6. 常见问题与排查技巧实录
6.1 排查僵尸进程的现场方法
查僵尸进程最快的命令是：ps -eo pid,ppid,stat,comm，状态列里看到Z就是僵尸。或者用top命令，在进程列表的S列也会看到Z。
确认僵尸进程之后，下一步是看它的PPID是谁。如果PPID是1（init），说明它的父进程已经退出，init会负责回收，只是有时需要点时间。如果PPID是一个正常运行的业务进程，那几乎可以肯定父进程没有正确调用wait或waitpid。这时候的处理办法通常是：修代码，在父进程里补上wait循环；如果情况紧急先把父进程重启，僵尸进程会被init重新收养。
其实很多服务框架已经封装好了进程回收逻辑，但自己手写多进程服务时，最容易漏掉的就是"子进程意外退出时父进程没有及时回收"。我踩过最严重的一次线上事故，就是一个常驻任务进程每处理一个任务就fork一次，处理完不wait，半年后进程表满了，新任务连fork都失败，服务直接瘫痪。从那以后，我写任何fork代码，第一件事就是把wait循环写好，甚至先写完回收逻辑再写业务逻辑。
还有个隐蔽问题：父进程自己没退出，但也没有任何子进程时，wait()会一直阻塞。所以只要不是明确的"等下一次子进程退出"语义，我都会用waitpid(-1, &status, WNOHANG)轮询。后者成为非阻塞回收的标配姿势。
6.2 信号、孤儿进程与守护进程的补充
最后补充三个边界场景。
第一，子进程被信号杀死是常态，不只是崩溃。比如用户按Ctrl+C，内核把SIGINT发给整个前台进程组，所有前台子进程都会收到信号。父进程在waitpid返回后应该用WIFSIGNALED判断一下，不要把"被信号杀死"当成"异常"之外的情况简单忽略。
第二，孤儿进程也不要害怕。父进程退出后，孤儿进程会被内核送给最近的subreaper或init进程收养，由收养者负责wait回收。所以孤儿进程本身不会变成僵尸，真正的僵尸一定有一个还没来回收它的活着的父进程。理解这点对排查非常有用。
第三，守护进程的常规做法离不开fork：第一次fork后子进程调用setsid()创建新会话、脱离控制终端，有时会再fork一次防止重新获得终端，最后chdir("/")并把标准输入输出重定向到/dev/null。虽然现在很多人用systemd的Type=forking或直接前台运行，但了解这套从fork演化出来的流程，能帮你理解为什么很多传统服务的启动脚本长那样。
说到底，进程控制的知识点拉通起来就是一条线：创建时用fork，换程序时用exec，回收时用wait。把这条线上的每个系统调用的返回值、状态解析、错误处理都摸透，你再去看任何多进程服务、Shell实现、嵌入式daemon的代码，都会轻松得多。我每次带新人，也都是先从这三个函数入手，因为他们确实是Linux并发编程的第一道门槛，跨过去了，后面的线程、锁、通信才能盖得稳。
