进程、线程、协程这几个词大概是计算机相关专业绕不开的“老三样”。工作几年以后你会发现真正决定一个服务并发上限的并不是用了什么高深的框架而是你对这三个概念的理解深度。这一篇是这个系列的第三十六篇也是操作系统专题里关于并发基础模型的第二次展开。上一篇我们已经把定义和基本特性过了一遍这一篇直接照进现实它们之间到底谁更轻代价差在哪相同负载下选错模型的后果是什么也许有人会问现在的框架都封装得很好写业务代码时根本不直接创建进程还要不要搞清楚这些原理我的回答是需要。因为几乎所有异步框架、并发中间件、池化组件的底层设计都建立在“进程、线程、协程分别适合什么负载”这个判断之上。你不一定要自己造轮子但至少得看得懂别人造的轮子还得知道自己的车适合用哪个轮子。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一个都没少。这样一个完整的流程下来基本上把进程、线程、协程的成本模型、适用场景和容易踩的坑都梳理了一遍。回想我自己最开始学这一块的时候也是被各种概念绕得头晕真正想明白是在线上服务出了两次事故之后。要是能早点有人告诉我“先看负载类型再选并发模型”大概能少走不少弯路。希望这篇把该说的坑都说明白了至少在你自己做技术选型时可以多一个判断的依据。