读者写者问题

可视化演示

交互式演示读者写者问题的三种解决方案：读者优先、写者优先和公平调度，展示多线程并发访问共享资源时的同步机制和饥饿问题规避。

问题本质刻画

茶水间里的那本公共笔记，本质上就是操作系统里的“共享数据”：可能是一条数据库记录、一个缓存键、一个文件段落。来翻阅笔记的人叫“读者”，它们的操作是读取，不改变内容；来修订笔记的人叫“写者”，它们的操作是修改，会留下痕迹。读者彼此之间完全可以挤在同一页前各看各的，但写者动手时必须拥有一个绝对安静的环境，否则任何凑过来看的读者，都会看到“改了一半”的半成品。

操作系统把这种场景抽象成三个必须同时满足的约束：多个读者可以同时访问共享数据；写者在修改时，任何读者和其他写者都不能打扰它；进程不能因为长期轮不到机会而被饿死。前两条保证了数据的正确性——也就是“不会读到中间状态”，第三条保证了系统的活性——也就是“不会有人永远等着”。

用形式化语言来描述，就是三种访问组合中，只有一种被允许并发：

所以管理员的职责就是一句话：放读者们一起进书房，而写者必须单独进场。理解了这三条规则，就拿到了后面所有调度策略的钥匙。

读者优先策略

新来的这位管理员是个“讨好多数派”的人：只要有人在看书，他就不断放新读者进去，因为放读者进去总没错；只有房间彻底空了，他才让等了一下午的写者进场。这套做法就是读者优先（Readers-Preference）——读者的感受永远排第一，写者只能见缝插针。

把它翻译成调度逻辑：只要当前还有读者在访问共享数据，后续读者不必等待、直接进入；写者则必须等到读者计数归零才能进门。实现时维护一个读者计数 R（readcount）：新读者到达时先检查当前的读者数——只要有人正在读，就放心进去；至于写者，门口竖着一把“写者锁”，谁都不能在有读者的情况下拿到它。

读者优先的准入条件可以浓缩成一句话：读者任何时候都能进，写者只有在没人读时才能进。

读者像潮水一样一波波涌进来，写者只能在水完全退去的间隙进场；如果潮水永不退去，写者就只能永远站在门口——这就是“写者饥饿”。读者优先把吞吐做到了极致，却把公平性的风险全部推给了写者。

写者优先策略

换了位雷厉风行的管理员：只要有人登记要修订笔记，他立刻在门口挂上“暂停入内”的牌子，新来的读者都在门外排队，保证写者尽快拿到空房间。这就是写者优先（Writers-Preference）——把被亏待的一方翻身扶正。

写者优先的规则是：一旦有写者在等待，之后到达的读者必须排队阻塞，不能插队进房。注意一个细节：已经在房内的读者允许读完再走，强行清场会把正在进行的读操作撕成碎片。实现时用“等待写者数 W”登记：写者到达时 W 加 1；只要 W > 0，新读者就被挡在门外；当房间空出时，优先叫醒写者进场。

对比读者优先，写者优先把“谁说了算”的权力反转了过来：读者进门要看写者脸色，写者进门只看房间空不空。

写者被“插队保护”了，但普通读者可能遇到黑压压的写者队伍，一整天进不了书房。读者饥饿同样真实存在——可见“优先”这个词，永远是把一方的幸福建立在另一方的等待之上。

公平策略设计

为了避免两拨人互掐，管理员在门口装了个取号机：先来后到，叫号进场。谁先到谁拿号，想插队门都没有，读者写者一视同仁。这就是公平策略（Fair Scheduling）的直观画面，它的核心只有四个字：先来后到。

公平策略要解决的是“饥饿”这个结构性缺陷。它让所有请求按到达顺序排队：当一个写者排在队伍前面时，之后到达的读者必须排在它后面，不能抢先进入房间；反过来也一样，一个排在写者前面的读者，写者也不能越过它。这样每一方都有机会，谁都不会被永远晾在门外。

工程实现上，通常会维护一个 FIFO 队列或“等待写者计数”：有写者在等待时，新读者不再直接进场，而是排进队列。这种策略的代价是调度逻辑变复杂，每次读者进门都要多检查一次等待状态，因此公平是用一点点吞吐换来的。

取号机的意义不是让所有人都变快，而是让“永远轮不到”这件事从根源上消失。公平性不能提高吞吐，但它治愈了饥饿——这也是操作系统调度里“活性”概念的真正含义。

读写锁实现要点

书房的“门禁系统”由两个零件组成：读门是一个计数器，显示当前有几个人在看书；写门是一把只能由一个人握住的钥匙。计数器归零的那一刻，钥匙才会被交给等着的写者。这套门禁搬进操作系统，就是读写锁（Read-Write Lock）。

经典实现里需要两把锁：一把“写者锁”来控制写者的独占，一把“互斥锁”来保护读者计数器不被多个读者同时改写。读者进房的动作是：先用互斥锁护住计数器，把读者数加 1；如果自己是第一位读者，就把写者锁锁上，挡住可能的写者；然后释放互斥锁，安心进房。读者离房时反向操作：读者数减 1，如果自己是最后一位，就释放写者锁。

写者就简单得多：直接去拿写者锁，拿到就进房，离开时释放。整个实现浓缩成一个精妙的分工——首读者上锁，末读者解锁。

计数器让“很多人同时看”成为可能，写者锁让“没人看时才能改”成为铁律，两个零件缺一不可。这道门禁，就是所有读者写者策略在地基处的共同蓝图。

性能与权衡

