我最近在复习操作系统里的进程管理，越看越觉得“进程图像”“收缩”这两个词被大家一笔带过的次数太多了。考试考到“进程切换时做了什么”，很多人只会答“保存现场、恢复现场”，但现场是什么、保存在哪、什么时候“收缩”什么时候“膨胀”，很少有人能讲透。这篇笔记就是围绕进程图像和收缩这两个核心，把进程管理里的创建、切换、换入换出、撤销这些机制串起来讲。适合正在准备操作系统期末、考研复试，或者刚开始学系统编程的读者。我会尽量按实际项目里调试进程时的思路来写，而不是教科书式的罗列。
1. “进程是运行中的程序”这句话，只说对了一半
1.1 程序是菜谱，进程是厨房里正在进行的那顿饭
刚接触操作系统时，几乎每本教材都会说一句话：进程是运行中的程序。这句话没有错，但理解得太浅会让人在后面学到进程同步、调度、内存管理时感到困惑。我更喜欢用一个生活类比：程序是菜谱，进程是厨房里正在进行的那顿饭。菜谱放在抽屉里，内容永远不变，这是静态的。厨房里有人切菜、开火、装盘，锅碗瓢盆的位置在变、食材在消耗，这些都是动态的。程序在磁盘上和程序在内存里跑起来，完全不是一回事。
进程之所以“活”，是因为它除了代码和数据之外，还多了一套运行时的状态，包括程序计数器、寄存器里的值、栈里的调用关系、打开的文件、当前所在的目录。这些状态合在一起，构成了一个进程在某一时刻的完整画面。操作系统教材里把这套画面叫作进程图像，也叫进程映像。过程管理本质上就是对这套图像的创建、保存、切换、修改和销毁。
1.2 进程图像是进程在内存里的“全家福”
我没有找到统一的教科书定义，不同教材对进程图像的用词略有差异，但核心含义一致：进程图像是进程实体在内存中的完整表示，也就是包括程序代码、数据集合、进程控制块、系统堆栈和用户栈在内的整体结构。你可以把进程图像理解为一张“全家福”，照片里既有静态的部分（代码和数据），也有动态的部分（寄存器现场、栈的内容、打开的文件描述符），还有描述这个进程是谁的档案信息（PCB）。
操作系统在进程管理中做的所有事情，几乎都围绕这幅图像展开。进程创建，是要把一幅图像从零搭起来；进程调度，是把当前这幅图像保存好，再换另一幅图像进来；进程阻塞，是让这幅图像暂时停在一个非运行状态，但保存在内存里；进程结束，是把这幅图像彻底拆除。所以说，理解了进程图像，就理解了进程管理的底牌。
1.3 为什么“收缩”这个词值得单独讲
“收缩”在操作系统里有好几个层面的意思，这一点特别容易混淆。最常见的理解是在进程切换时，处理器状态这些“活动的”信息会被压缩保存到内核栈和PCB里，图像从“全展开”变成“快照”，这可以理解为图像的一种收缩。另一个层面是内存管理里的对换和紧凑：当内存不足时，把暂不运行的进程图像换到外存，或者把分散在内存不同位置的进程图像移动到一起，这也是一种收缩。还有一个层面是系统调用和中断返回时，内核栈、用户栈的增长与回缩。我写这篇笔记时，会把这三层意思都拆开，结合进程管理的实际场景讲清楚。
2. 进程图像的四块拼图：代码、数据、栈、PCB
2.1 程序代码与数据集合：进程的“静态骨架”
进程图像里最直观的部分，是程序代码和程序数据。代码段（正文段）存放编译后的机器指令，它在内存中通常是只读的，而且可以被多个进程共享。当一个程序被多次执行时（比如开了好几个终端都运行ls命令），这些进程的代码段可以映射到同一块物理内存，不需要每个人复制一份。这正是很多教材里强调的“代码共享”节省内存的原理。
数据集合则比较复杂，包含全局变量、静态变量，以及程序运行时动态分配的堆内存。我们平时写C语言时，全局变量放在数据段，malloc出来的内存则在堆区。堆是向高地址增长的，栈是向低地址增长的，二者之间有空隙，这是进程虚拟地址空间里最常见的布局。一个进程图像里“静态”的部分不是永远不变的，数据段内容会被程序修改，堆也会因为malloc/free而伸缩，但整体结构是稳定的。
为了更直观，我在Linux下写一个最简单的C程序，然后查看它的内存布局：
#include <stdio.h> #include <stdlib.h> int global_var = 42; int main() { int local_var = 10; char *p = malloc(64); printf("global: %p, local: %p, heap: %p\n", &global_var, &local_var, p); free(p); return 0; }编译运行后，地址大致呈现：全局变量和堆区在中低地址区，局部变量和栈在高地址区。这是进程图像里最基础的“骨架”，后续讲栈的收缩和堆的动态变化，都建立在这块布局上。
2.2 用户栈与系统堆栈：进程的“动态现场”
栈是进程图像里最容易让人迷惑的部分，因为一个进程其实有两套栈：用户栈和内核栈。用户栈运行在用户态，存放函数调用的局部变量、参数、返回地址；内核栈则运行在内核态，存放系统调用和中断处理时的现场信息。
为什么需要两套栈？核心原因是安全隔离。用户程序不能随便访问内核的栈，否则它就能伪造内核态的执行上下文，进而控制系统调用返回流程，这是非常严重的安全漏洞。所以处理器设计上就有“用户态与内核态”的区分，操作系统在每次从用户态陷入内核态时，会切换到内核栈，处理完再切换回来。
这个过程的本质，就是栈内容的“生长”和“收缩”。用户程序调用函数时，用户栈向下增长；函数返回时，栈顶向上收缩。发生系统调用时，处理器把现场压入内核栈，内核栈“膨胀”；系统调用返回到用户态时，内核栈又“收缩”。理解栈的收缩机制，比死记“栈是后进先出”有用得多，因为进程图像中变化最频繁的就是栈区域。
2.3 进程控制块PCB：进程的“身份证档案”
如果说代码、数据、栈是进程的身体，那PCB就是进程的档案和身份证。每个进程都对应一个PCB，操作系统通过PCB来识别进程，没有PCB的进程是不存在的。
PCB里一般包含五类信息：进程标识符（PID，以及创建该进程的父进程ID），处理器状态（寄存器现场，这是进程切换时最重要的一块），调度信息（进程优先级、当前状态、等待原因），内存管理信息（代码段、数据段、栈的起始地址和长度，页表或段表指针），以及I/O状态信息（打开的文件列表等）。
有个很容易忽略的细节：不同操作系统里PCB的组织方式不同。Linux把进程描述符放在thread_info里，用链表和哈希表管理；老式Unix系统则有进程表项。但我们学习时不必纠结具体实现，抓住核心就行：PCB是进程图像中唯一让操作系统“认识”这个进程的数据结构，其他部分再多，没有PCB也无法参与调度。
2.4 一张文字图看懂进程虚拟地址空间
学习进程图像时，我最开始总记不住各段的上下关系，后来自己画了几次内存布局图，才真正记住。下面这张是Linux下典型进程虚拟地址空间的示意图（从低地址到高地址）：
高地址 +------------------+ | 环境变量 | +------------------+ | 用户栈 | <-- 向下增长（函数调用时向下扩展） +------------------+ | 空洞 | +------------------+ | 堆 | <-- 向上增长（malloc时向上扩展） +------------------+ | 数据段(全局) | +------------------+ | 代码段(只读) | +------------------+ 低地址这张图是所有进程图像的“基准底图”。栈和堆是动态变化的，会相互靠近；如果堆向上增长和栈向下增长撞到一起，就会触发栈溢出或者堆溢出错误。很多进程崩溃问题的根源，其实都可以在这一层找到答案。
3. 进程切换时，“图像收缩”到底在收缩什么
3.1 先分清三种容易混淆的“收缩”
“收缩”这个词在进程管理里有三个容易被混淆的含义。第一种是CPU上下文切换时，当前进程的活跃寄存器现场被压缩保存到PCB和内核栈中，进程图像从“运行态全展开”转为“就绪态快照”。第二种是内存换出和紧凑操作，系统把暂时不用的进程图像整体或者部分搬到外存，或者挪动位置，让内存空间变得连续。第三种是内核态深入时，内核栈和用户栈本身发生的增长与回缩。这三种收缩机制不同、目的不同、触发条件也不同。我在复习时曾用下面这张表区分，效果很好：
| 收缩类型 | 触发时机 | 收缩到什么位置 | 恢复机制 |
|---|---|---|---|
| 上下文切换现场保存 | 时间片耗尽、中断、系统调用 | 内核栈和PCB | 再次被调度时恢复 |
| 进程换出到外存（对换） | 内存不足、进程被挂起 | 磁盘交换区 | 重新调入内存 |
| 栈帧的回退 | 函数返回、中断返回 | 栈指针向高地址移动 | 再次调用时自动增长 |
搞清楚这三种收缩，再读那些教材里的代码就顺多了。很多人学进程切换时觉得寄存器保存恢复很抽象，我建议直接拿一棵函数调用树去想：foo调用bar，bar调用baz，baz返回后bar继续执行，bar返回后foo继续执行。这个过程中，每一个调用点都需要保存返回地址和局部变量，函数返回时这些栈帧收缩掉。整个进程被切走时，系统保存的是最外层“运行中状态”的现场，而不只是某一个栈帧。
3.2 上下文切换的完整流程
进程切换（上下文切换）是操作系统进程管理最核心的操作之一，它由内核完成，用户程序无法感知细节。一次完整的切换大概分为五步：
第一步，触发切换事件。可能是时间片耗尽，可能是进程等待I/O主动阻塞，也可能是更高优先级进程抢占。第二步，从用户态切换到内核态。进程通过中断、系统调用或者异常陷入内核。第三步，保存当前进程的处理器现场，包括程序计数器PC、栈指针SP、通用寄存器、状态寄存器等，把这些值写入当前进程的PCB和内核栈。第四步，通过调度算法选出下一个要运行的进程。第五步，从新进程的PCB和内核栈中恢复它的现场，把相关寄存器填回处理器，然后切换回用户态继续执行。
这个过程中最关键的一句话是：切换的开销不在于“搬运图像数据”，而在于保存和恢复寄存器的次数、TLB和缓存失效带来的代价。如果我们把进程图像理解为整个地址空间，那你可能会以为切换就是把整个图像搬来搬去，实际上进程在内存中的代码、数据、栈、堆都还待在原地，切换时真正被交换的，是处理器现场的“活动状态”。
为了加深理解，我写过一段伪代码来描述切换逻辑：
void context_switch(struct task_struct *prev, struct task_struct *next) { // 1. 保存prev的现场到prev的内核栈和PCB save_processor_state(prev->thread); // 2. 切换内存地址空间（加载next的页表等） switch_mm(prev->mm, next->mm); // 3. 切换内核栈（栈指针指向next的内核栈） switch_stack(prev->thread, next->thread); // 4. 恢复next的现场 restore_processor_state(next->thread); }在实际的Linux内核里，switch_to宏就是这么做的。它保存prev的寄存器现场，把ESP切换到next的内核栈，再从next的thread里恢复现场。这里隐含了“图像收缩”的关键：prev运行时的全部处理器状态，在切换的一瞬间被压缩为一堆寄存器值，塞进了PCB和内核栈。等它下次被调度时，再从这堆值中“展开”，恢复成完整的运行状态。
3.3 内核栈为什么是保存现场的最佳位置
有些读者会问：现场信息为什么保存到内核栈，而不是直接全部塞进PCB？答案和栈的特性有关。PCB的大小是固定的，放不了太多嵌套调用的现场数据；而内核栈可以随着调用深度动态增长和收缩。系统调用可能嵌套、中断可能嵌套，每一层都要保存不同的现场。内核栈这种后进先出的结构，正好天然适配嵌套场景，每一层处理返回时都能把最内层的现场先恢复。
另一个原因是内核栈和进程切换天然绑定。进程被切走时，CPU切到新进程的内核栈，旧进程内核栈中的数据自然就“冻结”在原来的位置。下次切回来时，只要恢复栈指针SP指向旧进程内核栈的正确位置，就能按原样接着运行。这种设计配合起来非常顺畅，所以我们说进程切换的图像收缩，很大程度就是“把活跃状态压栈保存”这个动作。
3.4 切换代价的实际体验
真正让我体会到进程切换开销的，是在一个高并发的网络服务程序里做压测。当时我用top命令观察，发现系统态CPU占比很高，进程数几百个，频繁切换导致吞吐量上不去。后来我查了很多资料，才明白每次切换不只是寄存器保存恢复，还会导致TLB失效，新进程刚访问过的页表没有缓存，一开始访问内存必然慢。这就是为什么很多高性能服务倾向于用事件驱动模型而不是多线程阻塞模型，因为每来一个请求就阻塞唤醒一个线程，切换成本太高。
从这个角度再看“进程图像收缩”，它的意义就清晰了：系统通过把运行现场快速压缩保存，让CPU能毫秒级地从一个进程切到另一个进程，但这种“毫秒级”如果频率过高，也是巨大开销。进程管理不只是静态的数据结构管理，更是一场关于“压缩和展开”的表演。
4. 进程图像在内存中的“瘦身”：换出、换入与紧凑
4.1 对换技术：把暂时不跑的进程图像搬到外存
前面讲的进程切换是CPU层面的快速切换，进程的静态图像始终留在内存里。但内存是有限资源，当多个进程都想同时驻留内存时，内存可能不够用。这时候操作系统会启动对换（swapping）机制：把暂不运行的进程的整个图像从内存换到磁盘的交换区，腾出空间给运行中的进程。等那个被换出的进程再次被调度时，再把它从磁盘换回内存。
这里要特别说明一个容易混淆的点：进程被换出，不等于进程被撤销。进程的PCB仍然保留在外存或内核管理的交换区相关结构里，它只是暂时“睡眠”在磁盘上。等到合适时机，系统按需把它唤回内存。对换技术里，进程图像真的被“搬走”了，这和上下文切换只搬寄存器现场有本质区别。从教材角度看，对换适合优先级低、长时间等待I/O的进程；现代操作系统虽然不常做整个进程的对换，但在嵌入式系统、早期Unix以及内存极小的情况下，对换是保证系统运行的救急手段。
4.2 内存紧凑：把分散的进程图像“挤”到一起
还有一个和“收缩”强相关的机制叫紧凑，英文是compaction。内存经过反复的分配和释放，会产生大量小的空闲碎片，每个碎片单独看都不够大，但加起来空间并不少，这可能让一个大进程图像找不到连续区域装入。紧凑的做法是：把已分配的所有进程图像整体向内存一端移动，把所有空闲碎片合并成一个大连续区。
紧凑的代价非常明显：移动进程图像意味着要修改它们的地址映射，如果是分页系统，页表要重新计算；如果是分区分配，PCB里的段表基址也要改。这本质上是对进程图像做一次“物理搬家”。现代操作系统大多采用分页存储管理，分散的页框本来就不要求连续，所以单一的紧凑机制已经用得不多，但分段管理或者某些特殊场景下紧凑仍然有应用价值。理解紧凑的意义在于，它提醒我们进程图像的“地址”不是固定的，任何改变物理位置的操作，都必须同步更新PCB中的地址映射信息。
4.3 页面置换：进程图像的局部“瘦身”
现代操作系统更多使用虚拟内存和页面置换，进程图像不需要一次性全部装入内存，而是按需装入。当一个进程的代码和数据被划分为多个页面，访问某个页面时如果它不在内存，就发生缺页中断，从磁盘调入该页。如果内存已满，还必须先选一个页面换出到磁盘。这个过程虽然是对单个页面的操作，但从进程图像角度看，它实际上是进程图像的局部收缩——一部分内容暂时离开了内存。
进程图像被换出的页面越多，理论上进程运行需要的内存“足迹”越小，但缺页中断越频繁。极端情况下，频繁换页会导致“抖动”（thrashing），也就是系统花大量时间换页，几乎没有时间真正执行程序指令。我在实验时遇到过这种情况：开太多进程，每个进程工作集都超过物理内存，系统负载直接飙升，CPU却大多是等待I/O的iowait。
这里有一组经典的参数值得对比：进程工作集和驻留集。工作集是进程在某一时间窗口内实际访问的页面集合，驻留集是进程当前驻留在内存中的页面集合。调度和内存管理要让驻留集覆盖工作集，否则必然频繁缺页。进程的PCB中记录的其实正是当前驻留集的范围和状态，这又回到了画面：PCB负责描述进程图像的“当前瘦身状态”。
5. 进程图像的诞生、覆盖与消亡：一次完整生命周期
5.1 fork：子进程图像是怎么“复印”出来的
进程图像的创建在Unix-like系统上主要通过fork系统调用完成。fork的特殊之处在于，子进程不是从空白开始搭图像，而是直接复制父进程的进程图像。父进程的代码段、数据段、用户栈、堆，以及PCB中的大部分字段（包括打开的文件描述符、环境变量、当前目录）都会被复制一份给子进程，然后子进程从fork调用的返回点开始执行。
这里有个经典考点：父进程和子进程的fork返回值不同。父进程收到子进程PID，子进程收到0。代码是同一份，但进程图像是两份独立的，它们的虚拟地址空间互不影响。我们写一个最常见的例子：
#include <stdio.h> #include <unistd.h> int main() { pid_t pid = fork(); if (pid < 0) { perror("fork"); } else if (pid == 0) { printf("child: my pid is %d\n", getpid()); } else { printf("parent: child pid is %d\n", pid); } return 0; }运行结果里，父进程和子进程的代码段物理上可能是共享的，但数据段从一开始就是按“写时复制”机制处理的。写时复制是一种优化：刚开始父子进程共享同一块物理数据页，只有当某一方真正写入数据时，才复制一份给写入方。这意味着至少在最开始，子进程的“图像”并没有被完整复制到新的物理内存，只是在虚拟地址空间层面复制了页表映射。直到某一方写数据，才真正产生私有副本。
写时复制让fork的代价大大降低，也解释了为什么fork创建进程比单纯创建线程还要快一些。我们在系统编程面试时被问“fork做了什么”，最好的回答不是“复制了父进程全部内存”，而是“复制了PCB、页表等控制结构，物理页面按写时复制共享”。
5.2 exec：加载新程序，覆盖旧图像
fork之后，子进程往往要执行一个新的程序，这时会调用exec族函数（execl、execv、execve等）。exec的作用是：把当前进程图像里的代码段、数据段、用户栈、堆全部替换成新程序的内容，然后重新初始化这些区域，但进程的PID、父进程关系、打开的文件描述符通常保持不变。
也就是说，exec不是创建新进程，而是“让同一个进程换一副全新的图像”。这个设计非常精妙：先fork复制图像，再exec替换图像，子进程最终运行的就是全新的程序。如果把进程图像看成一本书，fork相当于复印机复印了一本书，exec相当于撕掉复印本的内容、重新装订一本新书，但书的封面标签（PID）保留不变。
exec加载新图像时，还有一个细节值得注意：新程序入口地址会被写入PC，栈会被重新初始化并压入argv和envp。旧图像占用的内存空间被回收，映射新程序的段和页。这个过程的实质，是对进程图像做一次彻底的“刷新”。
5.3 exit与僵尸进程：图像消亡的最后一程
进程图像的消亡通过exit系统调用完成。进程调用exit后，内核会执行以下工作：回收该进程占用的内存，关闭已打开的文件描述符，释放其他内核资源，然后把进程状态改成僵尸状态，并向父进程发送SIGCHLD信号。为什么进程已经退出了还叫僵尸？因为它还保留了PCB中的一小部分信息，包括PID、退出状态、CPU使用时间等，这些信息是为了让父进程通过wait/waitpid查看子进程的退出结果。直白说，进程图像的大部分已经销毁，只留一个“骨架档案”等父进程来领。
如果父进程一直不调用wait，僵尸进程就会一直留在进程表中，累积多了会占满PID空间。这在写长跑服务时是个真问题：如果不处理好子进程的回收，系统里会出现大量僵尸进程。我在自己写的多进程网络服务里就踩过这个坑，子进程一多，不调用waitpid回收，进程表渐渐被占满，新进程fork失败，报“Resource temporarily unavailable”。后来通过信号处理函数统一waitpid回收子进程，才真正解决。
进程图像的整个生命周期：fork出生、exec换血、运行中切换收缩、换出瘦身、finally exit销毁，这一圈走下来，正好把操作系统进程管理的所有知识点串起来了。
6. 期末最爱挖的坑：图像与收缩的易错点清单
6.1 高频判断题和选择题陷阱
复习到后期，我总结了一批和进程图像、收缩相关的高频陷阱题，每次考试都有人在这里丢分。我列几个典型的：
| 常见判断题 | 正确答案 | 陷阱分析 |
|---|---|---|
| fork之后父子进程完全共享同一份代码段，所以它们代码段的虚拟地址相同 | 对 | 注意虚拟地址相同不代表物理地址相同，而且代码段是只读的 |
| 进程切换就是操作系统把进程图像从内存搬到磁盘 | 错 | 切换只保存/恢复寄存器现场，图像仍留在内存 |
| exec创建了一个新的进程 | 错 | exec不创建进程，只替换当前进程图像 |
| 进程被换出外存后就无法被唤醒 | 错 | PCB和外存映像仍在系统控制中，可被重新调度进入内存 |
| 进程调用exit后PCB立即释放 | 错 | 先转为僵尸，PCB保留直到父进程回收 |
这道“进程切换=搬运图像”的题，本质就在考你有没有把“上下文切换”和“对换”区分开。我见过不少同学栽在这里，因为教材先讲了处理器状态、再讲进程切换，很容易把两张图弄混。核心记忆点就一个：进程切换是CPU换“运行状态”，对换换的是“驻留内存的图像”。
6.2 实操视角：用命令观察真实进程图像
学理论别光看课本，我强烈建议自己动手观察一下真实进程的图像。Linux系统里最直观的工具是查看/proc文件系统。比如我们在一个终端里运行程序，然后在另一个终端执行：
cat /proc/PID/maps pmap PID/proc/PID/maps会列出进程当前所有的虚拟内存区域，包括可执行文件映射、共享库、堆、栈。你能清楚地看到栈区域是从高地址往低地址长的，堆在低地址向上长，共享库的映射位于中间，这就是进程图像在运行中的真实快照。再配合strace观察系统调用，你可以看到一个进程创建时调用mmap、open、read这些系统调用的完整序列，体会到进程图像是怎么一点一点被搭起来的。
还可以在程序里做一个小实验：递归调用函数几百次，每调用一次打印当前栈变量的地址，你会发现地址在逐渐变小，这就是用户栈向下增长的过程。等递归深度过大导致栈溢出时，程序报Segmentation fault，这时候你再回头想“栈空间的收缩和增长”，体会会完全不同。
6.3 面试时的加分回答
如果去面试系统开发岗，面试官问到“你对进程图像怎么理解”，只看书本的背法很难拿高分。我建议按这个层次回答：
第一层，进程图像是进程在内存中的完整实体，包括代码、数据、栈、堆和PCB。第二层，进程管理和调度本质上是对这些图像的控制：保存、切换、换入换出、销毁。第三层，现代系统对进程图像的优化，包括写时复制、按需分页、工作集模型，让一个“完整图像”不需要全部常驻内存也可以正常执行。第四层，理解进程切换的真正开销不是搬移图像本身，而是TLB失效、缓存失效、以及内核栈切换的连锁效应。这样由浅入深，既展示了知识储备，又展示了工程视角，效果远好于单纯背诵定义。
复习完进程图像和收缩这条线，我最大的感受是：操作系统很多概念都是互相咬合的，孤立地背“进程三态”“PCB包含什么”很容易忘，但如果你始终带着“这幅图像正在被压缩、搬运、替换、销毁”的画面去看，所有知识点都能连在一起。我建议读这篇笔记的读者，学完以后亲自写一个fork程序，再配合pmap观察它的内存映射，把纸面上的进程图像变成自己眼睛看到的真实数据，记忆会牢固得多。后面我还会补一篇进程同步的笔记，把锁、信号量和条件变量也串到进程管理这条线里讲。
