写Linux程序的人，几乎都要跟进程控制打交道。fork、exec、exit、wait这四个词，翻过书的人都能念出来，但真正把它们组合起来用对，才是区分“看过”和“会写”的分水岭。我见过不少开发者在多进程服务里栽跟头，要么子进程变僵尸，要么进程崩了没人拉起，要么fork之后缓冲区输出乱套。这些问题的根源，说到底都是对进程控制的理解还停留在“调用一下就行”的层面。
这篇文章我不打算罗列man手册，而是从进程生命周期讲起，把创建、退出、回收、替换这几个环节逐层拆开，配合可直接跑的代码和实际踩坑记录，把进程控制这摊事讲清楚。适合正在学Linux系统编程的在校同学，也适合刚接触后端服务、需要排查线上多进程问题的工程师。只要你手上有台Linux机器，能写一点C语言，就可以照着做一遍，踩一遍坑之后再回头看，很多问题会豁然开朗。
1. 进程控制全景：先从生命周期认识“控制点”
1.1 一次进程从生到死发生了什么
在Linux里，进程不是凭空出现的，也不是自己结束的。它的一生大致分四步：被创建、加载代码运行、正常或异常退出、被父进程回收。每一步都对应一组系统调用，这就是“进程控制”的对象。
我常用一个比喻：把进程想象成厨房里的一张订单工单。fork相当于前台把新订单录入系统，生成一个工单实例；exec相当于给这个工单绑定具体的菜品做法；exit相当于厨师做完菜之后在工单上打上“完成”标记；而wait则是店长确认这张订单真的收尾了，才允许销毁工单。如果不做最后一步确认，工单就一直占着柜台位置，新的订单就送不进来。
这个类比不是万能的，但能解释一个关键点：进程创建和进程销毁，并不是对称的简单操作。创建进程的核心系统调用是fork，销毁进程的核心系统调用是exit，而真正完成“销毁确认”的是wait系函数。很多新手只盯着fork，忽略了exit和wait，所以才会出现僵尸进程这种常见病。
1.2 进程控制到底在控制哪些资源
进程是Linux资源分配的基本单位，这句教科书定义听起来抽象，落到控制层面就非常具体了。一次fork后，子进程会得到一套独立的资源视图，包括文件描述符表、信号处理设置、当前工作目录、环境变量、以及一份“看起来完全拷贝”的地址空间。exec则会把这份地址空间里的代码段、数据段、堆和栈全部换成新程序的内容，但PID、文件描述符表这些内核资源依然保留。
这也是为什么进程控制从来不只是“多开几个程序”那么简单。你在进程管理里做的每一个决定，本质都是在管理资源的归属和生命周期。例如父进程持有的监听socket，fork之后子进程也会继承这个文件描述符，如果不主动关闭，就可能出现多个进程同时监听同一端口的情况；又比如父进程和子进程共用了某个已加锁的互斥量，fork之后如果直接调用exec，执行流可能带着奇怪的锁状态进入新程序。
理解了这一点，再看下面各个系统调用，思路就顺了。我们不是在“调用API”，而是在精确控制一组资源的创建、替换和回收。
2. 进程创建：fork到底发生了什么
2.1 调用一次fork，为什么返回两次
先看最经典的fork用法：
#include <stdio.h> #include <unistd.h> #include <sys/types.h> int main() { pid_t pid = fork(); if (pid < 0) { perror("fork"); return 1; } if (pid == 0) { printf("child here, my pid=%d, parent pid=%d\n", getpid(), getppid()); } else { printf("parent here, child pid=%d, my pid=%d\n", pid, getpid()); } return 0; }fork的返回值有三个情况：父进程返回子进程的PID，子进程返回0，失败返回-1。很多人第一次看到这个设计会觉得奇怪：一个函数怎么可能有两个返回值？实际上不是函数返回了两次，而是调用fork之后，系统里出现了两个执行流，每个执行流各自从fork的那条return语句之后继续往下走，于是每个执行流都会“看到”一个返回值。
这种设计的精妙之处在于，父子进程通过不同的返回值，天然地进入了不同的业务分支。父进程需要拿到子进程的PID，才能以后精确地管理这个子进程，所以fork把子进程的PID返回给父进程；子进程想知道自己是谁，直接调用getpid()就行，不需要fork额外返回。返回0给子进程，也方便写if (pid == 0)这种判断。
有一点要提醒：父子进程谁先继续跑，是由内核调度器决定的，不保证父先跑还是子先跑。所以上面那段例子的打印顺序是不确定的，这是进程控制里第一个需要接受的“随机性”。
2.2 写时复制：fork并不是真的“复制”
早期Unix版本的fork确实会把父进程的地址空间完整复制一份，代价高昂。现代Linux采用写时复制，英文叫Copy-On-Write，思想很朴素：fork的时候并不复制物理内存，只把父进程的页表项复制一份给子进程，同时把这些页标记为只读。两个进程可以安心地共享同一批物理页面，谁都不去写，大家相安无事。
一旦父子进程中的某一个真的往共享页里写数据，CPU会触发一个缺页异常，内核这时才分配新的物理页，把原内容拷贝过去，然后把对应进程的页表项改成可写。这样，绝大多数情况下fork的开销就只是建立页表和复制少量描述符，极快。
这个机制直接催生了一条重要经验：fork之后立刻exec，是非常高效的，因为exec会直接丢弃父进程的地址空间，那些共享页根本不会被触发复制。反过来，如果fork之后父子进程都继续跑复杂的业务，大量页面会被逐个复制，性能损耗就会显现出来。
另外，多线程程序里调用fork要格外小心。fork只会复制当前调用线程，其他线程不会存在，但那些线程可能正持有锁。于是子进程里这些锁会保持在“已被持有”的状态，如果子进程后续又去加速锁，就可能死锁。这也是为什么很多服务端程序避免在多线程运行期间直接调用fork，而是采用专门的进程模型。
3. 进程退出和“僵尸”问题：资源回收的艺术
3.1 exit、_exit、return的区别，决定日志会不会重复
进程退出比新手想象中复杂。return是函数返回，只能在main函数里当成进程退出；exit是库函数，负责清理用户态资源；而真正进入内核做退出动作的是_exit系统调用。它们之间的差别，最典型的现象就是缓冲区。
看这个例子：程序里用printf打印一行内容，但printf的缓冲区没有及时刷新。如果调用exit，标准库会冲刷缓冲区，内容正常打印；如果调用_exit，缓冲区里的内容直接被丢弃。更隐蔽的是在fork之后：子进程继承了父进程的缓冲区数据，exit时会把这份缓冲区再刷一遍，于是你可能看到同一行日志输出两次。
实际开发中，我习惯在fork之前调用fflush(NULL)，把所有标准IO缓冲区清空。子进程里如果exec失败，需要退出时直接用_exit(127)，绕开用户态库的清理动作。这能省去一大堆莫名其妙的“日志重复”问题。
3.2 僵尸进程是怎么养成的
子进程退出后，内核不会立刻把它的所有信息清空。它会保留一份最小的进程描述符和退出码，直到父进程调用wait或waitpid来“收尸”。如果父进程一直不调用，或者父进程自己也退出了，而子进程还没被收养，就会发生下面两种情况之一：子进程变成僵尸进程，由init进程（PID为1的进程）临时收养并回收；或者在一些容器环境里，1号进程不一定承担收养职责，僵尸就可能一直赖着不走。
僵尸进程的危害不在于占内存，而在于它无法被kill，因为已经“死”了，只是没拆干净。每次产生一个僵尸，就有一个PID被占用。如果生产环境里僵尸进程数量持续累积，最终会达到进程数上限，导致fork返回-1，服务直接无法创建新进程。
避免僵尸的标准姿势有三种：父进程主动waitpid；父进程用SIGCHLD信号通知配合waitpid；或者用fork两次的技巧，让子进程再fork一个孙进程，然后子进程立刻退出，这样孙进程被1号进程直接收养，父进程不用管。其中信号配合waitpid是生产环境最常用的方案，我在第5节会给出完整示例。
3.3 waitpid的参数并没那么难
waitpid的完整定义是：
pid_t waitpid(pid_t pid, int *status, int options);pid传-1表示等待任意子进程；options传WNOHANG表示如果没有子进程退出就立即返回0，不阻塞。status里面装着退出码和终止信号，需要配合WIFEXITED、WEXITSTATUS等宏来解析。很多人在这个地方犯迷糊，其实记住一句话就行：waitpid只负责“确认并回收”，不负责“判断业务是否成功”，判断业务是否成功要靠status宏去拆。
4. 进程替换：用exec族把一个进程变成另一个程序
4.1 execve才是底层的那个主角
Linux上真正的进程替换系统调用是execve：
int execve(const char *path, char *const argv[], char *const envp[]);另外的execl、execv、execlp、execvp、execle都是包装过的库函数，最终都会调用execve。进程一旦执行execve成功，当前进程的代码段、数据段、堆栈全部被替换成新程序，但PID不变，文件描述符表大多数情况下也不变，当前工作目录不变。所以执行exec之后，原来的代码除了返回值-1这个失败情形之外，不会继续执行。这也是为什么通常exec调用后面紧跟着perror和exit，否则一旦exec失败，状态会非常难查。
文件描述符的继承性很重要。假设父进程监听着8080端口，fork后执行exec，子进程中那个监听socket仍然开放。如果业务上不允许子进程持有这个fd，应该在exec之前主动close(fd)，或者给fd加上FD_CLOEXEC标记，让exec时自动关闭。
4.2 六个兄弟函数怎么选
| 函数 | 路径查找 | 参数形式 | 环境变量 |
|---|---|---|---|
| execl | 显式路径 | 可变参数列表，以NULL结尾 | 继承现有环境 |
| execv | 显式路径 | 字符串数组 | 继承现有环境 |
| execlp | 通过PATH查找 | 可变参数列表，以NULL结尾 | 继承现有环境 |
| execvp | 通过PATH查找 | 字符串数组 | 继承现有环境 |
| execle | 显式路径 | 可变参数列表，以NULL结尾 | 自定义envp |
| execve | 显式路径 | 字符串数组 | 自定义envp |
选择策略很简单：参数固定就选l系列，参数个数会动态变化就选v系列；想让系统用PATH帮你在常见目录中找可执行文件就选带p的版本，否则老老实实写完整路径。自定义环境变量只在特殊场景才需要，一般情况直接继承环境就够了。实际工作中，我用得最多的是execvp和execve，前者跑外部命令很方便，后者适合做精确控制。
4.3 exec失败后的善后处理
exec返回-1时会设置errno，常见错误包括：文件不存在（ENOENT）、权限不足（EACCES）、可执行文件格式无法识别（ENOEXEC）。还有一个容易忽略的点：如果脚本第一行的解释器路径写错，execve同样会失败，shell脚本也不例外。
exec失败之后，当前进程还在，还会继续执行刚才的代码。所以如果写的是：
execl("/opt/service/bin/worker", "worker", NULL); printf("this will run only when exec fails\n");错误处理一定要跟上。很多启动脚本里的服务静默失败，就是没检查exec的返回值，或者perror打印被后续代码覆盖了。约定俗成的做法是exec失败后立即打印错误信息并_exit(127)。127这个数字不是随便来的，shell体系里约定127表示“命令未找到”，继承这个约定能和其他工具的行为保持一致。
5. 实战：写一个能自动重启的进程守护程序
5.1 需求拆解：挂着、盯着、拉起来
进程控制各系统调用单独看都不复杂，难在组合。我来写一个实际场景：假设有一个叫worker的服务进程，它跑在后台提供一些计算能力，我需要在它崩溃或退出之后自动拉起，同时在被通知停止时能优雅地把整个守护程序停下来。
拆解下来需要四个能力：fork创建子进程、exec把子进程替换成worker、waitpid回收退出状态、SIGCHLD信号通知父进程“子进程状态有变化”。这个模式非常典型，很多简单的进程管理器和容器init进程都是这个骨架。
5.2 代码实现：信号处理与主循环
#include <errno.h> #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/wait.h> #include <unistd.h> static volatile sig_atomic_t child_exited = 0; static volatile sig_atomic_t stop_flag = 0; static void handle_sigchld(int sig) { child_exited = 1; } static void handle_stop(int sig) { stop_flag = 1; } int main() { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = handle_sigchld; sigaction(SIGCHLD, &sa, NULL); sa.sa_handler = handle_stop; sigaction(SIGTERM, &sa, NULL); sigaction(SIGINT, &sa, NULL); while (!stop_flag) { pid_t pid = fork(); if (pid < 0) { perror("fork"); sleep(1); continue; } if (pid == 0) { char *args[] = { "./worker", "config.ini", NULL }; execv(args[0], args); perror("execv"); _exit(127); } while (!stop_flag && !child_exited) { pause(); } if (stop_flag) { break; } child_exited = 0; int status; pid_t ret; do { ret = waitpid(pid, &status, WNOHANG); } while (ret == 0 && !stop_flag); if (ret == pid) { sleep(1); } } while (waitpid(-1, NULL, WNOHANG) > 0) { ; } return 0; }主循环的思路是这样：先fork，子进程里exec替换成worker；父进程在pause处挂起，等待SIGCHLD信号。SIGCHLD到来时，handle_sigchld把child_exited置1，pause提前返回，主循环进入waitpid回收子进程，然后sleep(1)作为重启间隔，继续下一次fork。stop_flag为1时跳出循环，最后把还没回收的全部子进程清理一遍后退出。
5.3 这段代码里的坑，我一个个踩过
第一，信号处理函数里不要调用printf、malloc这类非异步信号安全函数。上面代码里信号处理函数只对一个volatile sig_atomic_t变量赋值，这是标准做法。打印日志放到主循环里做，不要在信号函数里做。sig_atomic_t类型保证读取和赋值是原子的，不会被信号打断出问题。
第二，重启间隔必须加。如果没有sleep(1)，一旦worker因为某种原因启动即崩溃，守护程序会进入“fork->exec->崩->再fork”的死循环，瞬间把CPU打满，还会产生海量进程切换。加一个固定时间间隔是最简单的熔断机制。
第三，waitpid的循环条件要小心。代码里用了WNOHANG做非阻塞轮询，但在一个子进程的场景下，SIGCHLD信号已经告诉你“有子进程状态变化”，其实可以直接阻塞waitpid一次。我保留这个非阻塞写法，是为了应对极端情况：如果SIGCHLD信号到达时主循环刚好在处理其他事，waitpid可能一时还没拿到状态，循环等待避免了吞掉信号。如果你要管理多个子进程，记得waitpid的pid参数要用-1，并且加一个足够小的循环，把这次信号对应的所有退出子进程都回收掉，因为Linux信号不排队，可能只给你一个SIGCHLD。
6. 进程控制调试与排查实践
6.1 常见问题速查：一眼定位病因
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| ps显示子进程状态为Z | 父进程没执行wait/waitpid | 检查父进程代码，补充回收逻辑 |
| fork返回-1 | 进程数达到上限或内存不足 | 查看ulimit -u，检查系统进程数 |
| exec后程序没按预期运行 | 路径不对、权限不足、解释器缺失 | strace跟踪execve调用，看errno |
| printf日志重复出现 | fork复制了标准IO缓冲区 | fork前fflush(NULL)，子进程用_exit |
| 子进程没退出但无法被waitpid | 父进程和子进程陷入死锁或阻塞 | gdb attach父进程和子进程，看栈帧 |
| 守护程序反复重启worker | worker启动即崩溃，缺少重启间隔 | 加sleep间隔，并查看worker日志 |
| 子进程继承了不该有的端口 | fork/exec保留了文件描述符 | 显式close(fd)或设置FD_CLOEXEC |
这里最常用的两个工具：ps -o pid,ppid,stat,cmd可以快速看清父子关系和进程状态；strace -f -e trace=process可以跟踪所有进程控制相关的系统调用，包括fork、execve、waitpid。排查僵尸进程时，我第一件事就是ps看STAT列，看到Z直接找父进程。
6.2 进程控制代码自查清单
写进程控制相关代码时，我每次都会在脑子里过一遍六个问题：fork之后有没有立刻判断返回值？子进程退出时用的是exit还是_exit，会不会冲刷带动缓冲区？exec失败之后有没有除了perror之外的处理逻辑？子进程是否继承了我没打算共享的文件描述符？父进程是否在SIGCHLD或者waitpid里做了全量回收？守护进程有无重启间隔，防止崩溃循环打爆CPU？
这六个问题看起来简单，但每一个都有对应真实事故。我见过有服务因为少判断fork失败，在系统进程数超限时无限循环创建进程，最后把整台机器拖垮；也见过因为exec后漏了_exit，导致子进程一边执行着新程序启动逻辑，一边还在继续跑父进程的循环，两个逻辑混在一起，现象极其诡异。这些坑的共同特点就是：不在现场看，很难一眼想到是进程控制的问题。
我个人调试这类问题最有用的方法，不是加日志，而是直接用strace跟进程控制相关的调用轨迹。它会把fork的返回值、execve的参数、waitpid的结果都打出来，一条一条对下来，问题几乎藏不住。如果你能灵活运用fork、exec、wait、信号这几板斧，再把排查工具用得顺手，Linux多进程编程就算是真正迈过门槛了。