读者优先时，书房利用率最高，因为读者们能挤在一起看；写者优先时，修订从不被耽误，但读者被挡门外时房间常常空着没人用。管理员渐渐意识到，怎么调和这个两难，取决于来看书的人里改稿的占多少——这就是性能权衡的本质。

性能对比有两个维度：吞吐量是单位时间完成多少次访问，延迟与饥饿则关心某个请求要等多久。读写锁和普通互斥锁的关键差异，在于读者能否并行。假设有 N 个读者、M 个写者，每次读耗时 t\_r、写耗时 t\_w。普通互斥锁把所有操作串行化，总耗时是两者的线性叠加；读写锁允许最多 P 个读者同时读数，读者部分的耗时被压缩到原来的 1/P。

两个方案的总耗时之比，就是读写锁带来的“加速比”：

所谓“选策略”就是选性价比：读者占绝对多数时，让读者扎堆最划算；写者频繁时，再多门禁也省不下时间，不如用一把简单的锁。读多写少四个字，是读者写者问题从理论走向工程的第一条准绳。

实战应用落地

书房的经验出了公司依然好用：数据库就是一本巨大的公共笔记，缓存是贴在门口的小抄。工程上最常见的场景，正是“很多人看同一份数据，少数人改它”，读者写者模型几乎原封不动地搬进了数据库和缓存的架构里。

第一个场景是数据库读写分离：写请求只能进主库，主库是唯一的写者；读请求可以打向多个从库，从库们就是并发读者。主从同步时，从库短暂读到旧数据是可以容忍的“滞后窗口”，但主库的写入必须串行，这正是写者独占的体现。第二个场景是缓存更新：更新数据库后删掉缓存，下一次读会 miss，再去数据库拉新值回填。第三个场景是框架内建的读写锁，比如 Go 的 sync.RWMutex、Java 的 ReentrantReadWriteLock，把门禁系统做成了开箱即用的零件。

其中最容易踩坑的是缓存更新的顺序。正确做法是“先更新数据库，再删除缓存”；如果反过来“先删缓存、再更新数据库”，中间一个极短的间隙里，另一个线程可能用旧值回填缓存，造成长期脏读。

写者改笔记时先把门口小抄撕掉，读者下次重新进来看新版——这就是缓存世界里“写者优先但不允许读者读到半成品”的朴素智慧。从原理到实战，读者写者问题从未走远。

AI 应用场景

Python 演示

import threadingimport timeimport random  class ReadWriteLock:    """带策略选项的读写锁, reader_priority=True 表示读者优先"""     def __init__(self, reader_priority=True):        self.cond = threading.Condition()        self.readers = 0               # 当前读者数 R        self.writer = False            # 是否有写者在工作        self.writers_waiting = 0       # 等待中的写者数 W        self.reader_priority = reader_priority     def r_lock(self):        with self.cond:            while self.writer or ((not self.reader_priority) and self.writers_waiting > 0):                self.cond.wait()       # 写者优先时, 新读者给写者让路            self.readers += 1     def r_unlock(self):        with self.cond:            self.readers -= 1            if self.readers == 0:                self.cond.notify_all()  # 最后一位读者唤醒所有等待者     def w_lock(self):        with self.cond:            self.writers_waiting += 1            while self.writer or self.readers > 0:                self.cond.wait()       # 写者必须等所有读者离场            self.writers_waiting -= 1            self.writer = True         # 宣示独占, 防止被唤醒的读者抢跑     def w_unlock(self):        with self.cond:            self.writer = False            self.cond.notify_all()     # 写者离开, 唤醒所有人  def reader_work(lock, name, records):    t0 = time.perf_counter()    lock.r_lock()    t1 = time.perf_counter()    records.append((name, 'read', t0, t1))    time.sleep(random.uniform(0.02, 0.05))    lock.r_unlock()  def writer_work(lock, name, records):    t0 = time.perf_counter()    lock.w_lock()    t1 = time.perf_counter()    records.append((name, 'write', t0, t1))    time.sleep(random.uniform(0.06, 0.1))    lock.w_unlock()  def simulate(reader_priority):    lock = ReadWriteLock(reader_priority)    records = []    jobs = [('R1', reader_work), ('R2', reader_work), ('R3', reader_work),            ('W1', writer_work), ('R4', reader_work), ('W2', writer_work)]    random.shuffle(jobs)    threads = []    for name, work in jobs:        t = threading.Thread(target=work, args=(lock, name, records))        threads.append(t)        t.start()        time.sleep(0.01)               # 错开到达时间, 模拟随机到达    for t in threads:        t.join()    return records  def main():    for priority in (True, False):        records = simulate(priority)        print('reader_priority =', priority)        for name, op, t0, t1 in sorted(records, key=lambda x: x[2]):            print('  %s  %s, 等待 %.3f 秒' % (name, op, t1 - t0))        print()  if __name__ == '__main__':    main()

1. while self.writer or self.readers > 0:写者等待的条件：有写者正在干活或还有读者在场，都不得进入临界区
2. self.writer = True用布尔标志宣示“我进来了”，防止被唤醒的读者抢跑造成写读重叠
3. if self.readers == 0: self.cond.notify_all()最后一位读者离场时叫醒所有等待者，把门禁交给写者
4. while self.writer or ((not self.reader_priority) and self.writers_waiting > 0):读者让路的条件：有写者在工作；写者优先模式下还有写者排队时读者也等待
5. threading.Thread(target=work, args=(lock, name, records))每个读者/写者是一个线程，模拟真实程序里的并发访问
6. time.sleep(0.01)错开线程启动时间，模拟请求随机到达，让“写者被读者潮挡住”的现象可见

常见误区

面试题