1. 进程退出：正常退出和异常退出之间到底差了什么

系列写到第十一篇，进程的“后半生”终于要聊透了。前面几篇我们把进程从fork创建讲到了调度切换，但有个问题很多朋友在学的时候容易忽略——进程怎么死、死了之后怎么被收尸、怎么被替换成另一个程序。这三个问题看着零散，实际上是一条完整的链路：终止 -> 回收 -> 替换。搞懂这条链路，你才真正明白操作系统里“进程”这个东西不是静态的概念，而是一个不断出生、存活、死亡、被继承的完整生命周期。

先说进程终止这件事。很多人第一反应是“进程终止不就是执行完 return 0 嘛”，这句话对了一半，但远不够。进程退出在 Linux 下至少有五种路径，我列一下：

• main函数里执行return，编译器会在背后帮我们补上exit调用
• 主动调用exit函数，这是标准 C 库提供的
• 主动调用_exit或_Exit，这是系统调用级别的
• 被某个信号杀死，比如按 Ctrl+C 发送 SIGINT，或者kill -9发送 SIGKILL
• 最后一个线程返回了，或者调用了pthread_exit

这五种路径表面看都是“进程没了”，但操作系统在里面做的工作差别非常大。最核心的区别在第一类到第三类是“主动终止”，应用层代码可以控制退出码、可以执行清理函数；而第四类是“被动终止”，进程根本没有机会做任何清理，内核直接把资源回收了。

1.1exit与_exit的差异：不只是差一个函数名

很多教材上都会讲exit会刷新缓冲区而_exit不刷新，这里我要多说几句。标准 I/O 库（比如printf）为了提高效率，往磁盘或者终端写数据的时候不是每次都进内核的，而是在用户态缓冲区攒着，等缓冲区满了或者遇到换行符（终端模式）再一次性写入。

如果你在代码里写了printf("hello")然后立刻调用_exit(0)，这个字符串大概率不会出现在屏幕上，它死在用户态缓冲区里了。而exit在真正进入内核之前，会先调用stdio层的清理函数把所有缓冲区刷干净。

这个细节在写守护进程、写一些长时间运行的服务时特别容易踩坑。想象一下你在某个模块里用printf打日志，调试的时候一切正常，结果代码提交之后日志全丢了，排查半天发现是某个错误路径直接调了_exit。我建议在代码评审里约定：非极端情况统一用exit，只有exec失败或者子进程刚fork出来急需快速退出这种场景才考虑_exit。

再看atexit注册的清理函数。exit会按注册的逆序逐个调用这些钩子函数，_exit一个都不调。这个机制的典型用途是清理临时文件、释放共享内存、写最后的审计日志。但这里有个陷阱：如果你注册的清理函数里又调用了exit，结果是未定义的，实际工作中应该尽量避免这种互相纠缠的写法。

1.2 退出码的传递机制与解析

进程退出后，内核会保留一个很小的数据结构，里面存着退出码和终止信号，直到父进程来取。这也是我们下一步要讲的“回收”问题的源头。子进程的退出码在 shell 里可以通过$?查看，但在父进程里要用wait系列函数拿。

值得注意区分两种退出码：

• 正常退出时，退出码是 0~255 之间的整数，main返回值、exit参数都可以决定它
• 被信号杀死时，内核记录的是终止信号编号，比如 SIGSEGV 对应 11，SIGKILL 对应 9

判断子进程是被信号杀死还是正常退出，要看wait返回的状态字里不同的位段。状态字是一个 int，它的编码规则比较绕，我在这里给一个最常用的判断口诀：WIFEXITED(status)为真说明正常退出，WEXITSTATUS(status)拿具体退出码；WIFSIGNALED(status)为真说明被信号杀，WTERMSIG(status)拿信号编号。

还有一个细节很多人不知道：如果你在 shell 里执行echo $?拿到 127，这往往意味着命令不存在；拿到 126 通常意味着命令存在但不可执行。这些不是内核规定的，是 shell 约定俗成的映射，理解这个对你写启动脚本排查问题很有帮助。

