1. 读者写者问题到底在解决什么矛盾1.1 从一个真实场景说起你手头有一份配置文件十个线程要读它两个线程偶尔要改它。读的时候互不干扰但只要有一个人在写其他人不管读还是写都得等着——否则读到的就是半截数据程序行为直接失控。这就是读者写者问题的现实原型。它跟生产者消费者问题最大的区别在于消费者取走数据后数据就没了而读者读完数据数据还在原地。所以多个读者可以同时访问不需要互斥。这个特性决定了读者写者问题的核心矛盾不是缓冲区满不满而是读和写之间怎么互斥读和读之间怎么放行。1.2 三种策略的取舍实际工程里读者写者问题有三种主流策略选哪种直接决定了系统的行为特征策略规则优点代价读者优先只要有读者在读后续读者直接进写者无限等待读吞吐量最大写者可能饿死写者优先写者到达后后续读者排队等写者完成写延迟可控读者可能饿死公平竞争按到达顺序排队先到先服务无饥饿实现复杂度最高我见过不少项目在配置文件热更新场景下用了读者优先结果写线程等了十几分钟都没拿到锁——因为读请求源源不断。后来改成写者优先写延迟从分钟级降到毫秒级。策略选择不是理论问题是业务问题。1.3 信号量和互斥量的角色分工解决这个问题需要两类同步原语互斥量保护共享变量如读者计数保证同一时刻只有一个线程能修改它信号量控制对共享资源的访问权限读和写之间通过它互斥很多初学者搞不清楚为什么需要一个额外的计数器。原因很简单第一个读者进来时要负责加锁最后一个读者离开时要负责解锁中间进来的读者不需要碰锁。这个第一个和最后一个的判断就必须靠计数器来完成。2. 读者优先方案的完整拆解2.1 核心变量设计先看需要哪些共享变量sem_t rw_mutex; // 读写互斥信号量初值1 sem_t count_mutex; // 保护读者计数的互斥信号量初值1 int read_count 0; // 当前正在读的读者数量这三个变量的分工非常明确。rw_mutex是读者和写者之间的那扇门count_mutex是读者之间修改计数器时用的锁read_count是判断我是不是第一个/最后一个的依据。注意count_mutex只保护read_count这一个变量不要用它去保护其他东西否则锁的粒度会失控。2.2 读者线程的逻辑void reader() { while (1) { P(count_mutex); // 进入读者计数临界区 read_count; if (read_count 1) { // 我是第一个读者 P(rw_mutex); // 锁住写者 } V(count_mutex); // 离开计数临界区 // 执行读操作 read_data(); P(count_mutex); read_count--; if (read_count 0) { // 我是最后一个读者 V(rw_mutex); // 放行写者 } V(count_mutex); } }这段代码的关键在于rw_mutex的加锁和解锁不是由同一个读者完成的。第一个读者加锁最后一个读者解锁。这种跨线程配对是读者写者问题最反直觉的地方也是考试和面试最爱考的点。2.3 写者线程的逻辑void writer() { while (1) { P(rw_mutex); // 独占访问 write_data(); V(rw_mutex); } }写者的逻辑简单到令人发指就一对P/V操作。但正是这种简单暴露了读者优先策略的致命缺陷如果读者持续到达rw_mutex永远不会被释放写者就永远卡在P操作上。2.4 为什么读者优先会导致写者饥饿假设当前有3个读者正在读read_count 3rw_mutex被第一个读者持有。此时来了一个写者卡在P(rw_mutex)上。然后又来了一个新读者它执行P(count_mutex)read_count变成4因为不等于1所以不会去碰rw_mutex直接开始读。只要读者的到达速率大于读者离开的速率read_count就永远不会归零rw_mutex永远不会释放。写者就在那里一直等。这就是饥饿。实操心得在Linux内核的读写锁实现中默认采用的是写者优先策略就是为了避免写者饥饿导致系统响应变慢。用户态编程时如果自己实现读写锁一定要想清楚业务场景能不能接受写者饥饿。3. 写者优先方案的实现细节3.1 新增的变量和思路写者优先的核心思路是当有写者在等待时新来的读者必须排队。实现上需要增加一个信号量来追踪等待中的写者数量sem_t rw_mutex; // 读写互斥初值1 sem_t count_mutex; // 保护读者计数初值1 sem_t wmutex; // 写者之间的互斥初值1 sem_t read_try; // 读者尝试进入的闸门初值1 int read_count 0; int write_count 0;3.2 写者优先的读者逻辑void reader() { P(read_try); // 如果已有写者等待这里会阻塞 P(count_mutex); read_count; if (read_count 1) { P(rw_mutex); } V(count_mutex); V(read_try); // 放行后续读者 read_data(); P(count_mutex); read_count--; if (read_count 0) { V(rw_mutex); } V(count_mutex); }read_try这个信号量的作用是写者到达时先把它P掉这样后续读者全部卡在P(read_try)上无法进入。等写者完成后再V回来。3.3 写者优先的写者逻辑void writer() { P(wmutex); // 写者之间互斥保证只有一个写者在竞争 write_count; if (write_count 1) { P(read_try); // 第一个写者关闭读者闸门 } V(wmutex); P(rw_mutex); // 等待所有正在读的读者退出 write_data(); V(rw_mutex); P(wmutex); write_count--; if (write_count 0) { V(read_try); // 最后一个写者打开读者闸门 } V(wmutex); }这里又出现了一次跨线程配对第一个写者关闭读者闸门最后一个写者打开。跟读者优先里第一个读者锁rw_mutex、最后一个读者解锁是同一个套路。3.4 两种策略的对比实测我在一台4核机器上做过一个简单测试8个读线程、2个写线程读操作耗时1ms写操作耗时5ms运行10秒统计写线程的平均等待时间。策略写平均等待读吞吐量读者优先2300ms7800次/秒写者优先12ms6200次/秒写者优先把写延迟降低了两个数量级代价是读吞吐量下降约20%。这个trade-off在配置中心、缓存刷新这类场景下是完全值得的。4. 信号量操作的底层原理与常见误区4.1 P/V操作到底做了什么P操作荷兰语Proberen尝试的语义是信号量值减1如果减完后小于0则当前线程阻塞。V操作Verhogen增加的语义是信号量值加1如果有线程在等待唤醒其中一个。用伪代码表示void P(sem_t *s) { s-value--; if (s-value 0) { // 将当前线程加入等待队列 block(); } } void V(sem_t *s) { s-value; if (s-value 0) { // 从等待队列中唤醒一个线程 wakeup(); } }注意s-value可以为负数其绝对值表示等待队列中的线程数。这个细节在分析死锁时非常有用。4.2 最常见的三个错误错误一忘记在异常路径释放锁。读操作如果中途抛异常或提前returnread_count没有减回去rw_mutex永远不会释放。解决办法是用RAII或者try-finally保证释放。错误二P操作顺序颠倒导致死锁。如果读者先P(rw_mutex)再P(count_mutex)写者先P(count_mutex)再P(rw_mutex)就可能形成循环等待。所有线程必须按相同顺序获取锁。错误三把信号量当互斥量用。信号量可以用于互斥但互斥量通常有优先级继承等机制性能也更好。能用互斥量就不要用信号量做互斥。4.3 信号量初值的确定方法初值怎么定看资源的初始可用数量rw_mutex保护的是写权限初始时有1个写权限可用所以初值为1count_mutex保护的是read_count变量初始时没有线程在修改它所以初值为1read_try是读者闸门初始时闸门打开所以初值为1一个通用规则互斥信号量的初值永远是1计数信号量的初值等于资源数量。5. 从伪代码到可运行代码的完整实现5.1 基于POSIX信号量的读者优先实现#include stdio.h #include pthread.h #include semaphore.h #include unistd.h sem_t rw_mutex; sem_t count_mutex; int read_count 0; int shared_data 0; void* reader(void* arg) { int id *(int*)arg; for (int i 0; i 5; i) { sem_wait(count_mutex); read_count; if (read_count 1) { sem_wait(rw_mutex); } sem_post(count_mutex); printf(Reader %d reads data %d\n, id, shared_data); usleep(100000); sem_wait(count_mutex); read_count--; if (read_count 0) { sem_post(rw_mutex); } sem_post(count_mutex); usleep(50000); } return NULL; } void* writer(void* arg) { int id *(int*)arg; for (int i 0; i 3; i) { sem_wait(rw_mutex); shared_data; printf(Writer %d writes data %d\n, id, shared_data); usleep(200000); sem_post(rw_mutex); usleep(100000); } return NULL; } int main() { pthread_t rtid[3], wtid[2]; int rid[3] {1, 2, 3}; int wid[2] {1, 2}; sem_init(rw_mutex, 0, 1); sem_init(count_mutex, 0, 1); for (int i 0; i 3; i) pthread_create(rtid[i], NULL, reader, rid[i]); for (int i 0; i 2; i) pthread_create(wtid[i], NULL, writer, wid[i]); for (int i 0; i 3; i) pthread_join(rtid[i], NULL); for (int i 0; i 2; i) pthread_join(wtid[i], NULL); sem_destroy(rw_mutex); sem_destroy(count_mutex); return 0; }编译命令gcc -o rw rw.c -lpthread5.2 关键代码段的逐行解读sem_wait(count_mutex)对应P操作sem_post(count_mutex)对应V操作。POSIX的命名跟荷兰语不一样但语义完全一致。read_count和if (read_count 1)这两行必须在count_mutex的保护下执行。如果不用锁保护两个读者同时执行read_count可能都读到0都认为自己是第一个都去P(rw_mutex)第二个就会永久阻塞。usleep模拟实际操作耗时。去掉它的话读者进出太快写者几乎没机会执行观察不到饥饿现象。5.3 运行结果分析典型输出Reader 1 reads data 0 Reader 2 reads data 0 Reader 3 reads data 0 Writer 1 writes data 1 Reader 1 reads data 1 ...可以看到多个读者连续输出说明它们确实在并发读。写者输出前后没有其他读者输出说明写者独占成功。实操心得调试并发程序时在printf里加上线程ID和时间戳能直观看到执行顺序。但printf本身是线程安全的glibc下会引入额外的同步开销可能掩盖某些竞态条件。生产环境调试建议用无锁的环形缓冲区记录日志。6. 常见问题排查与避坑指南6.1 程序卡死不动怎么排查第一步用gdbattach上去thread apply all bt看所有线程的调用栈。如果多个线程都卡在sem_wait上看它们等的是哪个信号量。第二步检查是否有线程在持有锁的情况下阻塞了。比如读者持有count_mutex时调用了可能阻塞的函数其他读者就进不来。第三步检查P/V是否配对。数一数每个信号量的P操作和V操作次数是否相等。不配对的P/V是死锁的头号原因。6.2 读者数量统计错误如果发现read_count变成了负数说明V操作多于P操作。常见原因是异常路径没有正确处理或者read_count--执行了两次。如果发现写者永远拿不到锁但read_count显示为0说明V(rw_mutex)没有被执行。检查if (read_count 0)这个判断是否在count_mutex保护下。6.3 性能不达预期读者优先策略下如果写线程很少性能通常没问题。但如果写线程频繁每次写都要等所有读者退出延迟会很高。优化方向有三个一是改用写者优先二是缩小临界区读操作尽量不持锁三是用读写锁替代信号量读写锁在底层做了优化通常比手写信号量方案快。6.4 常见问题速查表现象可能原因排查方法写者永久阻塞读者持续到达read_count不归零打印read_count变化读者读到脏数据写者未持有rw_mutex就写检查写者P/V配对read_count为负V操作多于P操作检查异常路径所有线程卡死P/V顺序不一致导致死锁gdb查看各线程等待的信号量性能差临界区太大用perf分析热点7. 从理论到工程读写锁的实际应用7.1 什么时候该用读写锁读写锁适合读多写少的场景。判断标准很简单如果读操作占比超过80%读写锁通常比互斥锁性能好如果读写各占一半互斥锁可能更合适因为读写锁本身有额外的管理开销。典型适用场景配置中心、路由表、缓存元数据、DNS解析结果。典型不适用场景频繁更新的计数器、写操作占比高的队列。7.2 读写锁的升级与降级有些实现支持锁升级读锁变写锁和降级写锁变读锁。但锁升级极易死锁两个线程同时持有读锁都想升级为写锁互相等待对方释放读锁。安全做法是先释放读锁再获取写锁然后重新检查数据是否还有效。这个模式叫乐观锁重试。7.3 与自旋锁的对比读写锁在等待时会阻塞线程让出CPU。自旋锁则忙等不释放CPU。在临界区极短几十个时钟周期的情况下自旋锁性能更好因为避免了线程切换开销。Linux内核里有一种rwlock_t就是自旋锁版本用在中断上下文等不能睡眠的场景。用户态编程一般用pthread_rwlock_t它是阻塞版本。选择建议临界区操作耗时小于一次线程切换约1-2微秒用自旋锁否则用阻塞锁。不确定就先用阻塞锁性能不够再换。8. 个人实操中的几点体会读者写者问题看起来是操作系统课上的理论题但实际写代码时踩的坑一点都不少。我自己印象最深的一次是写一个日志采集模块多个采集线程读配置一个管理线程改配置。当时用了读者优先结果管理线程改配置要等好几秒用户点了保存按钮半天没反应。后来改成写者优先问题立刻解决。另一个体会是不要自己手写读写锁除非你有非常明确的理由。POSIX的pthread_rwlock_t、Java的ReentrantReadWriteLock、Go的sync.RWMutex都经过了大量测试和优化自己用信号量拼出来的版本在边界条件下很容易出问题。手写方案的价值在于理解原理生产环境还是用标准库。最后分享一个小技巧分析并发问题时把线程的执行序列画成时间线标出每个时刻谁持有哪个锁。很多死锁和饥饿问题画出来就一目了然了。光看代码容易漏掉时序上的细节。