1. 从“读者写者”这个经典模型说起它到底在解决什么现实问题如果你正在学操作系统或者准备面试后端、嵌入式、系统开发相关的岗位“读者写者问题”大概率是你绕不开的一道坎。很多人第一次看到这个名字的反应是读者和写者不就是读文件和写文件吗这有什么好讲的但真正动手写过并发程序的人都知道多个执行流同时访问同一份数据时麻烦从来不是“能不能读”而是“什么时候能读、什么时候必须等、等多久、谁先等”。读者写者问题本质上描述的是这样一种场景有一份共享数据一部分执行流只读取它另一部分执行流会修改它。读操作之间互不干扰可以同时进行但只要有人要写就必须独占访问不能有任何读者或其他写者同时操作。这个约束听起来简单但把它翻译成可运行的同步逻辑就会牵扯出一连串设计取舍。我先把这个问题的核心约束用一句话概括读读共享、读写互斥、写写互斥。这三条是所有读者写者方案的共同底线。但在这条底线之上还存在一个更微妙的问题——当读者和写者同时排队等待时到底该优先让谁进入这个优先级的选择直接衍生出了三种经典策略读者优先、写者优先、公平竞争。不同的策略对应不同的信号量和计数器设计也对应不同的实际应用场景。为什么这个问题值得单独拿出来详解因为它是理解“信号量如何协调多类执行流”的最佳样本。生产者消费者问题里只有两类角色缓冲区满和空是两个对称的条件哲学家就餐问题关注的是资源分配的死锁而读者写者问题第一次引入了“同类可并发、异类互斥”这种非对称的访问模式。你在实际工程中遇到的缓存系统、配置中心、数据库连接池、日志模块底层都能看到读者写者模型的影子。举个贴近开发的例子。假设你写了一个内存配置对象多个工作线程会频繁读取配置项偶尔有一个管理线程会更新配置。如果每次读都加互斥锁读多写少的场景下性能会被严重拖累如果完全不加锁更新配置时读到一半的数据就可能出现字段不一致。读者写者模型给出的答案就是让读操作共享进入写操作独占进入同时通过计数器记录当前有多少读者只有第一个读者负责加写锁、最后一个读者负责释放写锁。这套逻辑就是后面所有代码的骨架。所以这篇内容我会从最朴素的读者优先方案讲起逐步推到写者优先和公平策略把每个信号量的含义、每个判断条件的意图、每个容易写错的地方都拆开说清楚。无论你是刚接触操作系统课程还是已经工作几年想重新梳理并发基础都能从中拿到可以直接用的东西。2. 读者优先方案信号量到底该怎么摆计数器为什么不能少2.1 最直觉的想法为什么行不通先别急着看标准答案我们从一个最朴素的想法出发。既然读读可以共享那我用一个信号量rw_mutex表示“写锁”读者进入前先判断有没有写者在写没有就直接读有就等。写者进入前直接对rw_mutex加锁。这个思路的问题在于读者怎么知道“现在有没有写者”如果读者也去对rw_mutex加锁来判断那读者之间就变成互斥了读读共享直接失效。有人会说那读者不加锁只在写者加锁时不读不就行了问题是读者无法在不加锁的情况下安全地读取“是否有写者”这个状态因为状态本身也是共享数据。这就是并发编程里一个反复出现的陷阱你想保护数据但保护数据所需的元信息本身也需要保护。正确的做法是把“读者数量”这个计数器单独保护起来用一个专门的信号量count_mutex来保证计数器的加减是原子的。而真正的写互斥由另一个信号量rw_mutex承担。关键在于只有第一个进入的读者去抢rw_mutex只有最后一个离开的读者去放rw_mutex。中间的读者只需要改计数器不需要碰写锁。2.2 读者优先的完整逻辑拆解我把读者优先方案的核心流程拆成读者侧和写者侧两部分来看。读者侧的逻辑是这样的// 全局变量 semaphore count_mutex 1; // 保护 read_count semaphore rw_mutex 1; // 读写互斥锁 int read_count 0; // 当前读者数量 // 读者进入 wait(count_mutex); read_count; if (read_count 1) { wait(rw_mutex); // 第一个读者负责锁住写者 } signal(count_mutex); // ---- 执行读操作 ---- wait(count_mutex); read_count--; if (read_count 0) { signal(rw_mutex); // 最后一个读者负责释放写者 } signal(count_mutex);写者侧就简单得多// 写者进入 wait(rw_mutex); // ---- 执行写操作 ---- signal(rw_mutex);这里有几个细节必须说透。第一read_count和判断read_count 1必须在count_mutex的保护范围内完成否则两个读者可能同时看到read_count为 0都去抢rw_mutex第二个就会阻塞导致本可并发的读变成串行。第二最后一个读者释放rw_mutex之前也必须先减计数器再判断这个顺序不能反否则会出现写者被唤醒但计数器还没归零的窗口。2.3 读者优先的隐患写者可能被“饿死”读者优先方案跑起来没问题但它有一个著名的缺陷只要读者源源不断地到来写者就永远拿不到rw_mutex。因为第一个读者持有写锁期间后续读者看到read_count 0就直接进入根本不去检查是否有写者在等待。写者只能干等直到某一刻一个读者都没有。在高并发读的场景下这个“某一刻”可能永远不出现。这就是所谓的写者饥饿。注意它不是死锁系统整体还在推进只是写者这一方被无限期推迟。在实际系统里写者饥饿意味着配置永远更新不了、日志永远刷不了盘、缓存永远失效不了后果可能比死锁还隐蔽。提示很多教材把读者优先称为“读者优先”而不是“读者独占”是因为它并没有禁止写者进入只是在竞争时偏向读者。理解这个措辞差异对后面区分写者优先很关键。2.4 一个容易忽略的实操细节计数器的可见性在真实的多核环境里read_count这个变量如果只是普通整型即使有信号量保护也可能因为编译器优化或 CPU 缓存导致可见性问题。信号量的 wait/signal 操作本身通常带有内存屏障语义所以只要计数器的一切读写都在count_mutex保护下可见性是有保障的。但如果你图省事在某个地方绕过信号量直接读了一下read_count做判断那就可能读到过期值。我在实际调试并发代码时踩过这个坑为了“优化”性能在读者进入前先无锁读一下read_count如果大于 0 就直接进结果在某些调度下读到了旧值导致本该等待的读者提前进入和写者撞在一起。后来老老实实把所有对计数器的访问都放进临界区问题才消失。这个教训是共享状态的每一次访问都要走同一套同步规则不能有例外。3. 写者优先方案多一个信号量解决饥饿的思路3.1 写者优先要解决的核心矛盾读者优先的毛病是写者饿死那写者优先的思路就很直接当有写者在等待时新来的读者必须排队不能插队。注意这里的关键词是“有写者在等待”而不是“有写者在写”。如果只是有写者在写读者本来就要等真正要处理的是写者还在排队、读者却不断插队的情况。要实现这一点需要引入一个额外的信号量通常叫wrt或者queue用来表示“是否有写者在等待或正在写”。读者进入前必须先通过这个信号量如果此时有写者排队读者就会被挡在外面。写者进入前先把这个信号量置为“有写者”这样后续读者就会被拦住。3.2 写者优先的信号量布局写者优先方案一般用四个信号量信号量作用初值rw_mutex读写互斥写者独占1count_mutex保护读者计数器1read_try读者进入前的排队闸门1write_try写者之间的互斥1读者侧逻辑wait(read_try); // 如果写者在排队读者在这里等 wait(count_mutex); read_count; if (read_count 1) { wait(rw_mutex); } signal(count_mutex); signal(read_try); // 放行其他读者 // ---- 读操作 ---- wait(count_mutex); read_count--; if (read_count 0) { signal(rw_mutex); } signal(count_mutex);写者侧逻辑wait(write_try); // 写者之间互斥 wait(read_try); // 拦住新读者 wait(rw_mutex); // 等现有读者退出 // ---- 写操作 ---- signal(rw_mutex); signal(read_try); // 放行读者 signal(write_try);3.3 为什么写者要先拿read_try再拿rw_mutex这个顺序是写者优先方案的精髓。写者先拿read_try意味着从这一刻起新读者无法通过read_try这道闸门只能排队。然后写者再去等rw_mutex等现有读者全部退出。等写者写完释放read_try排队的读者才能继续。如果顺序反过来写者先等rw_mutex再拿read_try那么在写者等待期间新读者仍然可以通过read_try进入写者还是可能被饿死。所以这个顺序不是随便定的它直接决定了优先级是否生效。3.4 写者优先的代价读者可能反过来饿死写者优先解决了写者饥饿但引入了对称的问题如果写者持续到来读者可能一直拿不到read_try。在实际系统里这表现为读请求延迟飙升监控面板上读的 P99 突然拉高。所以写者优先并不是“更好的方案”它只是把优先级倒过来了适合写操作更紧急、更不能延迟的场景比如事务提交、状态落盘。我在一个日志采集模块里用过写者优先的思路日志写入线程优先级高于查询线程因为日志丢了就找不回来查询慢一点可以接受。但后来发现查询接口在高峰期几乎不可用最后改成了公平策略才平衡下来。这个经历告诉我优先级策略的选择必须结合业务对延迟的容忍度不能只看理论上的公平性。4. 公平策略让读者和写者按到达顺序排队4.1 公平策略要达成的目标读者优先偏向读者写者优先偏向写者公平策略则希望两者按到达顺序获得服务谁先来谁先上不搞特殊。这在理论上最“正确”实现起来也最接近现实中的排队系统。公平策略的常见实现思路是引入一个信号量service_queue读者和写者在进入各自的临界区之前都先对这个信号量做一次 wait/signal形成一个统一的等待队列。这样无论是读者还是写者都按到达顺序排队不会出现某一方无限插队的情况。4.2 公平策略的一种实现骨架semaphore service_queue 1; // 统一排队闸门 semaphore count_mutex 1; semaphore rw_mutex 1; int read_count 0; // 读者 wait(service_queue); wait(count_mutex); read_count; if (read_count 1) { wait(rw_mutex); } signal(count_mutex); signal(service_queue); // ---- 读操作 ---- wait(count_mutex); read_count--; if (read_count 0) { signal(rw_mutex); } signal(count_mutex); // 写者 wait(service_queue); wait(rw_mutex); signal(service_queue); // ---- 写操作 ---- signal(rw_mutex);这里service_queue的作用是让读者和写者在进入真正的资源竞争之前先排一个统一的队。读者拿到service_queue后如果发现自己是第一个读者就去抢rw_mutex写者拿到service_queue后直接去抢rw_mutex。由于大家都在同一个队列里先到的先拿到service_queue也就先获得进入的机会。4.3 公平策略的边界与注意事项公平策略听起来很美但它也有代价。统一排队意味着读者之间的并发度可能下降因为每个读者都要先过service_queue这道闸门虽然闸门本身很快但在极高并发下仍会成为热点。另外公平策略并不能完全消除饥饿只是把饥饿的概率降到很低在极端调度下仍可能出现某一方长时间等待。还有一个容易写错的地方写者在拿到service_queue后立刻释放然后再去等rw_mutex。这个释放动作很关键如果不释放写者在等rw_mutex时会一直占着service_queue导致后面的读者和写者全部堵死整个系统退化成串行。我第一次写公平策略时就犯了这个错现象是所有线程都卡住不动排查了半天才发现是service_queue没及时释放。注意公平策略里的service_queue释放时机是区分“真公平”和“假公平”的分水岭。写者必须在进入rw_mutex等待之前释放它读者也必须在完成计数器操作后立即释放。5. 三种策略的横向对比与选型依据5.1 用一张表看清差异对比维度读者优先写者优先公平策略读读并发支持支持支持读写互斥支持支持支持写写互斥支持支持支持饥饿风险写者可能饿死读者可能饿死双方饥饿概率低信号量数量2 个4 个3 个实现复杂度低中中适用场景读远多于写写紧急且不能延迟读写都重要5.2 选型时真正该问的问题很多资料只告诉你三种策略的区别却不告诉你实际该选哪个。我的经验是选型时先问三个问题第一读和写的比例大概是多少如果读占 95% 以上读者优先通常够用写者饥饿的概率在有限时间内可以接受。如果写占比不低就要考虑写者优先或公平策略。第二写操作的延迟敏感吗如果写操作对应的是事务提交、状态持久化这类不能拖的事情写者优先更合适。如果写只是后台刷新晚一点无所谓读者优先反而能提升整体吞吐。第三系统对最坏延迟有要求吗如果有 SLA 要求读和写的 P99 都不能超过某个值那公平策略是更稳妥的选择因为它不会让任何一方无限等待。5.3 一个常被忽略的现实因素信号量本身的实现上面所有分析都假设信号量的 wait/signal 是公平的也就是等待时间最长的线程最先被唤醒。但很多系统提供的信号量并不保证 FIFO唤醒顺序可能是任意的。在这种情况下即使你写了公平策略的代码实际行为也可能偏向某一方。所以如果你的平台信号量不保证公平就需要在应用层自己维护一个显式的等待队列或者使用带公平参数的锁。这一点在跨平台开发时尤其要注意。同一个读者写者逻辑在不同平台上跑出来的延迟分布可能完全不同原因往往就出在底层同步原语的公平性差异上。6. 从伪代码到可运行代码几个必须验证的测试场景6.1 测试场景一读读并发是否真的并发写完读者写者逻辑后第一个要验证的是读读并发。构造多个读者线程同时进入在临界区里打印进入和退出的时间戳看是否有重叠。如果所有读者的时间区间都是串行的说明你的实现把读读也互斥了多半是count_mutex的范围画错了或者读者错误地去抢了rw_mutex。6.2 测试场景二写者能否被正确唤醒第二个要验证的是写者在最后一个读者退出后能否被唤醒。构造一个写者先等待、多个读者陆续进入退出的场景观察写者是否在最后一个读者退出后立即获得执行。如果写者一直不醒检查最后一个读者的signal(rw_mutex)是否执行到了以及read_count是否真的归零。6.3 测试场景三饥饿是否真的发生第三个要验证的是饥饿。对于读者优先方案持续注入读者观察写者等待时间是否无限增长。这个测试需要跑足够长的时间并且用日志记录写者的等待时长。如果写者等待时间随读者数量线性增长且没有上限说明饥饿确实存在。6.4 测试场景四计数器边界第四个要验证的是计数器边界。构造只有一个读者的情况确认它进入时抢了rw_mutex退出时放了rw_mutex。再构造两个读者先后进入的情况确认第一个抢锁、第二个不抢锁、第一个退出时不放锁、第二个退出时才放锁。这个边界如果搞错要么写者永远进不来要么写者和读者同时进入。我在实际项目里写过一个自动化测试用随机调度反复跑上面四个场景每次跑一万轮只要有一轮出现异常就打印现场。这个测试帮我抓到了好几个只在特定时序下才出现的 bug比人工 review 有效得多。7. 我在实际编码中踩过的坑和总结出的经验7.1 坑一把count_mutex和rw_mutex搞混最常见的错误是把两个信号量的职责弄反。count_mutex保护的是read_count这个计数器它的临界区非常短只包含计数器的加减和判断rw_mutex保护的是真正的共享数据它的临界区包含整个读操作或写操作。如果把读操作也放进count_mutex的临界区读读并发就没了如果把计数器操作放进rw_mutex写者会被读者的计数操作频繁打断。7.2 坑二忘记在异常路径释放信号量如果读操作或写操作中间可能抛异常或提前返回一定要用 try-finally 或 RAII 保证信号量被释放。我见过一个线上问题写者在写数据时遇到一个可恢复的错误直接 return 了没有释放rw_mutex结果后续所有读者和写者全部卡死。这种问题在测试环境很难复现因为需要特定的错误触发条件。7.3 坑三用普通变量做计数器前面提过可见性问题这里再强调一次。read_count必须是受信号量保护的共享变量不能因为“它只是个整数”就掉以轻心。在 C/C 里可以用volatile加信号量在 Java 里可以用AtomicInteger配合锁但最稳妥的还是所有访问都走同一把锁。7.4 经验先用最简方案跑通再按需优化不要一上来就写公平策略。先用读者优先把基本逻辑跑通确认读读并发、读写互斥、写写互斥都正确再根据实际压测结果决定是否升级到写者优先或公平策略。很多场景下读者优先已经足够过度设计反而引入更多 bug。7.5 经验把策略做成可配置如果这个读者写者逻辑要复用在多个模块建议把优先级策略做成配置项底层用同一套接口通过参数切换信号量布局。这样业务方可以根据自己的读写比例选择策略而不需要改代码。我在一个缓存组件里就是这么做的读多写少的业务用读者优先写敏感的业务用写者优先效果比一刀切好很多。7.6 经验监控等待时长比监控吞吐更有用吞吐量高不代表没有问题可能是某一方被饿死但另一方在疯狂推进。真正能反映健康度的是读者和写者各自的等待时长分布。如果某一方的 P99 等待时长持续上涨说明优先级策略需要调整。这个指标比单纯的 QPS 更能提前发现问题。读者写者问题看似是操作系统课本里的一个练习题但它背后的同步思想——同类共享、异类互斥、优先级取舍、饥饿防范——在分布式锁、数据库隔离级别、缓存一致性协议里反复出现。把这三种策略的信号量布局和取舍逻辑吃透再去看那些更复杂的并发模型会发现它们不过是同一套思路在不同约束下的变体。 
长河君 · 2026/10/14 6:15:40 · 阅读 1.2k 读者写者问题三种策略详解：信号量布局、饥饿风险与选型指南
1. 从“读者写者”这个经典模型说起它到底在解决什么现实问题如果你正在学操作系统或者准备面试后端、嵌入式、系统开发相关的岗位“读者写者问题”大概率是你绕不开的一道坎。很多人第一次看到这个名字的反应是读者和写者不就是读文件和写文件吗这有什么好讲的但真正动手写过并发程序的人都知道多个执行流同时访问同一份数据时麻烦从来不是“能不能读”而是“什么时候能读、什么时候必须等、等多久、谁先等”。读者写者问题本质上描述的是这样一种场景有一份共享数据一部分执行流只读取它另一部分执行流会修改它。读操作之间互不干扰可以同时进行但只要有人要写就必须独占访问不能有任何读者或其他写者同时操作。这个约束听起来简单但把它翻译成可运行的同步逻辑就会牵扯出一连串设计取舍。我先把这个问题的核心约束用一句话概括读读共享、读写互斥、写写互斥。这三条是所有读者写者方案的共同底线。但在这条底线之上还存在一个更微妙的问题——当读者和写者同时排队等待时到底该优先让谁进入这个优先级的选择直接衍生出了三种经典策略读者优先、写者优先、公平竞争。不同的策略对应不同的信号量和计数器设计也对应不同的实际应用场景。为什么这个问题值得单独拿出来详解因为它是理解“信号量如何协调多类执行流”的最佳样本。生产者消费者问题里只有两类角色缓冲区满和空是两个对称的条件哲学家就餐问题关注的是资源分配的死锁而读者写者问题第一次引入了“同类可并发、异类互斥”这种非对称的访问模式。你在实际工程中遇到的缓存系统、配置中心、数据库连接池、日志模块底层都能看到读者写者模型的影子。举个贴近开发的例子。假设你写了一个内存配置对象多个工作线程会频繁读取配置项偶尔有一个管理线程会更新配置。如果每次读都加互斥锁读多写少的场景下性能会被严重拖累如果完全不加锁更新配置时读到一半的数据就可能出现字段不一致。读者写者模型给出的答案就是让读操作共享进入写操作独占进入同时通过计数器记录当前有多少读者只有第一个读者负责加写锁、最后一个读者负责释放写锁。这套逻辑就是后面所有代码的骨架。所以这篇内容我会从最朴素的读者优先方案讲起逐步推到写者优先和公平策略把每个信号量的含义、每个判断条件的意图、每个容易写错的地方都拆开说清楚。无论你是刚接触操作系统课程还是已经工作几年想重新梳理并发基础都能从中拿到可以直接用的东西。2. 读者优先方案信号量到底该怎么摆计数器为什么不能少2.1 最直觉的想法为什么行不通先别急着看标准答案我们从一个最朴素的想法出发。既然读读可以共享那我用一个信号量rw_mutex表示“写锁”读者进入前先判断有没有写者在写没有就直接读有就等。写者进入前直接对rw_mutex加锁。这个思路的问题在于读者怎么知道“现在有没有写者”如果读者也去对rw_mutex加锁来判断那读者之间就变成互斥了读读共享直接失效。有人会说那读者不加锁只在写者加锁时不读不就行了问题是读者无法在不加锁的情况下安全地读取“是否有写者”这个状态因为状态本身也是共享数据。这就是并发编程里一个反复出现的陷阱你想保护数据但保护数据所需的元信息本身也需要保护。正确的做法是把“读者数量”这个计数器单独保护起来用一个专门的信号量count_mutex来保证计数器的加减是原子的。而真正的写互斥由另一个信号量rw_mutex承担。关键在于只有第一个进入的读者去抢rw_mutex只有最后一个离开的读者去放rw_mutex。中间的读者只需要改计数器不需要碰写锁。2.2 读者优先的完整逻辑拆解我把读者优先方案的核心流程拆成读者侧和写者侧两部分来看。读者侧的逻辑是这样的// 全局变量 semaphore count_mutex 1; // 保护 read_count semaphore rw_mutex 1; // 读写互斥锁 int read_count 0; // 当前读者数量 // 读者进入 wait(count_mutex); read_count; if (read_count 1) { wait(rw_mutex); // 第一个读者负责锁住写者 } signal(count_mutex); // ---- 执行读操作 ---- wait(count_mutex); read_count--; if (read_count 0) { signal(rw_mutex); // 最后一个读者负责释放写者 } signal(count_mutex);写者侧就简单得多// 写者进入 wait(rw_mutex); // ---- 执行写操作 ---- signal(rw_mutex);这里有几个细节必须说透。第一read_count和判断read_count 1必须在count_mutex的保护范围内完成否则两个读者可能同时看到read_count为 0都去抢rw_mutex第二个就会阻塞导致本可并发的读变成串行。第二最后一个读者释放rw_mutex之前也必须先减计数器再判断这个顺序不能反否则会出现写者被唤醒但计数器还没归零的窗口。2.3 读者优先的隐患写者可能被“饿死”读者优先方案跑起来没问题但它有一个著名的缺陷只要读者源源不断地到来写者就永远拿不到rw_mutex。因为第一个读者持有写锁期间后续读者看到read_count 0就直接进入根本不去检查是否有写者在等待。写者只能干等直到某一刻一个读者都没有。在高并发读的场景下这个“某一刻”可能永远不出现。这就是所谓的写者饥饿。注意它不是死锁系统整体还在推进只是写者这一方被无限期推迟。在实际系统里写者饥饿意味着配置永远更新不了、日志永远刷不了盘、缓存永远失效不了后果可能比死锁还隐蔽。提示很多教材把读者优先称为“读者优先”而不是“读者独占”是因为它并没有禁止写者进入只是在竞争时偏向读者。理解这个措辞差异对后面区分写者优先很关键。2.4 一个容易忽略的实操细节计数器的可见性在真实的多核环境里read_count这个变量如果只是普通整型即使有信号量保护也可能因为编译器优化或 CPU 缓存导致可见性问题。信号量的 wait/signal 操作本身通常带有内存屏障语义所以只要计数器的一切读写都在count_mutex保护下可见性是有保障的。但如果你图省事在某个地方绕过信号量直接读了一下read_count做判断那就可能读到过期值。我在实际调试并发代码时踩过这个坑为了“优化”性能在读者进入前先无锁读一下read_count如果大于 0 就直接进结果在某些调度下读到了旧值导致本该等待的读者提前进入和写者撞在一起。后来老老实实把所有对计数器的访问都放进临界区问题才消失。这个教训是共享状态的每一次访问都要走同一套同步规则不能有例外。3. 写者优先方案多一个信号量解决饥饿的思路3.1 写者优先要解决的核心矛盾读者优先的毛病是写者饿死那写者优先的思路就很直接当有写者在等待时新来的读者必须排队不能插队。注意这里的关键词是“有写者在等待”而不是“有写者在写”。如果只是有写者在写读者本来就要等真正要处理的是写者还在排队、读者却不断插队的情况。要实现这一点需要引入一个额外的信号量通常叫wrt或者queue用来表示“是否有写者在等待或正在写”。读者进入前必须先通过这个信号量如果此时有写者排队读者就会被挡在外面。写者进入前先把这个信号量置为“有写者”这样后续读者就会被拦住。3.2 写者优先的信号量布局写者优先方案一般用四个信号量信号量作用初值rw_mutex读写互斥写者独占1count_mutex保护读者计数器1read_try读者进入前的排队闸门1write_try写者之间的互斥1读者侧逻辑wait(read_try); // 如果写者在排队读者在这里等 wait(count_mutex); read_count; if (read_count 1) { wait(rw_mutex); } signal(count_mutex); signal(read_try); // 放行其他读者 // ---- 读操作 ---- wait(count_mutex); read_count--; if (read_count 0) { signal(rw_mutex); } signal(count_mutex);写者侧逻辑wait(write_try); // 写者之间互斥 wait(read_try); // 拦住新读者 wait(rw_mutex); // 等现有读者退出 // ---- 写操作 ---- signal(rw_mutex); signal(read_try); // 放行读者 signal(write_try);3.3 为什么写者要先拿read_try再拿rw_mutex这个顺序是写者优先方案的精髓。写者先拿read_try意味着从这一刻起新读者无法通过read_try这道闸门只能排队。然后写者再去等rw_mutex等现有读者全部退出。等写者写完释放read_try排队的读者才能继续。如果顺序反过来写者先等rw_mutex再拿read_try那么在写者等待期间新读者仍然可以通过read_try进入写者还是可能被饿死。所以这个顺序不是随便定的它直接决定了优先级是否生效。3.4 写者优先的代价读者可能反过来饿死写者优先解决了写者饥饿但引入了对称的问题如果写者持续到来读者可能一直拿不到read_try。在实际系统里这表现为读请求延迟飙升监控面板上读的 P99 突然拉高。所以写者优先并不是“更好的方案”它只是把优先级倒过来了适合写操作更紧急、更不能延迟的场景比如事务提交、状态落盘。我在一个日志采集模块里用过写者优先的思路日志写入线程优先级高于查询线程因为日志丢了就找不回来查询慢一点可以接受。但后来发现查询接口在高峰期几乎不可用最后改成了公平策略才平衡下来。这个经历告诉我优先级策略的选择必须结合业务对延迟的容忍度不能只看理论上的公平性。4. 公平策略让读者和写者按到达顺序排队4.1 公平策略要达成的目标读者优先偏向读者写者优先偏向写者公平策略则希望两者按到达顺序获得服务谁先来谁先上不搞特殊。这在理论上最“正确”实现起来也最接近现实中的排队系统。公平策略的常见实现思路是引入一个信号量service_queue读者和写者在进入各自的临界区之前都先对这个信号量做一次 wait/signal形成一个统一的等待队列。这样无论是读者还是写者都按到达顺序排队不会出现某一方无限插队的情况。4.2 公平策略的一种实现骨架semaphore service_queue 1; // 统一排队闸门 semaphore count_mutex 1; semaphore rw_mutex 1; int read_count 0; // 读者 wait(service_queue); wait(count_mutex); read_count; if (read_count 1) { wait(rw_mutex); } signal(count_mutex); signal(service_queue); // ---- 读操作 ---- wait(count_mutex); read_count--; if (read_count 0) { signal(rw_mutex); } signal(count_mutex); // 写者 wait(service_queue); wait(rw_mutex); signal(service_queue); // ---- 写操作 ---- signal(rw_mutex);这里service_queue的作用是让读者和写者在进入真正的资源竞争之前先排一个统一的队。读者拿到service_queue后如果发现自己是第一个读者就去抢rw_mutex写者拿到service_queue后直接去抢rw_mutex。由于大家都在同一个队列里先到的先拿到service_queue也就先获得进入的机会。4.3 公平策略的边界与注意事项公平策略听起来很美但它也有代价。统一排队意味着读者之间的并发度可能下降因为每个读者都要先过service_queue这道闸门虽然闸门本身很快但在极高并发下仍会成为热点。另外公平策略并不能完全消除饥饿只是把饥饿的概率降到很低在极端调度下仍可能出现某一方长时间等待。还有一个容易写错的地方写者在拿到service_queue后立刻释放然后再去等rw_mutex。这个释放动作很关键如果不释放写者在等rw_mutex时会一直占着service_queue导致后面的读者和写者全部堵死整个系统退化成串行。我第一次写公平策略时就犯了这个错现象是所有线程都卡住不动排查了半天才发现是service_queue没及时释放。注意公平策略里的service_queue释放时机是区分“真公平”和“假公平”的分水岭。写者必须在进入rw_mutex等待之前释放它读者也必须在完成计数器操作后立即释放。5. 三种策略的横向对比与选型依据5.1 用一张表看清差异对比维度读者优先写者优先公平策略读读并发支持支持支持读写互斥支持支持支持写写互斥支持支持支持饥饿风险写者可能饿死读者可能饿死双方饥饿概率低信号量数量2 个4 个3 个实现复杂度低中中适用场景读远多于写写紧急且不能延迟读写都重要5.2 选型时真正该问的问题很多资料只告诉你三种策略的区别却不告诉你实际该选哪个。我的经验是选型时先问三个问题第一读和写的比例大概是多少如果读占 95% 以上读者优先通常够用写者饥饿的概率在有限时间内可以接受。如果写占比不低就要考虑写者优先或公平策略。第二写操作的延迟敏感吗如果写操作对应的是事务提交、状态持久化这类不能拖的事情写者优先更合适。如果写只是后台刷新晚一点无所谓读者优先反而能提升整体吞吐。第三系统对最坏延迟有要求吗如果有 SLA 要求读和写的 P99 都不能超过某个值那公平策略是更稳妥的选择因为它不会让任何一方无限等待。5.3 一个常被忽略的现实因素信号量本身的实现上面所有分析都假设信号量的 wait/signal 是公平的也就是等待时间最长的线程最先被唤醒。但很多系统提供的信号量并不保证 FIFO唤醒顺序可能是任意的。在这种情况下即使你写了公平策略的代码实际行为也可能偏向某一方。所以如果你的平台信号量不保证公平就需要在应用层自己维护一个显式的等待队列或者使用带公平参数的锁。这一点在跨平台开发时尤其要注意。同一个读者写者逻辑在不同平台上跑出来的延迟分布可能完全不同原因往往就出在底层同步原语的公平性差异上。6. 从伪代码到可运行代码几个必须验证的测试场景6.1 测试场景一读读并发是否真的并发写完读者写者逻辑后第一个要验证的是读读并发。构造多个读者线程同时进入在临界区里打印进入和退出的时间戳看是否有重叠。如果所有读者的时间区间都是串行的说明你的实现把读读也互斥了多半是count_mutex的范围画错了或者读者错误地去抢了rw_mutex。6.2 测试场景二写者能否被正确唤醒第二个要验证的是写者在最后一个读者退出后能否被唤醒。构造一个写者先等待、多个读者陆续进入退出的场景观察写者是否在最后一个读者退出后立即获得执行。如果写者一直不醒检查最后一个读者的signal(rw_mutex)是否执行到了以及read_count是否真的归零。6.3 测试场景三饥饿是否真的发生第三个要验证的是饥饿。对于读者优先方案持续注入读者观察写者等待时间是否无限增长。这个测试需要跑足够长的时间并且用日志记录写者的等待时长。如果写者等待时间随读者数量线性增长且没有上限说明饥饿确实存在。6.4 测试场景四计数器边界第四个要验证的是计数器边界。构造只有一个读者的情况确认它进入时抢了rw_mutex退出时放了rw_mutex。再构造两个读者先后进入的情况确认第一个抢锁、第二个不抢锁、第一个退出时不放锁、第二个退出时才放锁。这个边界如果搞错要么写者永远进不来要么写者和读者同时进入。我在实际项目里写过一个自动化测试用随机调度反复跑上面四个场景每次跑一万轮只要有一轮出现异常就打印现场。这个测试帮我抓到了好几个只在特定时序下才出现的 bug比人工 review 有效得多。7. 我在实际编码中踩过的坑和总结出的经验7.1 坑一把count_mutex和rw_mutex搞混最常见的错误是把两个信号量的职责弄反。count_mutex保护的是read_count这个计数器它的临界区非常短只包含计数器的加减和判断rw_mutex保护的是真正的共享数据它的临界区包含整个读操作或写操作。如果把读操作也放进count_mutex的临界区读读并发就没了如果把计数器操作放进rw_mutex写者会被读者的计数操作频繁打断。7.2 坑二忘记在异常路径释放信号量如果读操作或写操作中间可能抛异常或提前返回一定要用 try-finally 或 RAII 保证信号量被释放。我见过一个线上问题写者在写数据时遇到一个可恢复的错误直接 return 了没有释放rw_mutex结果后续所有读者和写者全部卡死。这种问题在测试环境很难复现因为需要特定的错误触发条件。7.3 坑三用普通变量做计数器前面提过可见性问题这里再强调一次。read_count必须是受信号量保护的共享变量不能因为“它只是个整数”就掉以轻心。在 C/C 里可以用volatile加信号量在 Java 里可以用AtomicInteger配合锁但最稳妥的还是所有访问都走同一把锁。7.4 经验先用最简方案跑通再按需优化不要一上来就写公平策略。先用读者优先把基本逻辑跑通确认读读并发、读写互斥、写写互斥都正确再根据实际压测结果决定是否升级到写者优先或公平策略。很多场景下读者优先已经足够过度设计反而引入更多 bug。7.5 经验把策略做成可配置如果这个读者写者逻辑要复用在多个模块建议把优先级策略做成配置项底层用同一套接口通过参数切换信号量布局。这样业务方可以根据自己的读写比例选择策略而不需要改代码。我在一个缓存组件里就是这么做的读多写少的业务用读者优先写敏感的业务用写者优先效果比一刀切好很多。7.6 经验监控等待时长比监控吞吐更有用吞吐量高不代表没有问题可能是某一方被饿死但另一方在疯狂推进。真正能反映健康度的是读者和写者各自的等待时长分布。如果某一方的 P99 等待时长持续上涨说明优先级策略需要调整。这个指标比单纯的 QPS 更能提前发现问题。读者写者问题看似是操作系统课本里的一个练习题但它背后的同步思想——同类共享、异类互斥、优先级取舍、饥饿防范——在分布式锁、数据库隔离级别、缓存一致性协议里反复出现。把这三种策略的信号量布局和取舍逻辑吃透再去看那些更复杂的并发模型会发现它们不过是同一套思路在不同约束下的变体。