2. 僵尸进程：为什么系统里躺着大量“死人”会造成麻烦

接下来聊进程回收，这一章我想用“收尸”来类比。进程终止之后，内核其实并不会立刻把所有数据结构都删掉，至少要保留进程号、退出状态、资源使用统计这些信息，因为父进程可能随时来查询。这就是僵尸进程的本质——进程已经死了，但尸体还没被认领。

僵尸进程在ps命令里显示为Z状态。它的危害不在于占用 CPU（它根本不运行了），而在于：

• 占着进程表项不释放，进程号 PID 不能被复用
• 如果僵尸进程数量很多，进程表满了，新进程就fork不出来
• 父进程如果一直不去回收，僵尸会一直挂着

这里要澄清一个天大的误解：不是所有僵尸进程都是糟糕的。短暂的僵尸状态是正常生命周期的一部分，子进程死了，父进程还没调用wait，这段时间本来就应该显示为僵尸。真正有问题的是父进程死活不调用wait，导致僵尸永久挂起。

2.1 回收方案一：同步阻塞式回收

最简单的回收方式就是父进程调用wait或者waitpid，这个调用会阻塞在那里，直到有一个子进程终止。看这个最小示例：

#include <sys/wait.h> #include <stdio.h> #include <unistd.h> #include <stdlib.h> int main() { pid_t pid = fork(); if (pid == 0) { printf("child is running, pid = %d\n", getpid()); sleep(2); exit(42); } else { int status; pid_t ret = wait(&status); if (WIFEXITED(status)) { printf("parent waits done, child pid = %d, exit code = %d\n", ret, WEXITSTATUS(status)); } } return 0; }

wait系列函数的坑在于：如果父进程同时有好几个子进程，一次wait只能回收一个，而且你事先不知道回来的是哪个孩子。如果你要精确等待特定某个子进程，必须用waitpid(pid, &status, 0)，第一个参数指定要回收的进程号。

还有一个很实用的选项：waitpid(pid, &status, WNOHANG)。加上这个选项之后，如果子进程还没退出，调用不会阻塞而是立刻返回 0。这在非阻塞轮询的场景里非常有用。

2.2 回收方案二：异步信号驱动回收

如果父进程是个服务主进程，它不可能为了等一个子进程退出就阻塞在wait上，那样的话整个服务的并发能力就毁了。业内标准的做法是利用SIGCHLD信号。

子进程终止的时候，内核会自动向父进程发送SIGCHLD信号，默认行为是忽略它。我们可以在父进程里注册一个信号处理函数，在里面调用waitpid回收僵尸。这里有个经典的坑：传统signal注册的信号处理函数，执行完之后信号处理方式会被重置为默认行为，所以要么用sigaction，要么在回调里反复重新注册。

另外还有一个更隐蔽的坑：如果你的服务是多次fork出多个子进程，同一时刻可能有多个子进程同时终止，内核会不会给你发多个SIGCHLD？答案是不一定。标准信号是不可排队的，如果父进程处理完第一个信号之前又来了几个信号，后面的信号会被合并为一次。所以正确的做法是在处理函数里用while循环配合waitpid(-1, &status, WNOHANG)把所有僵尸一次性回收干净，直到返回 0 或 -1（注意要判断 ECHILD）。

#include <signal.h> #include <sys/wait.h> #include <stdio.h> #include <unistd.h> #include <string.h> #include <errno.h> static void handle_sigchld(int sig) { int status; pid_t pid; while ((pid = waitpid(-1, &status, WNOHANG)) > 0) { if (WIFEXITED(status)) { printf("reaped child %d, exit=%d\n", pid, WEXITSTATUS(status)); } else { printf("reaped child %d by signal=%d\n", pid, WTERMSIG(status)); } } } int main() { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = handle_sigchld; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART; sigaction(SIGCHLD, &sa, NULL); pid_t pid = fork(); if (pid == 0) { printf("child %d born\n", getpid()); sleep(1); return 0; } sleep(3); return 0; }

