《从零入门Linux系统篇（十九）：进程篇·三——僵尸进程与孤儿进程：深入理解进程退出与回收机制》

在上一篇文章中，我们已经认识了Linux中的进程状态，知道一个进程并不是从创建到结束始终保持同一种状态。它会运行、睡眠、阻塞，也可能被暂停。更重要的是，进程的生命周期并不会随着“代码执行结束”就简单画上句号。

当一个子进程退出，而父进程迟迟没有处理它的退出信息时，会发生什么？

它可能变成一个看起来已经“死掉”，却又没有彻底消失的进程——僵尸进程。

反过来，如果父进程先一步退出，而子进程还在继续运行，又会发生什么？

这时，子进程就会成为孤儿进程，并被系统重新接管。

乍一看，僵尸和孤儿听起来像两个有点吓人的名字，但它们其实描述的是 Linux 进程生命周期中非常典型的两种状态。一个涉及子进程退出后的资源回收，另一个涉及父子关系变化后的进程接管。

本文就从这两个特殊进程出发，带你继续往进程生命周期的深处走一层：为什么进程退出后还会留下痕迹？这些信息到底存在哪里？为什么1号进程会主动“收养”孤儿？这些看似奇怪的现象，背后其实都有一套严谨的内核机制。

目录

一、僵尸进程（Zombie Process）

1.1 什么是僵尸进程？

1.1.1 僵尸进程的定义与产生原因

1.1.2 子进程退出后，退出信息保存在哪里？

1.2 僵尸进程的危害——为什么会占用系统资源？

1.2.1 僵尸进程为什么会持续存在？

1.2.2 进程退出后，所谓的“内存泄漏”还存在吗？

1.3 僵尸进程实战——观察与模拟Z状态

1.3.1 编写僵尸进程模拟程序

1.3.2 使用命令行监控并识别Z状态

1.4 深入拓展——内核对象分配与SLAB技术

1.4.1 什么是SLAB？

1.4.2 内核数据结构的对象缓存机制

二、孤儿进程（Orphan Process）

2.1 什么是孤儿进程？

2.1.1 孤儿进程的定义与产生原因

2.1.2 谁来“托底”？——一号进程的领养机制

2.1.3 认识 1 号进程——systemd

2.2 孤儿进程实战——观察与模拟验证

2.2.1 编写孤儿进程模拟程序

2.2.2 命令行监控与进程关系分析

2.3 两个容易混淆的进程细节

2.3.1 父进程退出后，为什么自己不会变成孤儿进程？

2.3.2 前台进程与后台进程是如何发生变化的？

一、僵尸进程（Zombie Process）

在Linux系统里，一个进程的代码跑完了，绝不意味着它的生命就此画上句号。恰恰相反，子进程退出后会先踏入一个特殊的过渡地带——僵尸状态（Z状态）。此时的它，代码已经释放，数据已经消失，唯独那张PCB户口本还孤零零地悬在系统的进程表里，等着有人来料理后事。这个“死而不僵”的存在，就是我们今天要拆开的第一个话题。

1.1 什么是僵尸进程？

想象这样一个场景：你走在路上，一个人突然从你身边冲过去，紧接着“咚”的一声，摔在地上，猝死了。此刻，他虽然已经没有了生命体征，但因为死因不明，他的遗体和随身物品（对应子进程的task_struct、退出码和退出信号）必须原封不动地留在原地，谁也不能擅自收尸。这个“躺着等人来查”的阶段，就是僵尸状态。

直到你报警，警察赶到现场，拍照、翻看口袋、登记身份信息、查明死因，一条条记录完毕（对应父进程调用waitpid获取子进程的退出状态），这才挥手让救护车把遗体拉走，火化入殓。直到这一刻，死者在这个世界上留下的最后痕迹才被彻底抹去，真正进入“死亡状态（X状态）”。

在Linux里，子进程退出的这套流程跟这个场景如出一辙：代码跑完了，进程死了，但PCB没被回收，它就成了僵尸。这些僵尸飘在进程表里，不干活、不占内存，只是占着一行记录，等着父进程来“认尸”。如果父进程一直不来，它们就会一直挂在那儿，越长越多。这就是僵尸进程的全部秘密。

1.1.1 僵尸进程的定义与产生原因

我们创建子进程的初衷，说白了就是让它去替我们完成某个任务。任务干完了，结果怎么样？成功、失败、还是半路崩了？父进程必须有个交代。

