进程同步四大经典模型：死锁、信号量与并发故障排查

凌晨两点被叫起来救一个服务假死的场日志停在某一行不动进程活着CPU 几乎为零所有请求都超时。抓线程栈一看两个工作线程一个卡在入队、一个卡在出队各自握着一把锁等着对方手里的条件变量。那段代码当初是从教科书上的生产者消费者模型抄来的连变量名都没改。那次之后我把进程同步的几个经典模型重新从头捋了一遍——司机售票员问题、生产者消费者问题、哲学家进餐问题、读者写者问题。这四个问题看着像课堂作业实际上它们是四类并发故障的原型纯同步、同步加互斥、资源竞争死锁、共享读多写少的配额争夺。任何一个线上并发 bug往根上刨基本都能归到这四个模型里的一个或者它们的组合。这篇内容我打算按每个模型为什么长成这样、代码怎么写、哪一行写反就炸、炸了怎么查的顺序讲透适合刚学完操作系统课但一到工程里就懵的人也适合写过并发代码但没系统梳理过的人。1. 先把四个问题摆到同一张坐标纸上很多人学这四个问题是分开学的学完感觉是四套互不相干的解法。其实它们是同一件事在不同约束下的展开先看清楚坐标系后面的代码才有地方挂。1.1 互斥和同步不是一回事别混着用互斥解决的是同一个资源不能同时被两个人碰比如两个线程同时往一个计数器上加一最后结果少了一次这是竞态条件。同步解决的是两件事必须按某个先后顺序发生比如必须先把数据写进缓冲区读的一方才能去取。互斥是同步的一种特例但很多人写代码时脑子里只有加锁这一个动作于是把顺序约束也当成互斥来处理结果要么过度加锁把并发度锁死要么漏掉顺序判断导致逻辑错乱。判断一个场景到底需要什么我的习惯是问三个问题有没有共享的可写数据有几个执行流会碰它它们的动作之间有没有先后要求三个答案里第二个是有就必须考虑互斥第三个是有就必须考虑同步。两个都是有那就是双重约束四个经典问题里除了司机售票员其余三个都是双重约束。1.2 四个问题各自卡在哪个点上把这四个问题拆成参与者、共享资源、核心矛盾、最容易犯错的地方四列一眼就能看出它们的分工问题参与者共享资源核心矛盾最易出错处司机售票员司机、售票员车辆状态停/行纯顺序依赖无共享数据竞争信号量初值设错导致一开始就互等生产者消费者生产者、消费者有界缓冲区既要互斥访问缓冲区又要判断空/满P 操作顺序写反满缓冲区时死锁哲学家进餐5 个哲学家5 根筷子两两相邻共享多资源竞争循环等待全员先拿左手边形成环形等待读者写者读者、写者一份共享数据读读可并发读写/写写互斥还需计读者数忘记计数导致写者永远等不到注意第二行和第四行的区别生产者消费者的缓冲区是一个整体资源所有人抢同一个锁哲学家问题的资源是一组离散资源每个人要两把抢的方式不同死锁的形态就完全不同。读者写者则多了一层计数——读者数量本身就是需要保护的共享状态这层套嵌是它比前两个更绕的根本原因。2. 司机售票员两个信号量就能说清顺序依赖这是四个问题里唯一不涉及数据竞争的纯粹考顺序也是最适合拿来入门的。2.1 规则拆解成两条单向的等待场景是这样的一辆车司机负责开和停售票员负责开和关车门。硬性规则只有两条——车门没关好司机不能启动车没停稳售票员不能开门。注意这两条都是单向的不是互相等而是各自等一个前置条件成立。这种我等你的信号的结构最自然的表达就是两个信号量每个信号量代表一个条件的成立与否semaphore door_closed 0; // 门已关好的信号 semaphore car_stopped 1; // 车已停稳的信号初始车是停着的 // 司机进程 while (1) { P(door_closed); // 等门关好 start_engine(); drive(); // 正常行驶 arrive_and_stop(); // 到站停车 V(car_stopped); // 通知车停稳了 } // 售票员进程 while (1) { P(car_stopped); // 等车停稳 open_door(); passengers_exchange(); // 上下客 close_door(); V(door_closed); // 通知门关好了 }P 是申请条件不成立就阻塞V 是释放把条件置为成立并唤醒等待者。整段代码的逻辑就是两条等待链首尾相接形成一个稳定的循环节拍。2.2 初值为什么是 0 和 1 而不是两个 0这是新手最爱踩的坑。很多人觉得两个信号量初值都设 0 最安全于是写上door_closed 0; car_stopped 0;然后程序刚跑起来两个进程就都阻塞了谁也不会动。原因在于初值表达的是程序启动那一刻哪个条件已经成立。初始状态是车停着、门关着、司机还没发车。此时车已停稳这个条件是真的所以car_stopped初值必须是 1售票员才能拿到执行权去开门而门已关好这一刻还没发生售票员还没执行关门动作所以door_closed初值是 0司机必须等。改完之后跑一遍时序就通了售票员先拿到car_stopped开门上下客、关门、V(door_closed)司机拿到door_closed发车、到站、V(car_stopped)售票员再次拿到循环成立。整个系统只有一条执行路径不存在竞态。提示凡是写信号量第一件事是把初始时刻哪些条件为真列成一张清单然后逐个对应初值。初值不是凭感觉设的是由初始状态反推出来的。2.3 两个变量互换就变成另一个问题的变体如果把场景改一下售票员必须等司机把车停稳并且熄火才能开门司机必须等售票员确认所有乘客下完才能再次启动那就要再引入一个信号量把下客完成这个事件也编码进去。这就是这类问题的通用套路——每一个需要等待的事件对应一个信号量事件的先后关系对应 P/V 的配对。工程里对应的场景其实很常见比如初始化流程业务线程必须等配置加载线程完成加载才能继续配置线程加载完就V一下业务线程在入口P一下。写法上跟司机售票员一模一样只是没人会把它叫这个名字。3. 生产者消费者多出来的是容量这个约束司机售票员只有顺序没有共享数据所以简单。生产者消费者一开始就多了两个东西一是有界缓冲区二是空和满这两个状态判断。3.1 为什么三个信号量一个都不能少初学的人常想缓冲区是个共享资源加一把互斥锁不就行了不行。因为光有互斥只能保证不同时写保证不了没东西的时候不要读和满了的时候不要写。互斥锁只能告诉你现在没人用不能告诉你现在能不能用。所以需要三个信号量分工mutex初值 1保证同一时刻只有一个执行流在操作缓冲区的下标指针empty初值 N缓冲区容量表示当前还能放几个full初值 0表示当前有几个可取。empty和full是真正的同步信号量它们的值随生产消费动态变化且empty full N恒成立。这个恒等式是检查代码有没有写错的一个很好的抓手我在 review 别人代码时经常靠它快速判断有没有漏 V。3.2 环形缓冲区的标准写法#define N 8 semaphore mutex 1; semaphore empty N; semaphore full 0; item buffer[N]; int in 0, out 0; // 生产者 void producer() { while (1) { item it produce(); P(empty); // 先确认有空位 P(mutex); // 再抢缓冲区锁 buffer[in] it; in (in 1) % N; V(mutex); // 放完立刻还锁 V(full); // 通知多了一个可取 } } // 消费者 void consumer() { while (1) { P(full); // 先确认有货 P(mutex); item it buffer[out]; out (out 1) % N; V(mutex); V(empty); // 通知多了一个空位 consume(it); } }用环形数组而不是链表是因为下标自增取模就能复用空间不需要动态分配也不会因为频繁 malloc/free 引入额外的不确定性。in和out之间永远差着full个有效元素这个不变式在任何时刻都成立。3.3 P 的顺序写反会死锁而且死得很隐蔽把上面生产者里的两行换一下顺序写成先P(mutex)再P(empty)会怎样设想缓冲区已满empty 0。某个生产者抢到了mutex然后卡在P(empty)上阻塞。此时消费者想来取数据走到P(full)是能过的full N但紧接着P(mutex)就被挡住了——锁在生产者手里。于是消费者等锁生产者等空位而空位只能由消费者腾出来。循环等待成立死锁。这个 bug 的阴险之处在于缓冲区不满的时候它完全不发作压测跑一万次可能一次都不复现等到线上流量把缓冲打满的那一秒才炸。我见过不止一个团队在这个点上翻车。注意所有资源计数类的 P 操作必须在互斥锁的 P 操作之前。顺序永远是先拿配额再进临界区。这条规矩适用于所有带容量限制的队列实现。3.4 多个生产者和消费者同时存在时的额外考量上面的代码其实已经支持多生产多消费了因为mutex保护了下标读写empty/full保证了配额。但有两个细节容易被忽略。第一in和out是两个不同的变量理论上生产者和消费者改的不是同一个但这种看起来不冲突的判断在编译器重排和 CPU 乱序执行面前不成立所以它们必须放在同一个mutex保护下不能自作聪明地拆成两把锁。第二如果consume()是耗时操作一定要放在V(mutex)之后。放里面的话消费者拿着锁去做业务处理其他所有生产者消费者全部排队等锁并发度直接归零。这条我在 code review 里纠正过太多次属于能跑但性能烂的典型。4. 哲学家进餐资源是一组死锁是结构性的前两个问题的死锁都是写错代码导致的哲学家进餐不一样——按最直白的写法死锁是必然的不是概率的。这是它作为经典模型的价值所在。4.1 五个人五根筷子的死锁闭环五个人围一圈两两之间放一根筷子每个人要同时拿到左右两根才能吃。最直觉的写法semaphore chopstick[5] {1, 1, 1, 1, 1}; void philosopher(int i) { while (1) { P(chopstick[i]); // 拿左手 P(chopstick[(i 1) % 5]); // 拿右手 eat(); V(chopstick[i]); V(chopstick[(i 1) % 5]); think(); } }问题出在所有人同时执行到第一行。五个人各自拿起了左手边的筷子然后同时去拿右手边——而右手边那根正在右边那个人的左手里。五个人的等待关系首尾相接形成一个环谁都动不了。这就是死锁四个必要条件里的循环等待。死锁的四个条件是互斥、占有并等待、不可剥夺、循环等待四条同时成立才可能死锁。注意同时成立这个词它意味着只要破坏任意一条死锁就不成立。四种经典解法本质上就是四条破坏路径各选一条。4.2 四种破法各自破坏了哪一条方案做法破坏的条件代价限制人数加一个初值为 4 的信号量最多 4 人同时尝试循环等待凑不齐 5 人成环并发度上限降低第 5 人干等奇偶异序奇数号先左后右偶数号先右后左循环等待方向相反无法成环逻辑不对称代码可读性下降原子获取一次性申请两根全拿到才继续占有并等待不再持有等待需要额外的分配器或全局锁超时回退拿不到就主动释放已持有的退避重试不可剥夺主动放弃引入活锁风险需要随机退避工程里最常用的是第一种和第四种。第一种简单粗暴加一行信号量就完事第四种更通用因为真实系统里资源数量往往不是固定的 5而且允许重试。第二种在教学里漂亮但一旦筷子数量变成偶数或者不是环形排列就失效了。第三种在数据库事务里很常见一次性申请所有锁但在普通线程编程里实现成本偏高。4.3 限制人数方案的完整实现semaphore chopstick[5] {1, 1, 1, 1, 1}; semaphore limit 4; // 最多允许 4 人同时尝试 void philosopher(int i) { while (1) { P(limit); // 先占一个尝试名额 P(chopstick[i]); P(chopstick[(i 1) % 5]); eat(); V(chopstick[(i 1) % 5]); V(chopstick[i]); V(limit); // 吃完释放名额 } }为什么 4 就够因为要形成环必须五个人每人持有一根并等待下一根只允许 4 人进入尝试区最坏情况是 4 人各持一根但第 5 根一定在某个没进场的人手里闲着——不对这里要说准确4 人各持一根的情况下总共只被拿走 4 根剩下 1 根是空闲的必然有一个人能拿到第二根从而吃完释放环就打破了。提示limit的 V 操作一定要放在所有筷子的 V 之后。如果提前释放名额可能出现某个人还没放下筷子就放行了新人5 个人又凑齐了环重新形成。4.4 映射到真实场景多把锁的获取顺序哲学家问题在工程里的对应物极其常见一个对象需要同时持有 A、B 两把锁才能操作另一个路径需要 B、A。如果两个线程一个走 A→B、一个走 B→A就是标准的哲学家死锁。解决办法对应到工程里最实用的不是限制人数而是给所有锁定义一个全局顺序任何线程都必须按这个顺序获取。这就是奇偶异序方案的一般化——不是靠奇偶而是靠一个全局的排序约定。这条规矩非常好用我在设计任何需要持多把锁的模块时第一件事就是把锁编号写进注释然后 review 时专门盯获取顺序。5. 读者写者共享读的并发红利怎么兑现最后一个问题的特殊之处在于它承认了读读之间不冲突这个事实。前面三个问题里所有对共享资源的访问都是一视同仁地互斥读者写者第一次引入了访问类型的区分——读操作之间可以并行只有写才需要独占。5.1 读者优先版本与它的代价最经典的写法是用一个计数器记录当前有多少读者在阅读semaphore rw_mutex 1; // 读写互斥、写写互斥 semaphore count_mutex 1; // 保护 reader_count int reader_count 0; void reader() { P(count_mutex); reader_count; if (reader_count 1) // 第一个读者负责把写者挡住 P(rw_mutex); V(count_mutex); read_data(); P(count_mutex); reader_count--; if (reader_count 0) // 最后一个读者放行写者 V(rw_mutex); V(count_mutex); } void writer() { P(rw_mutex); write_data(); V(rw_mutex); }关键在if (reader_count 1)和if (reader_count 0)这两行。第一个进来的读者代表全体读者去抢rw_mutex后面的读者只需要给计数加一就能直接进最后一个离开的读者代表全体释放锁。这样读者之间完全不互斥并发度拉满。但代价是写者可能饿死。只要读者络绎不绝reader_count永远不归零rw_mutex永远不释放写者就一直卡在P(rw_mutex)上。在读者极多的场景缓存查询、配置读取写入请求可能几十分钟都拿不到机会。5.2 加一道公平闸门要避免写者饥饿思路是让读者和写者在入口处排同一个队semaphore rw_mutex 1; semaphore count_mutex 1; semaphore gate 1; // 公平闸门读者和写者都要先过 int reader_count 0; void reader_fair() { P(gate); // 排队 P(count_mutex); reader_count; if (reader_count 1) P(rw_mutex); V(count_mutex); V(gate); // 过闸后立刻放行后续读者仍可并发进 read_data(); P(count_mutex); reader_count--; if (reader_count 0) V(rw_mutex); V(count_mutex); } void writer_fair() { P(gate); // 和读者排同一个队 P(rw_mutex); write_data(); V(rw_mutex); V(gate); }这道gate的作用是写者一旦到达并抢到闸门后续到达的读者就被挡在门外无法再插队进来延续reader_count写者因此能等到当前这批读者全部离开。这是一个写者优先的近似实现也常被叫作公平策略。5.3 三种策略怎么选策略读者行为写者行为适用场景读者优先随时可进永不等待可能长期饥饿读远多于写、写实时性要求低写者优先有写者等待时读者排队来了就能尽快拿到写操作少但必须及时生效公平FIFO与写者同队与读者同队通用默认兼顾两边工程上大多数语言标准库提供的读写锁默认是某种公平策略。比如 C 的std::shared_mutex、Java 的ReentrantReadWriteLock都提供了公平与非公平两种构造方式。非公平版本吞吐更高公平版本延迟更稳定。我在实际项目中的经验是面向用户的接口用公平版本内部数据处理管道用非公平版本——前者用户能感知到卡顿后者只关心总吞吐。6. 从伪代码到能跑的代码中间隔着几道坎教科书上的 P/V 是抽象操作真到代码里你得自己处理信号量的实现、条件变量的配合、还有超时清理。这一段我拿 Python 走一遍因为它的threading模块把这些原语都暴露得很直白改起来方便看效果。6.1 用互斥锁加条件变量手搓一个信号量信号量的本质就两样东西一个整数一个等待队列。用条件变量实现如下import threading class Semaphore: def __init__(self, value): self.value value self.cond threading.Condition() self.waiters 0 def P(self): with self.cond: self.waiters 1 while self.value 0: self.cond.wait() self.value - 1 self.waiters - 1 def V(self): with self.cond: self.value 1 self.cond.notify()这里while不能写成if因为条件变量存在虚假唤醒被唤醒后必须重新检查条件。这一点在教科书里通常一笔带过但它是真实代码里最常见的 bug 来源之一。6.2 一个可运行的生产者消费者import threading, time, random class BoundedBuffer: def __init__(self, capacity): self.capacity capacity self.buf [] self.mutex threading.Lock() self.not_empty threading.Condition(self.mutex) self.not_full threading.Condition(self.mutex) def put(self, item): with self.not_full: while len(self.buf) self.capacity: self.not_full.wait() # 满则等 self.buf.append(item) self.not_empty.notify() # 唤醒一个消费者 def get(self): with self.not_empty: while not self.buf: self.not_empty.wait() # 空则等 item self.buf.pop(0) self.not_full.notify() # 唤醒一个生产者 return item def producer(buffer, pid): for i in range(20): item fp{pid}-{i} buffer.put(item) time.sleep(random.uniform(0, 0.01)) def consumer(buffer, cid): for _ in range(20): item buffer.get() time.sleep(random.uniform(0, 0.01)) buffer BoundedBuffer(4) threads [] for i in range(3): threads.append(threading.Thread(targetproducer, args(buffer, i))) for i in range(3): threads.append(threading.Thread(targetconsumer, args(buffer, i))) for t in threads: t.start() for t in threads: t.join() print(done)这里有个细节值得说Condition构造时传入了同一个Lock所以not_empty和not_full实际上共享同一把锁with self.not_full和with self.not_empty进入的是同一个临界区。这和前面 C 版本里用同一个mutex保护下标是一个道理。如果你想省事一个Condition也能干两件事只是notify的时候分不清唤醒的是生产者还是消费者效率低一点。6.3 怎么验证你的同步逻辑真的没问题代码能跑通不代表没问题尤其是并发代码。我一般做三件事第一加大随机延时。在关键操作前后插入随机 sleep把窗口放大让原本极低概率的交错更容易出现。上面代码里的time.sleep(random.uniform(0, 0.01))就是这个用途。第二做总数校验。生产者一共放进去多少个、消费者一共取出来多少个、有没有重复、有没有丢失全部统计一遍。上面例子里最终buf应该是空的且每个消费者拿到的 item 都不重复。第三设置超时监控。给join加上超时如果线程在规定时间内没结束大概率是死锁了。这一步在 CI 里特别有用因为死锁测试会永远挂住不加超时会拖死整个流水线。注意并发测试里跑通了和没 bug是两个概念。一个只在缓冲区恰好满的时候才发作的死锁在容量为 4 的测试里可能几百万次才撞上一次。条件允许的话把容量调小到 1 和 2 各跑一遍边界最容易暴露问题。7. 排查并发故障的几条实战路径理论和代码讲完了真正难的是线上出问题时怎么定位。这一段是我这些年积累下来的排查思路跟教科书关系不大但可能比前面几节更有用。7.1 死锁现场先把等待图拉出来进程卡死但 CPU 空闲第一反应就该是死锁。做法是抓线程栈然后看每个线程当前阻塞在哪个锁上、这个锁被谁持有。以 Linux 为例gdb -p pid后执行thread apply all bt就能看到全部线程栈或者用pstack直接打出来。找到卡在pthread_mutex_lock或类似调用的线程再看持有者是谁画一张有向图如果有环就是死锁环上的每个节点对应一段要改的代码。要注意的是有些死锁不是锁造成的而是条件变量唤醒丢失。线程在wait之前条件已经满足但notify发出时它还没进等待队列于是它进去之后永远等不到下一次通知。这类问题的表现是偶发卡死没有明显的锁环路。判断方法是检查wait外面是不是用了while循环重检条件——如果用了if基本就能锁定原因。7.2 竞态复现从时间窗口下手竞态比死锁难查因为它不留现场。我的做法是先想清楚哪个时间窗口内发生交错才会出错然后把那个窗口尽可能拉宽。常见手段有三个注入随机延时、把线程数调大、把某个操作临时改成耗时操作。还有一种更彻底的办法是用工具。线程检测器比如编译器的 ThreadSanitizer能在运行时记录所有内存访问并检测数据竞争虽然有一定误报和性能开销但比人肉猜要靠谱得多。我在几个 C 项目里把它加进 CI 的夜间构建抓到过好几次只在特定机器上才复现的问题。7.3 几条不写在教材里的经验第一永远不要在一个临界区里做阻塞调用。日志落盘、网络请求、数据库查询任何一个都可能卡住一旦卡在锁里整个系统就雪崩。我见过一个服务因为把一次 HTTP 调用放在了synchronized块里上游超时传导最终所有线程都堵在这把锁上。第二锁的粒度和锁的层级要提前定好。粒度太粗并发度低太细容易漏保护层级不定好必然出现获取顺序不一致。我的习惯是给每个模块的锁画一张层级图规定只能从高层往低层拿反向绝不接受。第三信号量的 V 操作宁可多写一次不要漏写。漏一次 V 就是永久阻塞多一次 V 顶多是计数偏大、提前放行虽然也是 bug但危害小得多而且通常在测试里更容易暴露。所以写代码时每个P旁边我都习惯性先写一个对应的V占位再填中间的逻辑。第四不要迷信加锁就万事大吉。加锁解决的是互斥解决不了顺序也解决不了可见性。有些场景需要的是一次性的顺序保证比如初始化完成的标志用原子变量加内存序比用锁轻量得多。最后提一个我自己踩过的坑曾经写过一个读者写者模型reader_count用的是普通 int觉得已经有count_mutex保护了没问题。结果编译器把计数器的读取优化到了锁外面导致if (reader_count 1)的判断时机不对第一个读者没去抢rw_mutex写者直接跟读者并发执行数据被写坏了。问题出在没有意识到编译器优化在锁边界上的行为需要额外的内存屏障来约束。修法是把计数器声明为原子类型或者确认编译器和平台的内存模型保证。这件事让我记住互斥锁保护的是代码块的互斥执行不自动等于内存可见性的全部保证涉及跨线程共享状态的变量原子类型永远是更稳的选择。