2.3 关于孤儿进程与被收养的常见误区

如果父进程先于子进程结束，子进程就变成孤儿进程。孤儿进程不会被丢掉，内核会让init这个进程（现在通常是子进程subreaper机制，但传统模型里就是 PID 为 1 的进程）收养它。收养之后，孤儿进程退出时，终止状态由 init 来回收，所以孤儿进程本身不会产生永久僵尸。

很多人把孤儿进程和僵尸进程搞混，我在这里彻底理一下：

• 僵尸进程：孩子死了，父亲不去收尸，尸体躺在那占着进程表
• 孤儿进程：父亲先死了，孩子被领养，孩子死的时候新父亲会收尸

还有一个subreaper机制值得提一句：如果你的程序是一个容器主进程，你可以用prctl(PR_SET_CHILD_SUBREAPER, 1)把自己标记为子收割者，这样某些孤儿会被你收养而不是直接升到 init，这在容器场景里控制子进程生命周期很重要。

3. 程序替换：exec 是“变形”不是“新开”

聊完进程怎么死、怎么被回收，接下来是本文的重头戏——程序替换。很多初学者会困惑：既然我能用fork创建新进程，为什么还需要exec系列函数？答案是fork创建出来的进程和父进程运行的是同一份代码，如果你要的是一个全新的程序（比如在 shell 里执行ls），就需要用exec把当前进程的地址空间、代码段、数据段全部替换成目标程序的内容。

一句话总结：fork是生娃，exec是换脑。换脑之后，进程号 PID 不变，但是跑的代码已经不是原来的了。

3.1 exec 家族函数六兄弟的功能与适用场景

Linux 下exec不是一个函数，而是一族函数，常见的六个如下：

带 p 的版本会去PATH环境变量里找可执行文件，所以execlp("ls", "ls", "-l", NULL)不需要写全路径。带 v 的还是带 l 的，区别在于参数是数组还是可变长列表。带 e 的版本可以自己指定完整的环境变量数组，这在需要低调清空环境变量的安全场景里很常用。

先看一个最常用的组合拳——fork配合execlp在子进程里启动新程序：

#include <unistd.h> #include <sys/wait.h> #include <stdio.h> #include <stdlib.h> int main() { pid_t pid = fork(); if (pid == 0) { execlp("ls", "ls", "-l", NULL); perror("execlp failed"); exit(127); } else { int status; waitpid(pid, &status, 0); printf("child finished\n"); } return 0; }

exec系列函数的返回值规则与常规函数完全不同：如果执行成功，它不会返回，因为原来的代码已经被替换掉了，没有地方可以“返回”；如果执行失败（比如文件不存在、没有执行权限、内核格式不对），它才返回 -1，你可以在exec调用之后接perror打印原因。

很多人写代码的时候忽略检查exec的返回值，这是个大坑。如果exec失败了你不管，子进程会继续往下执行原本的代码，跑出的行为完全不可预料。所以标准写法是：exec调用之后紧跟一个错误处理，然后exit(127)退出子进程。127 是 shell 的“找不到命令”惯例值，用它做失败状态，排查问题时语义清晰。

3.2 exec 之后代码去哪了：地址空间的全量替换

exec的内部过程可以粗暴理解成：内核把当前进程的虚拟内存区域全部释放掉，重新按目标可执行文件的段（代码段、数据段、BSS 段）建立映射，再按文件头里记录的入口地址设置 PC（程序计数器），然后从新入口开始运行。之前的栈、堆、全局变量全部推倒重来。

这带来一个很反直觉的行为：exec之前打开的文件描述符默认是继承的（不带FD_CLOEXEC标志的话），但堆里的数据、静态变量值全部没了。所以在exec之前如果你想给新程序传递一些参数，只能靠命令行参数、环境变量，或者显式通过文件描述符传递。这也是为什么很多命令行工具之间的数据传递要依赖管道、临时文件或者继承的文件描述符，而不是指望某块共享内存。

