想象你是一家大型餐厅的老板。厨房里主厨正在炒菜，但客人忽然爆炸性增长，一个人的手完全不够用。你决定再多招几个厨师。在操作系统的世界里，这一幕每秒钟都在上演——当一个服务需要处理并发请求时，它必须“扩招人手”，而扩招的唯一方式，就是 fork：把主厨的整个厨房原样复制一份给新厨师，新厨师再通过 exec 扔掉复制来的旧菜谱、换成自己的看家本领，最后在活干完时用 exit 办理“离职”——交还工牌、清理灶台，等主厨用 wait“回收”他的员工档案。这套流程环环相扣，任何一个环节出了问题，轻则资源泄漏，重则整个厨房停摆。这篇文章，就带你走进 UNIX 家族的后厨，看看 fork 怎么复印厨房、exec 怎么换菜谱、exit 怎么关门收工、僵尸进程又是怎么诞生的——以及最重要的，如何避免让一堆“离职未遂”的僵尸员工堵住你系统的血脉。

岗位关联

对 AI 从业者来说，理解 fork/exec 是看懂后台服务高并发架构、容器隔离与进程编排的必经之路——模型推理服务、数据流水线的每一个并发单元，底层都离不开这套生命周期管理。

目录
  1. 可视化演示
  2. fork创建进程
  3. 写时复制优化
  4. exec映像替换
  5. exit终止进程
  6. 僵尸进程
  7. wait回收进程
  8. 孤儿进程收养
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示Unix/Linux进程创建与终止的完整生命周期，包含fork复制、写时复制优化、exec加载和exit回收的动画演示。

本节配有交互动效（进入视口后自动加载，约 3KB）。

进程生命周期 fork复制父进程地址空间创建子进程 exec加载新程序镜像替换子进程 PID = fork() → exec() → exit() 五阶段揭示进程从创建到回收的内核流程

fork创建进程

UNIX 大饭店的扩张法则是“整店复印”。主厨想招新人，不需要去人才市场，直接把现在的厨房——包括每个灶台、每瓶酱料、正在烧的锅——原封不动复制一份，新厨师就从这份复制品里醒过来。更妙的是，新厨师醒来的瞬间，手里拿着一张和主厨完全一样的任务清单，唯一的不同是：清单右上角标注着“你是个新员工”。

这个“整店复印”在操作系统里就是 fork() 系统调用。它是 Unix/Linux 创建进程的唯一入口（内核线程除外）。fork 的行为一言以蔽之：复制当前进程，生成一个几乎一模一样的子进程。被复制的远不止代码，PCB、页表、文件描述符表、信号处理函数、环境变量、当前工作目录……统统复制一遍。

但 fork 最反直觉的地方在于它的返回值：调用一次，返回两次。父进程返回子进程的 PID，子进程返回 0。为什么？因为子进程不是从“系统调用入口”开始跑，而是从 fork 返回的那一行继续执行。这个返回值，就是父子进程在代码里的第一条分岔路——父进程拿到了子进程的“工号”，可以点名指挥；子进程拿到 0，进入“我是儿子”的分支逻辑。如果进程数达到内核上限或内存不足，fork 返回 -1，不创建任何子进程。

回到饭店：主厨按下复印键后，新厨师手里拿着和主厨一模一样的配方和工具，但工牌号（PID）是全新的。两人接下来各炒各的菜，互不相干——而这，仅仅是一个开始。

