进程、线程、协程，这三个关键词在操作系统和并发编程里几乎每天都要碰面。第三十六篇操作系统专题正好轮到它们，上一篇已经梳理了基本概念，这一篇继续往下挖几个真正影响编码和排障的深层机制：内核到底怎么调度线程、锁和原子操作各自解决什么问题、死锁为什么常常一夜之间让服务“噤声”、以及协程凭什么在用户态跑得飞快。这篇文章适合正在啃操作系统的学生、准备并发面试的开发者，也适合那些被线上卡死问题逼到去看线程栈的人。我不打算只堆名词，尽量把每个设计背后的“为什么”一起说清楚，看完你会发现，很多面试题和线上故障，其实是同一件事的两面。
1. 为什么线程比进程“轻”，调度模型帮我们想清了这件事
1.1 进程是资源容器，线程是执行流水线
从系统角度看，进程是资源分配的基本单位：地址空间、文件描述符、信号处理器都挂在进程名下。而真正被CPU调度执行的，是进程内部的线程。进程好比一间工厂，线程是流水线上的工人，工厂负责采购原料和设备，工人负责干活。一个进程至少有一个线程，多线程进程共享地址空间和资源，每个线程只需要维护自己的栈、寄存器上下文和线程控制块。
所以线程的创建比进程创建省钱，不是玄学，而是设计使然。创建进程要分配独立的地址空间、复制页表、建立文件表等一套资源；创建线程则是同一份资源大家一起用，操作系统只需要新分配一个栈和控制块。切换时同样如此，进程切换往往要换地址空间、刷TLB，而同一进程内的线程切换不需要动页表，代价自然更小。这也是多线程模型能成为主流的根本原因：宁可在一个进程里多开几条流水线，也不要一个任务就盖一座工厂。
1.2 三种线程映射模型的历史选择
这里还要区分两类线程。用户线程由线程库在用户空间管理，内核完全看不见它；内核线程才是操作系统内核直接调度和管理的执行流。用户线程到底怎么映射到内核线程，历史上出现过三种典型模型。
多对一模型：多个用户线程映射到同一个内核线程。所有调度都由线程库在用户态完成，切换不需要陷入内核，所以非常快。但致命问题也在这：只要其中一个线程做了一次阻塞式系统调用，整个进程的所有线程都会被卡住；而且进程只对应一个内核线程，多核CPU对它来说形同虚设。这个模型如今已经很少单独出现。
一对一模型：每个用户线程对应一个内核线程，主流操作系统普遍采用这种模型。它的优点是线程阻塞互不影响，多核并行能力充分，接口清晰，编程模型简单。缺点也直接：线程的创建和切换都要通过内核，每次都带着系统调用开销，线程数量更不能无节制增长，否则内核维护的上下文会吃光内存。
多对多模型：N个用户线程映射到M个内核线程，N大于M。设计目的是想同时吃到两边的红利：用户态线程库负责尽量廉价的切换，底层还能占着多个内核线程跑多核。但实现复杂，用户态调度和内核调度两层之间还要协同，细节一旦处理不好，效率反而不如一对一。
1.3 模型选型的现实约束：不是越复杂越好
实际选型往往不是越复杂越好。一对一模型能成为主流，一个重要原因是内核调度器在现代系统上已经优化得足够好，而“频繁创建销毁线程”的痛点，早就靠线程池这个老办法解决。对大多数应用来说，用户根本不需要自己维护两层调度。多对多模型听着很美，但它把复杂度从内核挪到了用户态线程库，收益却未必撑得起这个复杂度。
如果你的业务是海量网络连接，多线程方案会先遇到线程数量太多的问题，这时候更应该考虑协程，也就是后面专门聊的用户态调度玩法。简而言之：多线程模型解决的是“如何在多个核上同时跑多个任务”，协程解决的是“如何在一个线程里把等待的时间也利用起来”。两者不冲突，但场景要分清楚。
2. 同步互斥：锁、条件变量与原子操作到底在解决什么
2.1 竞态不是玄学，是三条指令错位
两个线程同时对同一个变量自增，表面上一行代码，编译后其实是load、add、store三条指令。线程A把变量加载到寄存器，还没来得及写回，线程B也加载了同一个旧值，两边各自加一，最后写回的新值只增加了一次。这种结果依赖线程执行时序的bug，就是竞态条件。临界区指的就是需要“排他执行”的那段代码区间，互斥锁是最基础的排他工具：谁持有锁谁进，其他人等在锁上。
有一个初学者特别容易忽略的点：锁保护的不是变量，而是访问变量的代码路径。如果有的路径加锁，有的路径不加锁，锁照样拦不住竞态。我在某项目里见过类似的线上事故：只在写配置时加锁，另一个线程读配置时忘加，结果读到了一个写了一多半的配置快照。所以加锁之前先问一句：所有可能触碰这份数据的路径，都进了同一扇门吗？
2.2 五类同步原语的区别与选型
互斥锁、自旋锁、读写锁、条件变量、信号量，这五个名字大家都不陌生，但什么时候用哪个，很多人是靠猜的。我习惯按临界区的特征来分：
- 互斥锁：没有竞争时开销小，有竞争时线程会休眠等待。适合临界区比较长、竞争可能比较大的场景。
- 自旋锁：获取不到锁时忙等待，不放弃CPU，一直轮询。适合临界区极短、多核环境，因为省掉线程切换的开销。单核CPU上加自旋锁会坑自己：持有锁的线程还没运行完，等锁的线程占着CPU空转，形成死等。
- 读写锁：多个读线程可以并行，写线程独占。适合缓存类读多写少的场景。
- 条件变量：本身不是锁，必须配合互斥锁使用，让线程在资源不满足时挂起等待，条件满足后再被其他线程唤醒。典型用法是生产者—消费者队列。
- 信号量：一个计数器加一个等待队列，用来控制同时访问资源的数量。和互斥锁的区别是，它允许N个线程同时进入，不强调“唯一持有者”。
选型的核心逻辑就是一句话：锁的粒度要和你操作的时间成本匹配。临界区只有几条赋值语句，用互斥锁反而可能比自旋锁慢，因为线程休眠唤醒的代价远大于空转几次；临界区要做IO或复杂计算，就老老实实用互斥锁，把CPU让给其他线程。
条件变量这里单独提醒一句：等待条件时应该用while循环重复检查，而不是if。原因是存在虚假唤醒的可能，也可能在唤醒和重新拿到锁之间，条件又被其他线程改掉了。这是生产者消费者队列里极其常见的bug来源，很多偶发卡死问题追到根上都是这一行写错。
2.3 无锁之路：CAS、ABA与内存序
很多场景其实可以不用锁，直接靠硬件支持的原子指令。比如自增在常见的CPU指令集上有原子加法指令，读改写逻辑可以用CAS（比较并交换）：先读旧值，计算新值，再用CAS把新值写回去；如果期间被别的线程改过，CAS失败就重试一轮。无锁编程的思路在并发计数器、状态标记这些场景里很常见。
但无锁不等于无坑。最经典的坑是ABA问题：线程A读到的值是V，期间线程B把它改成W又改回V，线程A再做CAS时发现仍然是V，以为没人动过，实际上已经被动过一轮了。如果只关心最终值，ABA通常无所谓；但如果数据结构带指针语义，比如无锁栈里，ABA可能让整个链表结构失效。解决思路是加版本号，CAS时同时比对版本，或者用带标记的指针方案。
还要补充一点：锁和原子操作的底层，都涉及内存序问题。CPU为了性能会乱序执行指令，普通变量读写可能在多核之间出现“看起来”顺序颠倒。锁的语义自带内存屏障约束，保证unlock之前的写操作对其他线程可见；而手写无锁代码时，就必须自己处理内存序问题，否则测试跑一万次不出错，上线说不定就崩。
3. 死锁：四个条件、两类策略、一次印象深刻的实战
3.1 死锁的四个必要条件与预防思路
死锁发生的充要条件，教科书上写得很清楚，四个条件必须同时满足：互斥、持有并等待、不可剥夺、循环等待。互斥是资源本身的属性，很多场景改不掉；持有并等待，可以通过一次性申请所有资源来破坏；不可剥夺，可以通过允许强制回收来破坏；循环等待，可以通过资源编号、按序申请来破坏。工程上最常见的做法，就是破坏“循环等待”。
给所有要竞争的资源定一个全局唯一的编号，任何线程都要按编号从小到大的顺序申请，不允许跳跃。这样即使每个任务需要多个锁，也不会出现交叉等待环。编码上实现不难，难的是团队约定和持续约束。我见过一个系统，规范写得很漂亮，但新同学在某个私有路径里提前拿了一把大锁，结果还是死锁。代码评审的时候，一旦看到锁顺序不统一，就要当场提醒。
死锁避免层面，还有一个经典理论叫银行家算法。它抽象了操作系统分配资源的场景：每次分配前，系统先做一次安全性检查，判断这次分配会不会让系统进入不安全状态，如果会就拒绝。银行家算法在理论上有价值，但在实际复杂业务里很少完整实现，因为“每个线程最多还需要多少资源”这件事本身就很难准确预估。现实世界通常是“预防+检测+超时”组合拳。
3.2 排查死锁的方法论
线上出现死锁时，现象往往很有辨识度：进程还活着，CPU很闲，但某个业务量直接归零，日志卡住不动。不同系统的排查工具不一样，但思路一致。
第一步，获取故障进程的线程栈转储，把所有阻塞中的线程列出来。第二步，顺着每个线程的栈帧，找出它持有哪些锁、正在等待哪些锁。第三步，画出“线程A持有x等待y，线程B持有y等待x”这样的等待环，基本就能实锤。第四步，沿着调用链定位到具体代码行，再回去看锁的获取顺序。
有一次我排查一个定时任务卡死的问题，一开始所有人都以为是数据库连接池满了。但拿到线程栈之后发现，线程A持有配置锁，在等任务队列的锁；线程B持有任务队列锁，刚走到半路想读配置。两个线程连在一起，叫不醒的循环等待，就这么简单。如果不是看栈，光靠猜数据库超时，可能要猜一晚上。
3.3 修复策略和活锁那个更隐蔽的兄弟
死锁修复策略通常有两类。第一类是等待超时：获取锁时带上超时时间，超时就回滚当前操作并重试，避免无限等下去。第二类是统一锁顺序：所有模块按同一份资源编号顺序取锁，从根源上断掉等待环。这两类不是二选一，线上系统往往同时用：锁顺序是设计规范，超时是兜底机制，让死锁最多表现为“偶发失败”，而不是“永久卡死”。
死锁还有一个更隐蔽的兄弟叫活锁。活锁里线程并没有放弃，而是在不断释放资源、重试、再失败、再重试，CPU跑满但业务毫无进展。活锁比死锁难排查得多，因为线程栈里看不到互等环。遇到这种情况，我会先看重试次数和退避策略——很多活锁都是因为没有加入随机退避，两个线程互相谦让，结果永远撞不到正确时机。引入随机等待或指数退避，往往立刻见效。
4. 协程：用户态调度凭什么更快
4.1 协程与线程切换的成本差异
协程是一种完全在用户态管理的执行流，内核不知道它的存在。线程调度要经过内核来决定“下一个运行谁”，协程的调度由程序自己决定“我现在让出执行权，交给谁继续跑”。所以协程切换不用调用操作系统接口，只需要在用户态保存和恢复少量上下文，把栈指针、程序计数器、通用寄存器保存好，再把目标协程的上下文装回来，全程不触发系统调用。
线程切换贵在哪里？线程切换要进入内核态，经过内核调度器的处理，从用户态陷入内核再返回用户态，这本身就是一笔不小的开销。同一进程内的线程切换虽然不涉及页表切换，但不同线程的栈、执行路径对缓存不友好，切换后缓存命中率掉一截也很常见。协程切换全部留在用户态，不碰这些，自然便宜。具体差多少倍，不同平台差异很大，但“同样的吞吐下，协程方案占用资源少一个数量级”，在IO密集场景里确实是常见现象。
4.2 栈式协程与无栈协程的实现取舍
从实现形态上，协程大体分两种。栈式协程给每个协程一套完整的调用栈，可以在任意嵌套的函数里挂起和恢复，用起来非常灵活，但每个协程都占一块栈内存，量级通常几十KB起步。无栈协程把挂起点编译成状态机，不保存完整调用栈，只保留执行状态和局部数据，内存更省，但挂起和恢复的位置受到一定限制，不能在深层函数调用里随意让出。
选型要看具体场景。大量并发连接、每个连接状态简单，用无栈实现很合适；需要在深层函数调用中随时挂起的库代码，栈式协程写起来更顺手。如果你在用某个现代编程语言做高并发网络服务，大概率已经接触过这两种实现中的一种，只是平时没注意底层差异。
4.3 协程的适用边界：IO密集与CPU密集
协程擅长IO密集场景：大量请求在等待网络、等待数据库返回，CPU基本闲着，传统多线程方案里一个连接一个线程，几万个连接就能把系统线程数量干爆。协程可以几万个并发只占很少内存，配合事件循环和异步IO，把“等待”的时间省出来去处理别的请求，这正是高并发网关和后端服务疯狂拥抱协程的原因。
但协程并不会让CPU变多。它还只是在单个线程上轮转执行，如果真的有一个CPU密集任务——比如图像渲染、复杂计算——四个核就是四线程收益封顶，换更多协程也顶不上多一个核。这种场景该开线程并行还是要开线程。理解这件事，你就不会再被“协程万能论”带偏。
5. 实战中的线程与锁：参数、避坑和面试速答
5.1 线程池大小怎么定：两条经验公式
线程池大小的经验公式，面试里常问，项目里更容易抄错。对CPU密集任务，线程数设为CPU核数+1比较合理，多出来的那一个用来弥补偶发缺页或系统停顿。对IO密集任务，设成核数乘以某个系数更合适，常见经验值是2，但更准确的做法是根据“等待时间/计算时间”来估算，整体线程数约等于CPU核数乘以一倍加这个比值。
我见过一个项目，8核机器上开了60个线程去调外部接口，结果接口还没打满，先把数据库连接池压垮了，成功率和CPU一起崩。后来把线程数压到16，配合连接池限流，表现反而稳了。多说一句：线程不是免费的，每个线程都占栈空间，数量上去之后，内核调度和上下文切换的开销会吃掉吞吐量。多线程设计要先想清楚瓶颈在哪，是CPU、数据库连接还是下游服务，线程数应该跟着瓶颈资源走。
5.2 锁粒度和伪共享，两个容易被低估的细节
锁粒度过大，整个系统退化成串行；锁粒度过小，锁数量变多且嵌套复杂，容易把自己套进死锁。我倾向先用粗粒度锁保证正确性，再通过压测找热点，最后把热点锁细分。这个顺序比一开始就精雕细琢一堆细锁要稳得多，因为锁粒度调整极易引入正确性问题。
伪共享则是个更隐蔽的性能杀手：两个线程各自修改不同变量，但这两个变量恰好落在同一个缓存行上，导致缓存行在两个核之间反复失效，看起来像锁竞争，实际上并没有锁。解决起来也不复杂：按缓存行对齐填充、把热点变量单独放在一个缓存行大小的结构里，或者干脆用线程本地存储。排查这类问题需要看CPU缓存一致性相关的性能计数器，如果你发现某个“无锁”数据结构在多线程下性能反而诡异，优先怀疑伪共享。
5.3 常见问题速查表与面试一句话答法
把常见症状、可能原因、排查动作整理成一张表，方便直接照着查：
| 症状 | 可能原因 | 优先排查动作 |
|---|---|---|
| 业务卡死，CPU很低 | 死锁 | 获取线程栈转储，找“持有锁等待锁”的环 |
| CPU饱和，吞吐上不去 | 线程过多，上下文切换频繁 | 检查线程总数指标，收缩线程池 |
| 耗时抖动明显，无明显锁 | 伪共享或系统层干扰 | 查缓存相关性能指标，检查结构体布局 |
| 偶发失败，重试又正常 | 活锁或锁超时回滚 | 看退避策略，加入随机退避 |
如果面试官让你用30秒说清进程、线程、协程的区别，我会这样答：进程是资源隔离的边界，线程是内核调度的基本单位，共享进程资源；协程是用户态自调度的执行流，不占内核调度资源。换线程的开销在模式切换和内核调度，换协程的开销只是恢复一个上下文结构体，协程通常用来扛高并发IO，但真正的并行还是要靠多线程或多进程。最后补一句“协程只是让单线程里的等待不再浪费CPU”，这句话往往是加分项。
我自己踩得最狠的一次死锁，是在两个服务互相调用的回调链路里。两边各自持有自己的锁，再去拿对方的锁，线上卡了很长时间才抓到完整调用栈。那次之后我给自己定了条规矩：凡是涉及多个锁的代码，锁顺序必须写进注释，评审时专门检查有没有违反顺序的调用。另一个小技巧是给锁加超时，把“死锁”变成“偶发失败”，系统至少能自愈。这些经验用一次就够了，希望这篇文章能帮你省下那半小时的排查时间。
