进程、线程、协程，这几个词大概是计算机相关专业绕不开的“老三样”。工作几年以后你会发现，真正决定一个服务并发上限的，并不是用了什么高深的框架，而是你对这三个概念的理解深度。这一篇是这个系列的第三十六篇，也是操作系统专题里关于并发基础模型的第二次展开。上一篇我们已经把定义和基本特性过了一遍，这一篇直接照进现实：它们之间到底谁更轻？代价差在哪？相同负载下选错模型的后果是什么？
也许有人会问，现在的框架都封装得很好，写业务代码时根本不直接创建进程，还要不要搞清楚这些原理？我的回答是：需要。因为几乎所有异步框架、并发中间件、池化组件的底层设计，都建立在“进程、线程、协程分别适合什么负载”这个判断之上。你不一定要自己造轮子，但至少得看得懂别人造的轮子，还得知道自己的车适合用哪个轮子。
1. 三个概念的边界划分：资源容器与执行流
1.1 用“资源归属 + 执行流”重新组织记忆框架
教科书上对进程、线程、协程的定义已经写得很清楚了，但很多人背完之后还是容易混，原因在于定义是按“是什么”来组织的，而实际工程里我们更关心“它拥有什么、它交换什么、它隔离什么”。所以我不建议从概念背起，更推荐从两个维度拆：资源和执行流。
进程是资源容器。它拥有独立的地址空间、文件描述符表、信号处理状态、环境变量等一堆“不动产”。线程是进程内部拆出来的执行流，它不拥有地址空间，和进程里其他线程共享全局变量、堆内存和大部分内核资源。协程再往前走一步，它连内核都不需要感知，完全由用户态的程序自己控制什么时候暂停、什么时候恢复。
用一张简单的层次关系来看：
- 进程：拥有完整资源，独立地址空间，至少拥有一个执行流。
- 线程：不独立拥有地址空间，共享所属进程的资源，由内核调度。
- 协程：不独立拥有资源，不被内核直接感知，由用户态调度器控制。
这个整理看起来简单，但能推导出很多有用结论。进程之间天然隔离，一个进程崩溃通常不会拖垮另一个进程；线程之间共享一切，高效但是需要小心翼翼；协程之间也共享宿主线程的上下文，怎么管理好“谁暂停、谁恢复、数据怎么同步”全看写代码的人。
1.2 一个容易忽略的推论：隔离与共享是在赌安全还是赌效率
隔离和安全往往是同一个意思，共享和效率也往往是同一个意思，但两者天生打架。
多进程模型最安全，哪怕某个子进程因为段错误直接崩掉，父进程还能重新拉起一个新的。你可以把这理解成“每家每户住在独立别墅里，水管爆了只淹自己家”。多线程模型所有线程住在一栋楼里，共享上下水，任何一家乱改管道都有可能影响整栋楼。协程模型更像一群人共用一个工作台，每个人可以随时暂停手里的活去干别的，但工作台上的工具如果乱拿乱放，别人就没法干活了。
这带来一个工程判断：如果你对稳定性的要求远高于内存上的效率，就多考虑进程隔离；如果进程间通信成本太大，且需要频繁共享数据，就用多线程；如果瓶颈在大量的等待和空闲上，才轮到协程登场。很多设计之所以出问题，不是因为用了某个模型，而是没搞清楚自己是在“赌隔离”还是在“赌效率”。
2. 调度成本拆解：模式切换、缓存失效与协程的“快”到底从哪来
2.1 一次完整上下文切换的旅程：从用户态到内核态再回来
讨论三种模型，无论如何绕不开“上下文切换”这四个字。很多人只知道切换有开销，但不知道开销具体花在哪，结果就是低估了多线程在高并发下的代价。
先看线程之间切换时发生了什么。线程A正在用户态执行指令，突然一个系统调用或者时钟中断触发，CPU特权级要从用户态切到内核态，先保留线程A完整的状态，包括所有通用寄存器、程序计数器、栈指针、状态寄存器，然后更新内核维护的调度数据结构，把线程A放回等待队列或就绪队列。内核调度器根据优先级、时间片、负载均衡等策略选出线程B，恢复它的全部上下文，最后回到用户态继续执行线程B。
如果切换的是进程，事情更麻烦。因为地址空间变了，页表基址寄存器要换，TLB（快表）里的映射基本全部作废。下一波内存访问大概率都要去查页表，可能还要触发缺页中断重新建映射。这个成本比单纯保存几个寄存器高一个量级。
那你也许会问，线程切换虽然不用换地址空间，是不是就没什么缓存损失？也不是。线程B跑的代码和数据大概率跟线程A不在同一个地方，之前的指令缓存、数据缓存、分支预测历史都帮不上忙，等于把CPU的“短期记忆”全部清掉重来。
2.2 教科书不写的隐性成本：缓存、TLB与分支预测
我在学习操作系统时，很长一段时间以为上下文切换的开销就是“保存寄存器 + 恢复寄存器”，实际上寄存器保存只是很小一部分。
现代CPU性能依赖两个核心机制：缓存和分支预测。缓存靠局部性原理，预设你接下来访问的地址大概率在刚才访问过的地址附近；分支预测靠历史规律，预设这次跳转跟以前多数情况一样。上下文切换直接打断这两个机制，取指和访存都踩空，流水线不得不停顿等待。高频切换下，CPU真正花在“重新热身”上的时间可能比执行用户代码还多。
这也是很多性能测试里的隐藏陷阱。同一个程序，线程数少的基准测试看起来很快，换到高并发场景突然变得很慢，原因之一就是切换频率上升后缓存命中率急剧下降。所以评估并发模型的性能，不能只看单次切换到多少微秒，更要看“单位时间里发生了多少次切换”。
2.3 协程为何能省掉大头开销
协程切换不需要陷入内核，只发生在用户态。一个协程让出CPU时，用户态调度器只需要保存少量寄存器、栈指针和当前执行位置，从就绪队列里取出下一个协程，恢复这些状态，继续运行即可。这个过程里没有任何特权级切换，不碰内核调度队列，也不用刷新页表。
如果继续用生活类比的话：线程切换好比两个人交接班，要先把文件柜钥匙交还门卫，再由门卫登记、通知下一个人进来拿钥匙；协程切换则是同一办公室里两个同事站起身换个座位，连门都不用出。
但这里必须补充一个前提，协程也不是完全绕开操作系统。协程真正发起IO操作时，最终还是要去内核态，只是借助非阻塞IO机制实现了“等待时不占线程”。它把从内核态进出的次数压缩到最少，而不是完全消除。理解这一点很重要，否则容易以为协程能彻底突破操作系统限制，那是误解。
3. 并发模型选型：负载类型决定答案，而不是流行程度
3.1 一张选型对照表与它的适用边界
很多技术文章喜欢说“某某模型最好”，这是误导。模型没有绝对优劣，只有匹配不匹配。我自己在实际项目中沉淀了一套初步选型判断表，算不上万能，但能覆盖大多数场景。
| 业务特征 | 建议模型 | 核心原因 |
|---|---|---|
| 多个服务模块需要强隔离，防止崩溃互相蔓延 | 多进程 | 故障隔离最彻底，一个进程崩溃可由其他进程接管 |
| 单机内多核并行，任务以CPU计算为主 | 多线程，线程数接近核心数 | 利用多核并行，共享内存方便，同步模型相对成熟 |
| 高并发接入层、网关、消息转发，IO等待占比高 | 多线程 + 协程组合 | 用少量线程承载大量并发，等待时让出CPU |
| 任务创建销毁频繁，但执行时间短 | 线程池 / 协程池 | 复用对象，避免频繁创建销毁的固定成本 |
| 任务执行时间长、数量相对有限 | 常驻线程或独立进程 | 协程的调度收益被长任务稀释，反而增加复杂度 |
这张表的边界在于它是一个“起点”而不是“终点”。真实系统往往混合了多种负载，所以我建议先用它判断主要矛盾，再针对热点路径做微调。
3.2 CPU密集与IO密集：两种负载为什么走向相反
选型之前有一件事必须先做：判断你的任务是CPU密集还是IO密集。这条判断可以说是并发选型的分水岭。
CPU密集型任务的特点是几乎没有等待，比如视频转码、大规模数学计算、批量图像处理。这时并发模型的核心目标是“让每个核心都在干活”，线程数大约等于CPU核心数即可。线程再多，CPU也只会把时间花在切换上，而不是计算上。这种情况下协程也没有明显优势，因为没什么等待可以让出。
IO密集型任务恰好相反，CPU大部分时间是空闲的，都在等网络响应、等磁盘、等下游服务。一个线程发起一次网络请求，然后傻等几百毫秒，这几百毫秒里线程占用的内核栈、调度实体、缓存资源全都在空转。如果一千个并发请求就开一千个线程，大量资源就浪费在“等待”上。这时用少量线程配合协程，让每一个线程内的执行流在IO等待时切换到其他协程继续跑，才是把CPU利用起来的正确姿势。
我见过不少人把这两种负载混淆，结果把一个CPU密集的服务设计成几万协程并发跑，性能反而下降。方向搞反以后，任何并发模型都救不了。
3.3 一个典型Web接入服务的执行流：线程池与协程如何搭配
以最典型的Web接入服务为例。这个服务的核心工作就是接收请求、转发给下游、拿回响应、返回给客户端。整个过程里真正的计算很少，大头是等待下游网络IO。
如果只用线程池，线程数至少要等于并发请求数的平均值，而每个请求的等待时间又远大于计算时间，线程经常处于BLOCKED状态。如果只用纯粹的"单线程 + 事件循环"，确实能支撑大量并发，但一旦遇到某个CPU密集型的任务，比如序列化一个超大对象，整个事件循环都会被卡住，系统整体响应变慢。
最稳的组合是：线程池负责提供真正执行路径所需的执行流，每个线程内再挂一个协程调度器，把IO等待做成协程挂起点。等待发生时，执行流让给线程池里的其他协程；计算发生时，仍然可以占满多个CPU核心。这样既保留了多核并行能力，又不会让线程数随并发数线性增长。
提示：“用了协程就不需要线程”是最大的误解。协程只是用户态的执行流，真正发起系统调用、真正跑在CPU核心上的仍然是线程。协程解决的是线程内部的并发度，而不是替代线程。
4. 协程内部的调度世界：状态机、栈与事件循环
4.1 有栈协程与无栈协程：两种实现风格的代价与收益
协程的实现不是只有一种，理解它的内部机制，才能知道为什么有些语言里的协程特别好用，有些则用起来很蹩脚。
有栈协程，每个协程有自己独立的栈空间，切换时保存当前栈指针、寄存器、执行位置，后续直接从保存点恢复。好处是写法接近同步代码，函数调用中间也能挂起，返回之后还能继续执行，程序员几乎感知不到“这段代码会挂起”。坏处是每个协程要预先分配栈空间，几万甚至几十万个协程的内存占用会明显上升。
无栈协程不维护独立栈，而是在编译期把函数按挂起点拆成一个个状态片段。运行时只需保存一个状态编号和少数关键局部变量，挂起和恢复时不需要保存整个调用栈。好处是内存占用极低、切换开销更小；坏处是挂起和恢复必须依赖显式的await或yield语法，而且一旦有深层函数调用链，状态机的拆分会非常复杂。
有意思的是，很多成熟的异步框架虽然对外统一叫“协程”，内部实际是编译期状态机加上运行时对象池的组合。理解有栈和无栈的区别，有助于你判断一个协程框架为什么在某些场景下内存暴涨，为什么在另一些场景下挂起失败。
4.2 调度器的三个核心数据结构：就绪队列、等待队列、事件表
不管是有栈还是无栈协程，它在运行时最终都归一个用户态调度器管。这个调度器并不高深，核心就是几个数据结构和一套状态转移规则。
就绪队列存放所有可以立即执行的协程。事件表记录协程正在等待什么，比如“等待某个socket可读”“等待某个定时器到期”“等待某把锁释放”。等待队列可以看作事件表的反向索引，方便事件到来时快速找到对应的协程并唤醒它。
调度循环的伪代码大致是这样：
调度主循环： 1. 从就绪队列取出一个协程 2. 执行它，直到遇到挂起点或执行结束 3. 如果挂起： - 因IO等待：注册到事件表，放入等待队列 - 因主动让出：直接放回就绪队列尾部 - 因等待锁：放入锁等待队列 4. 当IO事件到达、定时器触发或锁释放时 将对应协程放回就绪队列 5. 回到步骤1这个循环配合事件驱动IO，就构成了底层机制。顺着这个视角再看那些高并发的中间件，你会发现它们的骨架大同小异：线程池承载真实的系统调用，事件循环做协程调度，IO就绪事件做唤醒触发。
4.3 用伪代码理解一次“挂起—恢复”的完整生命周期
光看调度循环还不够，我们把一个协程的一生串起来。
假设有个协程需要读取一个网络连接的数据，但数据还没到。它发起非阻塞读，返回“暂无数据”，这时它主动挂起，并把“我在等这个连接可读”登记到事件表。调度器看到它挂起，就从就绪队列里拉出下一个协程继续执行。一段时间后，网卡收到数据，事件通知触发，调度器查事件表找到刚才那个协程，把它放回就绪队列。等它再次拿到CPU，它从挂起点之后继续执行，读取已经到达的数据。
整个流程里，最贵的操作是网络事件通知本身，但它的频率远低于线程模型里每次都切换线程的频率。这就是协程能把并发撑到很高的根本原因：把“每次等待都切线程”变成“每次等待只登记事件”。
5. 一次线上问题复盘：线程池耗尽背后的负载错配
5.1 事故现场：线程池全满而CPU却闲着
分享一个真实项目里处理过的问题，隐去业务细节，只讲流程。
某个负责请求转发的服务，某天突然开始出现大面积超时，报警持续不断。一开始所有人都会惯性怀疑下游数据库或缓存变慢，但监控数据显示数据库负载正常、中间件也没有异常。直到点了好几次线程池监控，才确认问题出在“线程用光了”。
现象非常典型：线程池活跃线程数长期顶满，队列不停积压，新请求还没被执行就已经超时。而CPU使用率只有不到20%，说明这些线程绝大多数不是在计算，而是在等待。
5.2 排查链路：三张关键观测图定位根因
复盘时我们把排查过程拆成三步，每一步都对实测结果有决定意义。
第一步，看线程池活跃度曲线。活跃线程数长时间顶满，说明瓶颈是持续性的，不是偶发流量尖峰。这里要排除“瞬时抖一下又恢复”的情况，所以观察窗口拉到了连续几个小时。
第二步，抓线程运行位置。连续抓了多次现场快照，然后做调用栈统计，结果大量线程停在读取下游响应的IO等待上。也就是说线程没有死锁，也没有死循环，就是单纯地等在等外部响应。
第三步，看CPU与IO的关联。服务端CPU低，下游响应时间高，串起来就是：高并发导致大量线程同时在等待IO，线程池被等待占满，新的请求根本没有执行机会。CPU虽然有剩余，但已经没有执行流去用它。
这个链路非常重要。很多人排查线程池耗尽问题时，第一步就去看代码逻辑，反而忘了先看观测数据。数据的指向已经很明确，不需要再绕弯。
5.3 改造结果与定量对比
定位之后，我们把服务从纯粹的线程池模型，改成“少量线程 + 协程”模型，让每个IO等待都变成协程挂起。线程池从几千降到几十，单机吞吐量反而提升了一个大台阶，超时率归零。
改造前后的对比大概是这样的：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 线程数 | 数千 | 数十 |
| 单机吞吐量 | 基线 | 数倍提升 |
| 超时率 | 居高不下 | 归零 |
| CPU使用率 | 不足20% | 提升到合理区间 |
这个案例给我的教训是：线程池本身没有错，错的是把它用在了一个等待远多于计算的负载上。换成CPU密集型的短任务集合，这套方案可能又会变成灾难。所以遇到性能问题，第一反应不应该是“换一个新模型”，而是先搞清当前负载属于什么类型。
6. 并发共享的暗礁：可见性、原子性与同步手段的真实成本
6.1 一个看似简单的自增操作，在CPU层其实是三条指令
并发模型选得再好，只要涉及多个执行流共享状态，就绕不过同步问题。这里最常见的一道坎，就是很多人对“一行代码”在CPU到底做了什么没有概念。
比如执行“count++”，习惯上认为这是一次操作，但在CPU层面它至少包含三条指令：从内存读count到寄存器、寄存器加一、把新值写回内存。如果执行流A加了一半被切换走，执行流B也在做一次“count++”，两个执行流可能都读到同一个旧值，然后分别加一写回，最后count只增加了一次。
这就是原子性问题。很多人把它理解成“操作没做完就被打断”，其实本质是“检查并修改”这一整个步骤没有被整体执行，被拆成了多步，而中间可以被其他执行流插进来。
6.2 可见性带来的“幽灵修改”：改了却像没改
比原子性更容易让程序员崩溃的是可见性问题。
一个线程修改了一个共享变量，修改结果可能暂时只停留在CPU缓存里，没有同步到主存。另一个线程在其他核心里运行时，读到的还是内存里的旧值。结果你看到的现象是：代码逻辑上明明已经修改了变量，但另一个线程就是读不到最新值，就像这个修改是“幽灵修改”一样。
这种问题不会每时每刻发生，但在某些缓存刷写时机下会周期性出现。线上服务偶尔出现的诡异异常，很多都源于这种时序问题，而不是业务逻辑本身写错了。
解决可见性需要内存屏障或者同步工具，常见的做法是给共享变量加锁，或者使用具有发布语义的原子操作。这些手段的核心作用不只是让代码“看起来安全”，而是确保修改对所有执行流可见。
6.3 互斥锁、原子操作与无锁结构的性价比比较
面对这些问题，可选的手段并不多，各有各的成本。
互斥锁是最直接的手段，但它有两个代价：阻塞时内核态切换，以及锁持有期间的串行化。共享数据访问频繁时，锁竞争会导致线程排队，延时增长很快。读写锁在“读多写少”场景下效率更高，但写优先还是读优先需要根据业务权衡。
原子操作避开了内核切换，基本靠CPU指令完成，在竞争不激烈时性能远好于锁。但如果竞争激烈，CAS自旋重试会反复占用CPU，浪费程度不亚于锁。
无锁数据结构听起来很美，但它对内存模型、生命周期管理、ABA问题等要求都极高，常规团队不建议主动引入。我的经验是：先用锁写出正确版本，压测发现确实是锁瓶颈时，再用原子操作做局部优化。为了“显得高级”而引入无锁结构，往往会让问题更难排查。
协程在这种语境下能带来一些便利：单线程内运行的一组协程，同一时刻只有一个在执行，天然避免了一部分竞争问题。但一旦多个线程里的协程共享状态，锁和原子操作一个都跑不掉。最近几年我经常看到有人误以为“协程 = 并发安全”，结果只是把竞态问题从线程层搬到了协程层，该出的Bug一个都没少。
这样一个完整的流程下来，基本上把进程、线程、协程的成本模型、适用场景和容易踩的坑都梳理了一遍。回想我自己最开始学这一块的时候，也是被各种概念绕得头晕，真正想明白是在线上服务出了两次事故之后。要是能早点有人告诉我“先看负载类型，再选并发模型”，大概能少走不少弯路。希望这篇把该说的坑都说明白了，至少在你自己做技术选型时，可以多一个判断的依据。