于是，当子进程退出时，内核做了一件很干脆的事：把它占用的代码段、数据段全部回收，内存一个字节都不留。但唯独那张PCB（task_struct），子进程的户口本被故意扣了下来，暂时留在内核里。这里面藏着一个非常核心的结论：

你的代码和数据可以释放，但你的PCB不能走！

为什么？因为PCB里记着子进程的退出码、退出信号、运行统计这些“临终遗言”。如果内核把这些信息一并抹了，父进程就再也查不到子进程到底怎么死的。所以，保持Z状态，本质上就是给父进程留一个窗口，让它有机会来读取子进程退出时的那些关键信息。读完，内核才会把PCB也收走，僵尸才真正灰飞烟灭。

1.1.2 子进程退出后，退出信息保存在哪里？

僵尸进程的“临终遗言”，就刻在它那张PCB户口本的几个专属字段里。Linux内核的task_struct结构体里，专门划出了几个成员来记录进程的退出状态：

struct task_struct { // ... long exit_state; // 进程的退出状态（如 EXIT_ZOMBIE、EXIT_DEAD） int exit_code; // 退出数字（比如 exit(0) 里的那个 0） int exit_signal; // 退出信号（如果它是被信号干掉的，这里记下信号编号） // ... };

当子进程一脚踏进僵尸状态时，内核会把它的exit_state标成EXIT_ZOMBIE，然后把退出码和退出信号规规矩矩地填进对应字段。从此，这个子进程就只剩这张户口本还活着，数据全是“临终口供”。

父进程要做的，就是调用wait()或waitpid()系统调用（这两个接口我们后面讲进程等待时会专门细说），从子进程的task_struct里把exit_code和exit_signal读出来。读完，内核才会把这张PCB收走，僵尸才算真正入土为安。换句话说，僵尸进程的PCB就是一个临时档案袋，父进程不拆开看，它就永远在系统里悬着。

1.2 僵尸进程的危害——为什么会占用系统资源？

1.2.1 僵尸进程为什么会持续存在？

如果父进程自己忙得焦头烂额，或者干脆当甩手掌柜，不关心、不回收、不读取子进程的退出信息那么子进程的Z状态就会一直悬在那儿，没人收尸。问题就出在这里。子进程的用户空间内存（代码、数据、堆栈）确实被释放得干干净净，但它的task_struct还牢牢占着内核空间里的一块物理内存。千万别小看这个结构体，它里面塞了上百个字段，是一个实打实的内存大户。

如果一个父进程不停地fork创建子进程，子进程跑完就退，父进程却从不调用wait去回收，那么这些僵尸的task_struct就会在内核空间里越堆越多。一个子进程留一张户口本，十个留十张，一万个就留一万张，每一张都是货真价实的内核内存开销。

这就是典型的内核内存泄漏。你的程序会变得越用越卡，系统资源被这些“活死人”一口一口啃掉。更可怕的是，这种泄漏不是发生在用户态，你没法靠重启自己的程序彻底解决，得把那些僵尸全部清理掉，内存才能吐出来。所以，僵尸进程不是闹着玩的，它是会真实拖垮系统的隐患。

1.2.2 进程退出后，所谓的“内存泄漏”还存在吗？

分两种情况看，答案截然不同。

• 子进程自己在用户空间申请的内存（比如malloc出来的那些）：不用担心。子进程一退出，操作系统会把它整个用户空间的内存全部强制回收，一个字节都不会剩。这部分内存泄漏的风险为零。
• Z状态残留的内核task_struct：这才是真正的麻烦。只要父进程不退出、不调用wait回收，这张户口本就永远占用着内核内存。它不随子进程的退出而消失，反而会一直悬在那里，直到父进程亲自来收尸。

更要命的是常驻内存的进程。像Nginx、数据库这类服务器后台服务，一跑就是几个月甚至几年。如果它们在工作过程中时不时fork出子进程，子进程退出后又忘了回收，每漏一个，内核里就多一具僵尸。日积月累，这些僵尸会一点点蚕食内核内存，最终可能把整个系统的内存啃到枯竭，直接导致服务器崩溃。

所以结论很清晰：用户空间的内存泄漏会随进程退出而终结，但僵尸进程造成的内核内存泄漏，只要父进程还活着，就永远不会自动消失。处理僵尸进程，是每个长期运行的服务程序都绕不开的必修课。

1.3 僵尸进程实战——观察与模拟Z状态

1.3.1 编写僵尸进程模拟程序

光靠脑补不够，我们直接写一段C++程序，把“子进程先退、父进程甩手不管”的场面完整复现出来。

#include <iostream> #include <unistd.h> #include <sys/types.h> #include <cstdlib> int main() { pid_t id = fork(); if (id < 0) { std::cerr << "fork error" << std::endl; return 1; } else if (id == 0) { // 子进程：只活 5 秒，然后就地去世 int count = 5; while (count--) { std::cout << "我是子进程，PID: " << getpid() << ", 剩余寿命: " << count << "s" << std::endl; sleep(1); } std::cout << "子进程已退出，进入僵尸状态..." << std::endl; exit(0); } else { // 父进程：一直忙自己的，完全不管子进程死活 while (true) { std::cout << "我是父进程，PID: " << getpid() << ", 正在忙碌中，没空收尸..." << std::endl; sleep(1); } } return 0; }

1.3.2 使用命令行监控并识别Z状态

另开一个终端，把下面这条监控脚本贴进去跑起来。它会每隔一秒刷新一次进程列表，子进程咽气的那一瞬间，你绝不会错过：

while true; do ps -axj | head -n 1 && ps -axj | grep myprocess | grep -v grep; sleep 1; echo "---------------------------------------"; done

五秒倒计时一结束，你会看到两个非常扎眼的变化：

• 子进程的STAT栏从S+（睡眠）变成了Z+（僵尸）。加号还在，说明它还占着前台身份，只是人已经没了。
• 子进程的COMMAND栏末尾，冒出来一个幽灵般的标记：[myprocess] <defunct>。defunct 翻译过来就是“已故的、不再存在的”，这是僵尸进程的官方认证标签。

从此这个Z+状态就焊在那儿了，因为父进程还在自己的循环里忙活，压根没有要回收的意思。只要父进程不退出，也不调用wait，这个僵尸就会一直飘在进程表里，成为系统里一道安静又顽固的风景。

1.4 深入拓展——内核对象分配与SLAB技术

当父进程终于良心发现，调用waitpid()把退出信息取走了，这块残留下来的task_struct到底是怎么被销毁的？这就得把目光伸向Linux内核里一套相当精巧的内存管理机制了。

1.4.1 什么是SLAB？

在Linux运行期间，像task_struct、mm_struct、file这类内核结构体对象，简直可以称得上是“高频日用品”。它们会被反复创建，比如你每fork 一次，就得多一个task_struct；进程退出，它们又会被销毁。一进一出，频率极高。

那问题来了：如果每次创建这些结构体，都老老实实跑去向操作系统申请新的物理内存页；每次销毁，又直接把这些页释放掉，这来回折腾的成本有多高？每一次底层的内存申请和释放，都要牵涉到内核页表映射、虚拟地址和物理地址的转换，这些操作极其耗时，完全是高射炮打蚊子。

为了解决这个“高频小对象”的管理难题，Linux内核引入了SLAB内存分配器（包含SLAB/SLUB/SLOB几个具体实现）。它的核心思路一句话就能说清：先把一批对象提前造好，放在缓存池里，谁要用就直接从池子里拿；用完了也不真销毁，只是擦干净放回池子等下次再用。这样一来，频繁创建和销毁带来的页表操作开销，就被一次性摊薄了，内核的内存管理效率瞬间上了一个台阶。

换句话说，SLAB就是内核给那些“频繁生、频繁死”的小结构体开的一个“对象缓存池”。task_struct的回收，最后一步就是被擦净了放回这个池子里，而不是真的把内存页还回去。这也解释了为什么僵尸进程的户口本，能在父进程收尸之后，被那么干净利落地处理掉，不是销毁，是回收复用。

1.4.2 内核数据结构的对象缓存机制

SLAB技术的本质，其实就是内核给那些高频小结构体开的一个“对象池”。这个池子的运作逻辑，可以拆成两个动作来看——回收和复用。

• 回收不等于彻底销毁：当僵尸进程的收尸流程走完，内核准备释放它的task_struct时，并不会把这块内存真的还回物理内存管理系统。它只是轻轻把这块内存标记成“空闲（unused）”，然后送进一个空闲队列，也就是slab缓存池里，等着被再次使用。这就像退房时，不是把房子拆了，而是把房间打扫干净、挂上“可入住”的牌子。
• 创建时的极致复用：等到系统里又有新进程诞生，需要一块新的task_struct时，内核不会去物理内存里现挖一块，而是直接伸手到这个缓存池里捞一块现成的、已经标为空闲的内存出来。稍稍改几个字段，就变成了一块全新的task_struct。省去了重新申请、重新映射页表的全部开销。

通过这种“对象缓存”的思路，内核成功绕开了频繁申请和释放物理内存的昂贵开销。进程创建和销毁的效率，因此提升得相当可观。在大量并发fork的场景下，这个设计说是生命线也不为过。

二、孤儿进程（Orphan Process）

在多进程的家族体系里，除了“子进程先走、父进程不闻不问”造成的僵尸进程，还有一种情况正好相反：父进程先一步退出，留下子进程孤零零地继续运行。这些没了爹的孩子，就是孤儿进程。

2.1 什么是孤儿进程？

2.1.1 孤儿进程的定义与产生原因

在 Linux 系统中，一个父进程可能因为正常执行完毕、中途异常崩溃、或者被信号直接杀掉而退出。无论哪种死法，只要它下面还有子进程在跑，那些子进程瞬间就失去了唯一的监护人，沦为孤儿。

2.1.2 谁来“托底”？——一号进程的领养机制

操作系统是个极度注重安全和稳定的系统，它绝不允许任何进程在没有监护人的情况下四处游荡。原因很现实：如果这些孤儿没人管，等它们跑完退出、进入僵尸状态时，就永远不会有父进程来为它们收尸。一个没人收尸的僵尸，又回到了上一节那个内存泄漏的老问题上。所以，Linux内核早早设计了一套领养机制来兜底。

核心结论一句话：只要父进程先退出，操作系统就会强制指派1号进程，把剩下的所有孤儿子进程全部领养过去。

这个 1 号进程，在老版本的Linux里叫init，而在现代发行版（CentOS 7及以上、Ubuntu等）中，它的名字已经换成了systemd。换了马甲，职责不变，它是系统里所有进程的最终监护人，永远在线，专门负责给失去父进程的孤儿一个家，并在它们退出后完成收尸。有了这位“系统级大家长”，孤儿进程才不会变成无人认领的僵尸。

2.1.3 认识 1 号进程——systemd

1号进程是Linux内核启动后创建的第一个用户空间进程。它是整个系统所有用户进程的“老祖宗”，地位高得吓人，登录认证、系统服务管理、设备初始化，这些底层杂活全都由它帮着内核打理。

当我们登录操作系统时，系统会为我们自动创建一个bash。而这个bash的创建者，正是这位1号进程。systemd是它的名字，它本身就是操作系统的一部分，从开机那一刻起就一直驻留在内存里，直到关机才消失。正因为它的地位如此特殊，由它来接管孤儿进程再合适不过。孤儿子进程一退出，systemd就会立刻调用wait()族函数，把它们的task_struct回收得干干净净，绝不产生内存泄漏。有它在，孤儿就不会变成僵尸。

顺带提一句，其实还有一个更老的祖宗，0号进程。不过它开机之后很快就被替换掉了，属于系统启动瞬间的过渡角色，这里就不展开聊了。你只需要记住：1号进程systemd，是当代Linux里所有孤儿的终极监护人。

2.2 孤儿进程实战——观察与模拟验证

2.2.1 编写孤儿进程模拟程序

光听理论不过瘾，我们直接写一段C语言代码，把“父进程活5秒就撒手人寰，子进程则赖着不走”的场面搬到屏幕上。

#include <stdio.h> #include <sys/types.h> #include <unistd.h> #include <stdlib.h> int main() { pid_t id = fork(); if (id < 0) { perror("fork error"); return 1; } else if (id == 0) { // 子进程：没有退出计划，一头扎进死循环 while (1) { printf("我是子进程，pid: %d, ppid: %d\n", getpid(), getppid()); sleep(1); } } else { // 父进程：只活 5 秒，时间一到，拍拍屁股退出 int cnt = 5; while (cnt) { printf("我是父进程，pid: %d, ppid: %d, 剩余寿命: %d\n", getpid(), getppid(), cnt--); sleep(1); } printf("父进程生存期结束，已退出！\n"); } return 0; }

运行之后，屏幕上会先交替出现父子进程的各自播报。等那5秒倒计时走完，父进程吐出最后一句“已退出”，头也不回地消失了。而子进程呢？它还在继续刷屏，唯一不同的是，它打印出来的ppid 会悄悄变掉：原来的爸爸不在了，那个新的ppid，就是1号进程systemd的ID。一瞬间，孤儿就找到了新的监护人。接下来我们就在另一个终端里用ps把这一切看个真切。

2.2.2 命令行监控与进程关系分析

在终端里编译并运行程序，然后另开一个窗口，用ps命令高频捕捉进程状态，你会看到这样一段输出流：

我是父进程，pid: 22702, ppid: 21931, 剩余寿命: 5 我是子进程，pid: 22703, ppid: 22702 ... 父进程生存期结束，已退出！ [abc@]$ 我是子进程，pid: 22703, ppid: 1 我是子进程，pid: 22703, ppid: 1

• 前5秒里，一切如常。子进程的ppid稳稳指向22702，那是它的亲生父亲。屏幕上的父子俩你一句我一句，正常的家庭日常。
• 第5秒一到，父进程准时退出，命令行提示符重新跳了出来，仿佛刚刚那场父子对话只是场短暂的演出。然而，就在Shell提示符的后头，子进程却还在疯狂刷屏，好像什么都没发生过。

唯一变了的，是它的ppid。原来那个22702不见了，取而代之的是一个孤零零的数字：1。

这不是巧合，这是领养机制的现场实拍。就在父进程咽气的那一瞬间，1号进程systemd已经伸手把这名孤儿揽进了怀里。从此它的监护人变了，但它的生命还在继续。孤儿进程的整个诞生过程，全在这几行输出里讲完了。

2.3 两个容易混淆的进程细节

在模拟孤儿进程的过程中，你一定会撞上两个让人愣一下、想通了又拍大腿的现象。这两个细节，恰恰是理解进程家族关系的关键。

2.3.1 父进程退出后，为什么自己不会变成孤儿进程？

这个问题问得相当刁钻。按我们前面的逻辑“父进程退出，子进程还在运行，子进程就变成孤儿”那父进程退出的时候，它自己的父亲不是也活得好好的吗？那个父亲是谁？就是一直蹲在后台盯着它的命令行终端bash进程。既然bash还活着，父进程怎么没变成孤儿？

原因其实很干脆：

• 父进程退出时，它的子进程还赖在世上，所以子进程成了孤儿。
• 而父进程自己的老爹bash，从始至终都活着，还一直在后台盯着它。父进程刚咽气，bash就秒调用wait把它的退出信息回收得干干净净。整个收尸流程在极短时间内走完，父进程直接被清理出局，根本没有机会触发孤儿机制。

换句话说，孤儿机制的触发前提是“退出者还有活着的子进程，且没有活着的父进程”。而父进程退出时，虽然它确实还有活着的子进程，但它的父进程bash也没死。两个条件只满足了一个，所以它成不了孤儿。子进程那边则刚刚好反过来——它没有活着的父进程了（父进程退出），却又还没退出，于是孤儿身份稳稳落到它头上。一个退出，一个存活，身份的转换就藏在这一进一出之间。

2.3.2 前台进程与后台进程是如何发生变化的？

注意观察你在终端里的操作。当父进程退出、控制台重新跳出[abc@...]$ 提示符之后，不管你疯按多少下Ctrl + C，那个子进程都完全无动于衷，照样刷屏。为什么键盘突然管不了它了？

因为子进程被 1 号进程领养后，它的“人设”发生了一个隐蔽的转变：从台前退到了幕后。

那个小小的+号，就是前台身份的象征。父进程活着的时候，子进程跟它一起霸占着终端，你的键盘输入只能喂给它们。可父进程一退出，终端控制权重归Shell，子进程被systemd领走，成了没资格碰终端输入的后台进程。它能继续往屏幕上吐字，却再也听不到你的Ctrl + C了。

那怎么清理这个赖在后台不走的孤儿？指望Ctrl + C是没戏了，只能祭出最直接的九号信号。另开一个终端，执行：

kill -9 22703

把22703换成你实际查到的子进程PID就行。一记SIGKILL下去，这位后台孤儿就彻底安静了。

如果这篇文章对你有帮助，欢迎点赞、收藏、关注三连支持，你的反馈是我继续肝下一篇的最大动力。我们下篇见。