关于文件描述符，还有一个执行级特性叫 close-on-exec。如果你在open文件的时候传了O_CLOEXEC，或者用fcntl设置了FD_CLOEXEC，那么exec成功后这个 fd 会被自动关闭。这是防御性编程的关键——否则你在exec之前不小心打开的一个文件，会被新程序意外继承。

3.3 为什么用 fork+exec 而不是直接开新进程

你可能会问：为什么操作系统要用“先拷贝一份自己再替换”这种方式来启动新程序，而不是直接搞一个全新的进程？这得追溯到 Unix 的历史设计。fork天然支持了进程的创建，而且成本在写时拷贝（Copy-on-Write）机制的加持下，已经降得非常低：刚 fork 出来的子进程和父进程共享物理内存页，只有发生写入才复制。exec又负责把“共享着父进程内存”的子进程切换到全新的程序镜像，二者搭档既能复用创建进程的整套机制，又不需要给内核增加“直接加载可执行文件创建进程”的额外系统调用路径。

现代 Linux 上虽然也有posix_spawn这个更接近“直接创建”的函数，它内部依然会走类似 fork + exec 的路径，只是把大量细节封装好了。所以你在写程序的时候完全不用纠结性能问题，fork早已不是当年的傻拷贝了。

4. 综合实战：从创建到终止再到替换的完整演练

光讲理论不落地等于白学，这一章我用三个能直接编译运行的例子，把整条链路串起来。这三个例子从简单到进阶，覆盖了面试和工作中最核心的几个场景。

4.1 示例一：父进程精确回收指定子进程并解析退出码

第一个示例模拟一个比较现实的场景：父进程一次性创建三个子进程，每个子进程做不同的事，然后父进程需要逐一回收并打印每个子进程的退出状态。

#include <sys/wait.h> #include <stdio.h> #include <unistd.h> #include <stdlib.h> int main() { pid_t children[3]; for (int i = 0; i < 3; i++) { pid_t pid = fork(); if (pid == 0) { printf("child %d: my pid=%d, work %d\n", i, getpid(), i); sleep(1 + i); exit(10 + i); } children[i] = pid; } for (int i = 0; i < 3; i++) { int status; pid_t ret = waitpid(children[i], &status, 0); if (ret < 0) { perror("waitpid"); return 1; } if (WIFEXITED(status)) { printf("child pid=%d exit=%d\n", ret, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("child pid=%d killed by sig=%d\n", ret, WTERMSIG(status)); } } return 0; }

看到没，waitpid配合存储的子进程号数组，让父进程可以按顺序精确回收，这在多子进程服务里几乎就是标准操作。如果你用普通wait，一方面不知道回收的是谁，另一方面顺序也没有保证。

4.2 示例二：SIGCHLD 信号驱动回收与循环排空

第二个示例演示了如何在服务主进程里异步回收子进程。关键点在于：信号处理函数里printf不是异步信号安全的，严格生产环境应该用write或者只做waitpid。这里为了演示简洁我用了printf，日常写服务建议改成写日志或者只做回收不打印。

#include <signal.h> #include <sys/wait.h> #include <unistd.h> #include <stdio.h> #include <string.h> static void reap(int sig) { int status; pid_t pid; while ((pid = waitpid(-1, &status, WNOHANG)) > 0) { if (WIFEXITED(status)) { dprintf(1, "reaped %d, code=%d\n", pid, WEXITSTATUS(status)); } else { dprintf(1, "reaped %d, sig=%d\n", pid, WTERMSIG(status)); } } } int main() { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = reap; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART; sigaction(SIGCHLD, &sa, NULL); for (int i = 0; i < 5; i++) { pid_t pid = fork(); if (pid == 0) { printf("child %d working...\n", getpid()); sleep(1); exit(i); } } sleep(6); printf("main done\n"); return 0; }

注意我在信号处理回调里用的是dprintf而不是printf，因为printf的缓冲区操作在信号上下文里不安全，这个细节区分了很多“线上偶发崩溃”和“本地跑不出来”的问题。另外while循环排空僵尸是本例的灵魂，少了这个循环，在信号合并场景下必然残留僵尸进程。