fork()={子进程 PID父进程中0子进程中−1创建失败\displaystyle \text{fork}()=\begin{cases}\text{子进程 PID} & \text{父进程中}\\ 0 & \text{子进程中}\\ -1 & \text{创建失败}\end{cases}
fork 是唯一一个“调用一次、返回两次”的系统调用，返回值是父子进程分道扬镳的路标。
  1. 子进程 PID内核为新进程分配唯一的 PID，在父进程的 fork 返回值里写入这个 PID，父进程通过它来“点名”子进程。
    父进程得到: pid=fork()\displaystyle \text{父进程得到: }\text{pid}=\text{fork}()
  2. 子进程返回 0子进程的 fork 返回值是 0，这是主厨刻在任务清单上的暗号——“看到 0 就知道自己是新来的”。
    子进程得到: pid=0\displaystyle \text{子进程得到: }\text{pid}=0
  3. 失败返回 -1当进程数达到上限或内存不足时，fork 返回 -1，此时不会创建子进程，errno 会被设置以说明原因。
    fork()=−1⇒创建失败, 无子进程\displaystyle \text{fork}()=-1 \Rightarrow \text{创建失败, 无子进程}

写时复制优化

等等，整店复印听着痛快，成本却吓人。一个饭店动辄几十张灶台、几百瓶酱料，每招一个厨师就全店复制一次，第二天就能把仓库搬空。UNIX 大饭店的精明算盘是：先不真复制，只给新厨师一张平面图，标明“这间厨房你和主厨共用”；他要真去碰哪块区域，才把那块区域单独复制下来。

这个机制就是写时复制（Copy-on-Write，COW）。它是 fork 能够做到“飞快”的核心秘密。历史上 fork 确实做过全量内存复制，但现代 Unix/Linux 早已用 COW 替换了这个朴素实现。fork 时，父子进程的页表都指向同一批物理页，并把这些页标记为只读。此后谁都没有感知异常——读取数据直接共享，零成本。

只有某一方尝试写入时，CPU 触发缺页异常（page fault），内核才在异常处理中分配新物理页、把旧页内容拷贝过去、更新页表，然后重新执行那条写入指令。这样，fork 的初始复杂度就从 O（物理内存大小） 降到了 O（页表项数），而真正的物理页拷贝量，只等于进程实际写入的页数。一个典型的场景是：fork 之后立刻 exec——子进程压根没写几个页，整个 fork 的代价几乎可以忽略。

新厨师拿着平面图在厨房里转悠，和主厨共享一切，直到他真要挪动某瓶酱料——那一瞬间，这瓶酱料才被复制到他自己的小推车上。省下的时间与空间，就变成了 fork 的闪电速度。

Tfork=O(页表项),实际拷贝页数=O(被写入页)\displaystyle T_{\text{fork}}=O(\text{页表项}) ,\quad \text{实际拷贝页数}=O(\text{被写入页})
写时复制的核心思想：能共享就先共享，等真要改动的那一刻，再为改动付费。
  1. O（页表项）fork 初期只复制页表目录与页表项，页表规模远小于物理内存，所以 fork 瞬间就能完成。
    Tfork=O(PTE 数量)\displaystyle T_{\text{fork}}=O(\text{PTE 数量})
  2. 被写入页只有写操作触发的页才会真正复制，读共享页始终零拷贝。
    copy(p)  ⟺  p∈write-set\displaystyle \text{copy}(p) \iff p \in \text{write-set}
  3. 两者差异这正是 COW 让“创建进程”从重量级操作变成轻量操作的原因——内存越大，省得越多。
    naive: O(M)⟶COW: O(PTE)\displaystyle \text{naive: } O(M) \quad \longrightarrow \quad \text{COW: } O(\text{PTE})

exec映像替换

可是平面图终究解决不了另一个问题：新厨师复制来的菜谱，是主厨的拿手菜，不是自己的招牌菜。他必须把这本菜谱整个扔掉，换上自己带来的新菜谱，才能做出自己的味道。扔旧菜谱、换新菜谱的动作，在 UNIX 里就是 exec 系列系统调用。

exec 做的事，是用一个新程序的“映像”整体替换当前进程的内存映像。注意一个关键点：exec 并不创建新进程！它只是在已有进程的躯壳里换灵魂。execve() 的流程是：解析新程序文件路径 → 读取可执行文件头 → 映射代码段和数据段 → 重建堆和栈 → 设置新的程序入口地址。替换过后，进程的 PID、文件描述符、环境变量、工作目录等“身份信息”一律保留。

因为代码已经被新程序替代，旧程序再无返回的机会——exec 成功时永远不会返回，只有失败时才带着 -1 回到旧的调用点。这个“成功即永别”的语义，让 exec 成为操作系统里最决绝的系统调用之一。Shell 执行一条外部命令时，就是先 fork 出一个子进程，再在子进程里 exec 那个命令程序。

新厨师把旧菜谱扔进垃圾桶的那一刻，这间厨房就只属于他的招牌菜了。他不再记得主厨的任何拿手菜（旧代码），但他还是原来那个工牌号（PID）——这是 exec 和 fork 最本质的区别。

execve(path,argv,envp)→{不返回成功−1失败\displaystyle \text{execve}(\text{path},\text{argv},\text{envp})\rightarrow\begin{cases}\text{不返回} & \text{成功}\\ -1 & \text{失败}\end{cases}
exec 成功就不回来了，这是它与“创建新进程”最本质的区别——厨子还是那个厨子，只是换了拿手菜。
  1. path新程序文件在文件系统中的路径，内核从这里加载代码段与数据段。
    path→文件系统→内存映像\displaystyle \text{path} \to \text{文件系统} \to \text{内存映像}
  2. argv 与 envp命令行参数与环境变量，新程序的 main 函数通过它们接收外界信息。
    main(argc,argv),environ\displaystyle \text{main}(\text{argc}, \text{argv}), \quad \text{environ}
  3. 成功不返回代码段已被新程序取代，旧程序的下一行指令已不存在；只有失败时旧映像才保留，带着错误码返回。
    execve⇒entry←new_entry;no return\displaystyle \text{execve} \Rightarrow \text{entry} \leftarrow \text{new\_entry}; \quad \text{no return}

exit终止进程

菜总有做完的时候。到了打烊时间，厨师要做的不是甩手走人，而是按规矩关掉灶火（释放 CPU 与内存）、清理灶台（释放文件句柄）、交回工牌（通知父进程），最后在离职单上签下自己的名字——这一步，就是 exit。

进程的终止远不止“结束”两个字。exit() 在用户态和内核态各有一摊事要做。在用户态，C 库的 exit() 会依次执行 atexit() 注册的清理函数（比如关闭日志文件、释放临时资源），并刷新所有 stdio 缓冲区——这保证了 printf 的输出不会在进程消失时丢失。随后，真正进入内核的 exit_group() 系统调用。

在内核里，exit_group() 会释放 mm_struct（地址空间）、files_struct（文件描述符表）、fs_struct 等资源，把该还的都还给系统。收拾干净后，向父进程发送 SIGCHLD 信号，通知“你的子进程走了”。但此时进程并未完全消失——它变成一个僵尸（Zombie），在进程表里保留着最后一丝气息：PID、退出状态、计时信息。为什么不能立刻删掉？因为父进程可能还想知道“这孩子究竟是正常下班还是闯了祸才走的”。

厨师离职流程走完一半——人不在了（用户态资源没了），但工牌和档案还挂在人事部（进程表）里，等待着最终一步：wait。

exit(code)→用户态atexit+fflush⏟清理收尾→内核exit_group→SIGCHLD→Z⏟转型僵尸\displaystyle \text{exit}(\text{code})\xrightarrow{\text{用户态}}\underbrace{\text{atexit}+\text{fflush}}_{\text{清理收尾}}\xrightarrow{\text{内核}}\underbrace{\text{exit\_group}\rightarrow\text{SIGCHLD}\rightarrow Z}_{\text{转型僵尸}}
exit 不是进程的终点，而是僵尸状态的起点——真正的主角 wait 还没上场。
  1. code退出码，0 表示正常，非 0 表示异常；父进程 wait 后在 status 里拿到它。
    exit(0) 正常exit(非0) 异常\displaystyle \text{exit}(0) \ \text{正常} \quad \text{exit}(\text{非}0) \ \text{异常}
  2. atexit + fflushC 库的善后动作，把用户态该关的账户都关掉，缓冲区里的数据落盘。
    atexit(handler);fflush(stdout)\displaystyle \text{atexit}(\text{handler}); \quad \text{fflush}(\text{stdout})
  3. exit_group + SIGCHLD + Z内核把剩余资源回收，发送信号通知父进程，进程状态变为 Z。
    state←Z,SIGCHLD→parent\displaystyle \text{state} \leftarrow Z, \quad \text{SIGCHLD} \to \text{parent}

僵尸进程

假如人事部（父进程）忙着炒别的菜，一直没去办离职手续呢？厨师已经走了，可他的工牌还挂在墙上，档案还躺在抽屉里，员工名册上他的名字后面写着“离职待办”。在 UNIX 大饭店里，这种人叫“僵尸员工”——占着工位，不干活，也不许别人用他的工位。对应到操作系统，这就是僵尸进程（Zombie Process）。

进程退出后，内核为了保留退出状态给父进程读取，不能把 PCB（进程控制块）完全销毁，至少要保留 PID 和退出码。只有当父进程调用 wait() 把这个状态“读”走，PCB 才能真正被释放。如果父进程迟迟不 wait，僵尸就持续残留在进程表里——它不消耗 CPU、不占内存，但它占着一个 PID 名额。

而系统的 PID 数量是有限的（默认 pid_max 通常为 32768）。一个长期运转却从不回收子进程的服务器，PID 会被僵尸逐渐耗尽，最终导致 fork 返回 -1、新进程无法创建。这就是为什么“僵尸进程无害”是一个危险误解：单个僵尸确实无害，一群无人回收的僵尸，能把整个系统的造血能力堵死。

僵尸员工的工牌一天不摘，新员工（新进程）就一天拿不到这个工号。所以高效的饭店，一定要有个勤快的人事部——这就是 wait 的职责。

state=Z  ⟺  进程已 exit∧父进程未 wait\displaystyle \text{state}=Z \iff \text{进程已 exit} \land \text{父进程未 wait}
僵尸进程是一笔“挂账”——人不在了，账还挂着，等父进程来销账。
  1. 已 exit子进程已经执行完资源释放，只剩 PCB 中的最小信息。
    PCBzombie={PID,exit_code,times}\displaystyle \text{PCB}_{\text{zombie}} = \{\text{PID}, \text{exit\_code}, \text{times}\}
  2. 未 wait父进程还没有调用 wait/waitpid 来读取退出状态。
    ¬wait(child)\displaystyle \neg \text{wait}(\text{child})
  3. 状态 Z进程表里的状态标记为 Z，表示僵尸态，等待最终回收。
    task_state=TASK_ZOMBIE\displaystyle \text{task\_state} = \text{TASK\_ZOMBIE}

wait回收进程

人事部终于忙完了，拿起离职清单逐项核对：摘工牌、归档档案、从员工名册上划掉名字。这一整套动作，在操作系统里就是 wait() 和 waitpid()。wait 是僵尸进程的“最终归宿”——父进程调用它之后，内核把子进程的退出状态写入指定内存，然后释放 PCB，僵尸彻底消失。

wait() 的行为很朴素：如果没有任何子进程退出，它就阻塞挂起，直到某个子进程退出才返回；waitpid() 则更精确，可以指定等待某个 PID，也可以用 WNOHANG 选项实现非阻塞轮询——“我来看一眼，要是还没办完就先不等了”。一个循环 fork 处理任务的服务器，必须在每个任务结束后调用 wait 回收，否则就是每个月都在积累一批“离职待办”。

退出状态是一个 16 位的整数，包含退出码和终止原因，必须用宏来解码：WIFEXITED 判断进程是否正常退出，WEXITSTATUS 取出低 8 位的退出码。注意，wait 一次只能回收一个子进程，要按照子进程数量调用相应次数的 wait——这就像人事清单要一个一个地划名。

离职手续办完，工牌摘掉、档案归档、名册划名，僵尸员工终于“入土为安”。饭店的员工池又腾出了一个工号，可以招下一个厨师了。

waitpid(pid,&s,0)={pid回收成功−1无子进程,WEXITSTATUS(s)=退出码\displaystyle \text{waitpid}(\text{pid},\&s,0)=\begin{cases}\text{pid} & \text{回收成功}\\ -1 & \text{无子进程}\end{cases},\quad \text{WEXITSTATUS}(s)=\text{退出码}
wait 是 fo的“最终归宿”——僵尸进程只有被 wait 之后才真正从系统中消失。
  1. pid-1 表示任意子进程，>0 表示仅等待指定的 PID，0 表示等待同进程组的任一子进程。
    pid=−1⇒任意子进程\displaystyle \text{pid}=-1 \Rightarrow \text{任意子进程}
  2. &s输出参数，保存包含退出状态的整数，必须用 WIFEXITED / WEXITSTATUS 等宏解码。
    s=exit_code∣term_signal≪8\displaystyle s = \text{exit\_code} \mid \text{term\_signal} \ll 8
  3. WEXITSTATUS(s)从状态字中提取退出码，范围 0～255——这才是子进程留给父进程的“遗言”。
    exit_code=(s≫8)&0xFF\displaystyle \text{exit\_code} = (s \gg 8) \& 0xFF

孤儿进程收养

有一种更极端的情况：主厨（父进程）自己干得不开心，先辞职了。他手下的新厨师顿时成了没爹没娘的孤儿。但 UNIX 大饭店有条铁律：每个员工都必须挂在名册里——孤儿厨师会被大老板（init 进程）自动收编到自己名下，由大老板统一办离职手续。

父进程先于子进程退出时，子进程被称为孤儿进程（Orphan Process）。内核不会让任何进程失去父进程——它会将孤儿的父进程字段重写为 PID=1 的 init 进程，这个动作叫 reparent（重新寄养）。init 是系统启动后的第一个用户态进程，它的职责之一就是不断 wait() 回收所有被收养的孤儿。现代 Linux 还引入了 subreaper 机制，允许中间进程充当“子代理家长”，避免所有孤儿都涌向 init。

把一个进程完整的生命周期串起来看：fork 给了它生命，exec 给了它灵魂，exit 结束了它的工作，wait 为它办完最后的葬礼——四步缺一不可。每一秒，成千上万的进程都在这套流程里诞生、工作、谢幕。理解这条生命周期链，是理解 Linux 进程世界最重要的一条主线。

孤儿厨师被大老板收编后，终究会有一场体面的离职。从 fork 到 wait，每一个进程都在这条生命周期链上走过一遭——这也正是本篇文章想让你牢牢记住的完整图景。

父进程退出⇒reparent(子,init),PPID←1\displaystyle \text{父进程退出}\Rightarrow \text{reparent}(\text{子}, \text{init}),\quad \text{PPID}\leftarrow 1
孤儿进程不是没人管的野孩子——init 是操作系统里最负责任的“大老板”，永远会收尾。
  1. reparent（子，init）内核把子进程的父进程指针改为 init，完成重新寄养。
    task_parent←init_task\displaystyle \text{task\_parent} \leftarrow \text{init\_task}
  2. PPID ← 1孤儿进程的父 PID 变为 1，即 init 进程的 PID。
    getppid()=1\displaystyle \text{getppid}() = 1
  3. init 循环 waitinit 不断 wait 回收孤儿，避免僵尸堆积——大老板总是在默默善后。
    while(1) wait_pid(−1,&s,0);\displaystyle \text{while(1) }\text{wait\_pid}(-1,\&s,0);

AI 应用场景

Web 服务器的高并发多进程模型

阶段：模型部署与服务

解决的问题：单个进程只能串行处理请求，推理服务面对高并发时吞吐量直接撞墙。Nginx 的 master 进程启动后 fork 出多个 worker 进程，每个 worker 接管一部分连接；由于写时复制，fork 近乎零成本。如果某个 worker 崩溃，master 立即 fork 一个新的 worker 顶替，就像主厨的厨房被完整复制给了新厨师。

具体案例：在 GPU 服务器上部署基于 Flask 的 AI 推理服务，前端用 Nginx 做负载均衡。master 进程 fork 出 4 个 worker，因为 COW 共享物理页，同一个大模型的权重在内存里只占一份，四个 worker 并行处理请求，服务吞吐量提升近 4 倍。

容器运行时的进程启动

阶段：分布式训练环境搭建

解决的问题：容器与宿主机的隔离需要高效、轻量的进程创建方式。containerd 这类容器运行时启动容器内进程时，底层先 fork 一个进程，再通过 exec 加载容器内的 init 程序和业务命令，完整复刻了“复制厨房 + 换菜谱”的组合流程。

具体案例：在 Kubernetes 上启动一个 PyTorch 分布式训练任务时，kubelet 让 containerd fork 出 pause 进程作为 Pod 的“根进程”，再在子进程中 exec 运行训练入口脚本。训练进程的 PID 就是 fork 时分配的那个，从未改变。

数据流水线的任务调度与回收

阶段：数据流水线调度

解决的问题：AI 数据流水线经常要并发跑几十个清洗、转换任务，每个任务都是一个子进程。调度器负责 fork 子进程执行任务，任务结束后及时 wait 回收，避免僵尸堆积拖垮调度器。

具体案例：Airflow 调度器为每个 DAG 任务 fork 子进程执行 Python 脚本，执行完毕后调用 waitpid 获取退出码来判断任务成败。若某个任务变成了僵尸，调度器通过监控主动补充一次 wait 完成回收，保证 PID 不会被耗尽。

Python 演示

python57 行
import osimport sysimport time def demo_normal_cycle():    """演示: fork + wait 的正常生命周期"""    pid = os.fork()    if pid == 0:        # 子进程分支        print("[子进程] PID={} 开始干活".format(os.getpid()))        sys.stdout.flush()        time.sleep(0.5)        print("[子进程] 调用 exit(42) 退出")        sys.stdout.flush()        os._exit(42)    # 父进程分支    print("[父进程] 创建子进程 PID={}".format(pid))    waited_pid, status = os.waitpid(pid, 0)    if os.WIFEXITED(status):        code = os.WEXITSTATUS(status)        print("[父进程] 回收子进程 {}, 退出码={}".format(waited_pid, code)) def demo_zombie():    """演示: 不回收导致的僵尸进程"""    pid = os.fork()    if pid == 0:        print("[子进程-僵尸演示] 我现在退出")        sys.stdout.flush()        os._exit(7)    time.sleep(0.6)    if os.path.isdir("/proc"):        with open("/proc/{}/stat".format(pid)) as f:            state = f.read().split()[2]        print("[父进程] 子进程 {} 状态={} (Z表示僵尸)".format(pid, state))    else:        print("[父进程] 平台无 /proc, 跳过状态读取")    os.waitpid(pid, 0)    print("[父进程] 补一次 wait, 僵尸被回收") def demo_exec():    """演示: exec 替换当前进程映像"""    pid = os.fork()    if pid == 0:        print("[子进程] 即将 exec 执行 /bin/echo")        sys.stdout.flush()        os.execv("/bin/echo", ["/bin/echo", "[exec] 你好, 我是新程序"])        print("这行永远不会执行")    os.waitpid(pid, 0)    print("[父进程] exec 演示结束") if __name__ == "__main__":    if not hasattr(os, "fork"):        print("当前环境不支持 os.fork, 请在 Linux/macOS 运行")        sys.exit(0)    demo_normal_cycle()    demo_zombie()    demo_exec()
目的：用 Python 的 os 模块完整演示 fork 生子、_exit 终止、wait 回收以及 exec 映像替换，并在 Linux 上通过 /proc 观察僵尸状态。
  1. pid = os.fork()一次性 fork，父进程得到子进程 PID，子进程得到 0，用 if 分支区分两条人生。
  2. os._exit(42)绕过 C 库缓冲直接发起 exit 系统调用，刻意避开 sys.exit 的清理逻辑。
  3. waited_pid, status = os.waitpid(pid, 0)父进程阻塞等待并回收指定子进程。
  4. os.WIFEXITED(status)判断子进程是否正常退出，避免误读信号终止的状态。
  5. os.WEXITSTATUS(status)从状态字中解码出低 8 位退出码。
  6. os.waitpid(pid, os.WNOHANG)非阻塞尝试回收，返回值若为 (0,0) 说明子进程仍在运行。
  7. os.execv("/bin/echo", ...)直接在当前进程内替换映像，后面的 print 永远不会执行。
  8. sys.stdout.flush()exec 前刷新缓冲区，否则缓冲中的输出会随映像替换一起消失。
  9. if not hasattr(os, "fork")Windows 没有 os.fork，提前提示平台限制。

常见误区

误区我一直以为 fork 非常重，因为它要把父进程的所有物理内存原样拷贝一份给子进程，内存越大 fork 越慢。

正解现代 Unix/Linux 早就用写时复制（COW）替换了全量复制。fork 时父子进程共享物理页并标记只读，只有写入时才真正复制那一个页。就像饭店招新厨师时只给一张共用平面图，他碰哪块才复制哪块，而不是真的把整个厨房重新装修一遍。

为何常见：教材为了讲清概念，常先介绍朴素的“全量复制”再讲 COW 优化，读者只记住了前半句。

误区我觉得 exec 和 fork 一样，都是在系统里再开一个进程来跑新程序。

正解exec 不创建新进程，它只是用新程序替换当前进程的代码段、数据段和堆栈。进程的 PID、文件描述符等身份信息全部保留。换个比喻：fork 是招新人，exec 是给同一个厨子换菜谱——工牌号不变。

为何常见：从 Shell 的角度看，执行一条命令总是“先出现新程序”，很容易误以为背后新建了一个进程。

误区僵尸进程既然“活着”，肯定还在跑代码、占内存，会把服务器拖垮。

正解僵尸进程不运行任何代码，不占 CPU、不占内存，只保留 PCB 里的 PID 和退出状态。它真正的危害是占着 PID 名额，长期堆积会让系统无 PID 可用，fork 返回 -1。这就像离职员工不占办公桌，但工号一直被占用。

为何常见：“僵尸”这个名字太有画面感，让人下意识联想到还在活动的生物。

误区我在代码里调用 exit() 后，以为操作系统马上就把这个进程从进程表里删掉了。

正解exit 只是释放了用户态和大部分内核资源，进程会转入 Z（僵尸）状态，在进程表里保留一份“待领取的退出状态”。只有父进程调用 wait/waitpid 后，最后这点 PCB 才会被释放。exit 是谢幕，wait 才是落幕。

为何常见：应用层的体验是“exit 后进程就没了”，看不到内核态还有一段僵尸过渡期。

误区我以为父进程调用一次 wait，就能把所有的子进程都清理干净。

正解wait 一次只能回收一个子进程，而且只能回收自己的直接子进程。要回收多个子进程，就得调用多次 wait/waitpid。如果父进程一直不 wait，子进程就会一直挂在僵尸状态——人事清单必须一个一个划名，不能一笔划掉一整页。

为何常见：把 wait 想象成“一键清理”了，忽略了它面向单个子进程的设计语义。

面试题

Q1. 在 Linux 中 fork 成功后，子进程拿到的返回值是？

单选题 · easy

  • A.子进程自己的 PID
  • B.0
  • C.父进程的 PID← 正确答案
  • D.-1
  • E.fork 时父子进程物理页共享且标记为只读
  • F.任一进程写入共享页时，内核会分配新物理页并复制
  • G.每次 fork 都必须完整复制所有物理内存
  • H.读操作不会触发物理页复制
  • I.exec 会创建一个新进程
  • J.exec 成功后返回 0
  • K.exec 用新程序替换当前进程映像，PID 保持不变
  • L.exec 失败时没有任何返回值

答案：C。exec 只是在当前进程的躯壳里换灵魂，不创建新进程，PID 不变；成功时旧代码已消失，永不返回；失败时才返回 -1。把 exec 当“新建进程”是经典认知错误。

Q2. 关于 exit 与僵尸进程的关系，正确的是？

多选题 · mid

  • A.exit 后进程立即从系统彻底消失
  • B.exit 后进程进入 Z（僵尸）状态← 正确答案
  • C.父进程 wait 后进程才完全消失← 正确答案
  • D.exit 会向父进程发送 SIGCHLD 信号← 正确答案

答案：BCD。exit 释放资源后进程转入僵尸态，发送 SIGCHLD 通知父进程，必须等父进程 wait 后才彻底消失。A 忽略了僵尸过渡态，“立即消失”是应用层错觉。

Q3. 僵尸进程的主要危害是什么？

单选题 · easy

  • A.疯狂消耗 CPU 时间片
  • B.大量占用物理内存
  • C.长期占用 PID，堆积后可能耗尽 PID 空间← 正确答案
  • D.阻塞所有系统调用的执行

答案：C。僵尸进程不运行、不占 CPU 和内存，只保留 PID 和退出状态。真正危险的是它占用 PID 名额，堆积到上限会让 fork 失败。C 准确点出了这个看似温和却致命的危害。

Q4. 关于 wait 和 waitpid，下列说法正确的是？

多选题 · hard

  • A.wait 一次可以回收所有子进程
  • B.waitpid 可以指定等待某个具体的子进程← 正确答案
  • C.使用 WNOHANG 选项可以让 waitpid 非阻塞地轮询← 正确答案
  • D.父进程只能 wait 自己的直接子进程← 正确答案

答案：BCD。wait 一次只能回收一个子进程，A 是常见误解；waitpid 支持指定 PID、支持 WNOHANG 非阻塞模式；父进程只能回收自己的直接子进程（孤儿由 init 收养）。B、C、D 均正确。

Q5. 当父进程先于子进程退出时，子进程会被谁收养？

单选题 · easy

  • A.内核中的一个内核线程
  • B.最近的兄弟进程
  • C.init 进程（PID=1）← 正确答案
  • D.任意空闲进程

答案：C。内核会把孤儿进程的父进程指针重写为 init 进程（PID=1），这个动作叫 reparent。init 会循环调用 wait 回收这些孤儿，保证它们不被系统遗忘。

Q6. 以下哪些是 fork 复制给子进程的内容？

多选题 · mid

  • A.页表← 正确答案
  • B.文件描述符表← 正确答案
  • C.信号处理函数← 正确答案
  • D.进程 PID

答案：ABC。fork 复制 PCB、页表、文件描述符表、信号处理等几乎全部进程属性，但 PID 是新分配的，不会被复制。D 恰恰是 fork 后唯一“不同”的身份标识。

Q7. execve 成功加载新程序后，CPU 下一条执行的指令位于哪里？

单选题 · extreme

  • A.旧程序 main 函数的下一行
  • B.新程序文件的入口点← 正确答案
  • C.fork 返回路径的用户态代码
  • D.内核的 wait 路径

答案：B。execve 成功时，旧程序的代码段已被新程序整体替换，控制流从新程序文件头指定的入口地址开始执行，因此绝不会回到旧程序或 fork 的返回路径；D 是与 exec 无关的系统调用。A、C 都依赖旧映像仍然存在，而它已经被覆盖。

Q8. fork 返回 -1 表示什么？

单选题 · mid

  • A.子进程创建成功但父进程出错
  • B.创建失败，没有产生子进程← 正确答案
  • C.子进程已经退出并变成僵尸
  • D.表示当前进程是子进程

答案：B。fork 返回 -1 表示创建失败，不会产生子进程，常见原因是进程数达到上限或内存不足。若子进程已创建，父进程的返回值一定是大于 0 的子 PID，而不是 -1。