std::shared_mutex无法直接做到公平，因其lock_shared()和lock()无共享等待队列，读线程可无限插队导致写饥饿；真正公平需用std::mutex+condition_variable手动实现fifo调度。
读写锁本身没有内置“公平性”保证，std::shared_mutex 和 POSIX pthread_rwlock_t 默认都是读优先，容易导致写饥饿；真要实现读写公平，必须自己控制调度逻辑，不能依赖底层锁的默认行为。
为什么 std::shared_mutex 无法直接做到公平
std::shared_mutex 的 lock_shared() 和 lock() 是独立入口，内核不维护请求队列顺序。一旦有活跃读线程，新写线程就会一直阻塞，而后续读线程仍能不断抢入——这是标准规定的“读优先”语义，不是 bug，是设计选择。
常见错误现象：
- 写线程调用
lock()后长时间卡住，top显示 CPU 不高但程序响应迟滞 - 在高并发读场景下，写操作延迟从毫秒级飙升到秒级甚至更久
- 用
std::shared_lock+std::defer_lock尝试手动重试，反而加剧竞争和唤醒抖动
用条件变量 + 状态机模拟公平队列
核心思路：把读/写请求排队，按 FIFO 顺序分发锁权，禁止“插队式读”。关键不是锁本身，而是谁被允许去调用 lock_shared() 或 lock()。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用一个
std::mutex保护全局状态：int waiting_readers、int waiting_writers、bool writer_active、bool write_pending - 读线程进入前先原子递增
waiting_readers，再检查write_pending：若为 true，则等待read_cv（只在写释放后 notify） - 写线程先设
write_pending = true，然后 wait 直到waiting_readers == 0 && !writer_active，成功后才调mtx.lock() - 每次写释放后，优先 notify_one 写等待者；仅当无写等待时，才
notify_all读等待者
这样就强制形成「写请求一旦发出，后续读必须排队等它完成」的效果，逼近 FIFO 公平。
POSIX pthread_rwlock_t 怎么绕出读优先陷阱
POSIX 标准没提供写优先或公平模式的 flag，pthread_rwlockattr_setkind_np()（Linux 扩展）仅支持 PTHREAD_RWLOCK_PREFER_READER_NP 和 PTHREAD_RWLOCK_PREFER_WRITER_NP，后者仍非真正公平——它只是让写线程抢占当前读锁，不阻止新读线程在写等待期间进入。
安全做法：
- 彻底弃用
pthread_rwlock_t，改用pthread_mutex_t+pthread_cond_t手写公平调度器（同上一节逻辑） - 若必须用 rwlock，可在写线程中加粗粒度的退避：调
pthread_rwlock_wrlock()前，先尝试pthread_mutex_trylock()一个全局“写准入锁”，失败则短暂nanosleep()后重试 - 避免在循环中高频调用
pthread_rwlock_rdlock()，否则会持续压住写线程；可合并读批处理，减少锁进出次数
最容易被忽略的公平性破坏点
公平性失效往往不出现在锁实现里，而出现在业务逻辑层：
- 读线程持有
std::shared_lock时间过长（比如里面做了网络 I/O 或慢速计算），等于变相延长了写线程的等待窗口 - 多个读线程反复快速进出临界区，即使单次很短，但频率高到让写线程始终没机会“看到空档”
- 忘记在异常路径中释放锁（如 shared_lock 析构失败、或用了裸
lock_shared()却没配对unlock_shared()），导致整个队列卡死
真正的公平不是“每个线程等一样久”，而是“写请求发出后，系统不主动给新读放行”。这点必须贯穿设计、实现、压测全程。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