4.3 示例三：用 exec 在子进程里执行外部命令并传递状态

第三个示例是 shell 程序核心机制的迷你版：解析用户输入，fork一个子进程去exec外部命令，父进程等待结果并返回。这里我刻意选择execvp而不是execlp，是为了演示参数数组在实际应用里的灵活性。

#include <unistd.h> #include <sys/wait.h> #include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char input[256]; while (1) { printf("myshell> "); fflush(stdout); if (fgets(input, sizeof(input), stdin) == NULL) { break; } input[strcspn(input, "\n")] = 0; if (strcmp(input, "exit") == 0) { break; } char *argv_list[32]; char *tok = strtok(input, " "); int i = 0; while (tok != NULL && i < 31) { argv_list[i++] = tok; tok = strtok(NULL, " "); } argv_list[i] = NULL; if (i == 0) { continue; } pid_t pid = fork(); if (pid == 0) { execvp(argv_list[0], argv_list); perror("exec failed"); exit(127); } else { int status; waitpid(pid, &status, 0); if (WIFEXITED(status)) { printf("exit code: %d\n", WEXITSTATUS(status)); } } } return 0; }

运行这个程序你会发现，ls、pwd、echo这些命令都能执行了，而且退出码被正确传递。这个迷你 shell 是我当年学习时亲手敲过的经典练习之一，做完它你基本就理解了 Unix 进程模型的核心回路。后续你可以给它加管道处理、重定向、环境变量设置，这就是一个真实 shell 的雏形。

5. 面试高频问题与避坑实录

5.1 面试高频问题速查

先整理几个在操作系统面试里出现频率极高的问题，这些题目围绕的就是我们今天聊的三个主题：

Q1：什么是僵尸进程？如何避免僵尸进程？

答：子进程先于父进程退出，父进程没有调用wait系列函数回收，子进程的 PCB 残留，进程表项不释放。避免措施有三种：父进程同步调用wait/waitpid；父进程注册SIGCHLD信号处理函数并在其中waitpid(-1, &status, WNOHANG)排空；父进程先退出让 init 收养孤儿。

Q2：exit与_exit区别？

答：exit是标准库函数，会先执行atexit注册的清理函数、刷新标准 I/O 缓冲区，再进入内核的exit_group系统调用；_exit直接进入内核，跳过所有用户态清理。fork之后子进程不建议调用exit而建议_exit，原因在于子进程可能执行过父进程遗留的atexit函数，可能引发重复清理。

实际上很多资料在“fork 之后到底该用 exit 还是 _exit”上有分歧，我的结论是：如果子进程只调用了exec或_exit，两者都没问题；如果子进程没调exec，就直接_exit更安全。

Q3：exec执行成功后还会返回吗？

答：不会。exec成功时当前进程的用户态代码和数据全部被替换，没有代码继续执行原逻辑。只有失败才会返回 -1。

Q4：孤儿进程和僵尸进程有什么区别？

答：孤儿是父进程先死，被 init 收养；僵尸是子进程先死，父进程没回收。孤儿不会持久占用进程表项，僵尸会。

5.2 实操中的典型坑与排查思路

坑一：waitpid返回 -1 还以为是子进程退出失败。waitpid返回 -1 有几种情况：没有子进程（ECHILD）、被信号中断（EINTR）、参数非法（EINVAL）。其中 EINTR 是最容易被忽略的。在设置了信号处理函数的程序里，wait可能被信号打断，如果你没有处理 EINTR，回收逻辑可能异常退出。解决方法是循环调用，判断 errno 是否为 EINTR 后继续waitpid。

坑二：SIGCHLD信号处理函数里调用printf导致死锁或数据竞争。信号处理函数会打断主流程的任意位置，如果主流程正好在malloc或者printf的临界区里，信号处理函数里再次调用这些函数可能会导致堆和缓冲区的状态错乱。轻则输出乱序，重则死锁崩溃。生产环境的处理手段只有一种：信号处理函数里只做异步安全的操作（write、waitpid、sigaction），把需要传递的信息写入管道或者自管道唤醒主循环。

