20个线程并发读，1个线程写。写线程等了3176毫秒才拿到锁。不是死锁。不是bug。是std::shared_mutex的默认行为。大多数 C++ 程序员第一次用读写锁的时候，心里的预期模型是这样的：读者拿共享锁、写者拿独占锁，写者来了读者就等一下，读者来了写者也等一下，大家排队轮流来。这个预期在某些平台上是成立的——但在 Linux 上用 GCC 编译的std::shared_mutex，默认行为和这个预期相去甚远。写者来了，读者不但不等，还能继续插队进去拿锁。这篇从一个压测翻车现场出发，一路追到 libstdc++ 的shared_mutex实现、glibc NPTL 的pthread_rwlock_common.c源码，把读写锁的读优先策略是怎么让写线程活活饿死的，一行一行拆给你看。读完你会拿到三样东西：饥饿复现的完整压测代码、glibc 源码中读优先判断的关键路径、以及一份"什么场景该用什么锁"的工程决策清单。压测现场：写线程等了3秒先看代码。这是一个标准的读多写少场景：一个配置中心，20个线程并发读配置，1个线程定期更新配置。全局变量和读线程的逻辑很直接：#include/