我记得很清楚的另一个实战经验：曾经排查过线上一个服务，僵尸进程堆积到几百个，但是代码里明明写了SIGCHLD处理函数。后来发现是因为服务用第三方库自己注册了SIGCHLD，把我们的处理函数覆盖了。排查手段是cat /proc/<pid>/status看 SigBlk/SigIgn 相关位，或者在代码里多次注册后打印当前信号处理方式。这个“隐形覆盖”问题在日常开发里非常容易遇到。

坑三：exec之后程序行为异常但找不到原因。大概率是环境变量或者文件描述符泄漏问题。调试这类问题有个土办法：在执行exec前故意打印当前环境的几个关键变量，再对比新程序里的environ，看看是什么被污染了。另外可以用strace -f -e trace=execve跟踪整个系统调用序列，比人肉看代码高效得多。

坑四：写时复制带来的“假共享”错觉。fork之后父子进程共享物理内存，子进程exec新程序的一瞬间会释放掉所有共享页，这个代价虽然不低但可接受。如果你在fork之前创建了一个很大的内存区域（比如几百兆的缓存），子进程里又马上exec，这些内存会经历一次“共享 -> 释放”的过程，频繁fork+exec会带来明显的性能抖动。遇到这种情况，考虑用posix_spawn的POSIX_SPAWN_USEVFORK语义来规避不必要的页表复制。

5.3 一个容易混淆的补充：vfork 是不是已经废了

老书上讲到程序替换，必然会提到vfork。vfork设计初衷是：子进程创建后马上exec，那就没必要复制页表了，干脆父子共享地址空间，子进程exec之前父进程被挂起。这在没有写时拷贝的远古时代非常有用，但现代 Linux 已经有了完善的写时拷贝机制，fork后不立刻写的话，物理内存不会复制，vfork的优势基本被抹平。

vfork还有一个非常危险的历史包袱：子进程在exec之前如果修改了全局变量，修改会直接作用于父进程的地址空间。不少项目因为历史代码里用了vfork，出现诡异的“父进程数据被改”的问题。我的建议很简单：新代码一律用fork，不要用vfork，除非你明确知道自己要做什么。

6. 回看这条链路：为什么我把它们放一起学

我写这一篇系列文章的时候，刻意把进程终止、回收、替换放在同一个主题下讲，因为在真实的系统和面试场景里，这三个环节从来不会孤立出现。你看 shell 执行一条命令的完整链路：fork出子进程 -> 子进程里exec替换成目标程序 -> 子进程终止 -> shell 通过waitpid回收并获取退出码。中间任何一环出了问题，整个命令的执行结果都是错的。

比如服务端常见的“进程管理”组件，负责拉起一批 worker 进程，监控它们的存活状态，worker 突然退出时能感知到并重新拉起。这个组件内部做的事就是：fork+exec启动 worker，注册SIGCHLD处理回收，判断退出码决定是否重启。你把这篇文章讲的内容吃透了，再去看这类框架的源码，你会发现很多模式其实是相通的。

我个人在实际学习过程中的体会是：进程生命周期这部分知识，死记硬背函数签名没有意义，真正值钱的是理解“状态转移的因果链”。僵尸不是 bug，是设计的一部分；信号不可靠，所以要循环排空；exec不返回，失败要自己兜底。这些规律一旦你想通了，遇到新的进程管理问题就有自己的排查思路了。

最后分享一个小技巧：每次写完多进程程序，习惯性在终端里挂一个watch -n 1 'ps -eo pid,ppid,stat,comm | grep <你的程序名>'，实时观察进程状态变化。多看看进程如何从 S（睡眠）变成 Z（僵尸）再到消失，你对这套机制的体感会完全不一样。理论是地图，亲眼观察才是把地图变成肌肉记忆的过程。这篇就到这，下一篇我们聊聊进程间通信里最常用也最绕的管道机制。