C++多线程中锁饥饿是隐性调度失衡，根源在于std::mutex不保证公平、唤醒顺序由内核决定，解法需用condition_variable+显式队列控制唤醒逻辑，而非依赖锁类型。
锁的饥饿（starvation）在 C++ 多线程中不是由标准库直接报错提示的问题，而是一种隐性调度失衡：某些线程长期拿不到锁，尤其在读多写少或写优先策略下，写线程可能被大量读线程“淹没”，或低优先级任务永远排在队列尾部。根本解法不在于换锁类型，而在于控制等待顺序、限制持有时长、打破无约束的公平假象。
std::mutex 本身不保证公平，别默认它会轮询
std::mutex 是操作系统底层互斥体的封装，Linux 上通常是 futex，Windows 上是 Critical Section —— 它们都不承诺 FIFO 或任何公平策略。线程唤醒顺序由内核调度器决定，可能连续唤醒同类型线程（比如多个读线程），导致写线程无限等待。
- 不要依赖
std::mutex自带“公平性”，它没有 - 若业务逻辑要求写操作不能被无限延迟（如配置更新、状态刷新），必须显式干预排队机制
- 用
std::condition_variable+ 队列手写公平等待逻辑，比寄希望于 mutex 更可靠
用条件变量 + 显式等待队列控制唤醒顺序
真正的公平不是“谁先等谁先得”，而是“谁该执行谁被放行”。参考知识库中 FairRWLock 的设计思路：维护一个 std::queue 记录等待者类型（读/写）和对应 std::condition_variable*，每次只唤醒队首兼容者（例如：队首是写请求，就等所有读释放完再放行；队首是读，且无活跃写，就批量放行）。
- 关键点在于
m_cv.wait(lk, [&]{ return !m_writer && (waiter.type == 'r' || m_readers == 0); })这类带状态判断的谓词，而非无条件wait - 避免把所有线程塞进同一个
condition_variable等待，否则唤醒是随机的 - 每次
unlock()后调用drain_queue()而非notify_all()，防止“惊群”和重复竞争
避免写线程因读线程密集而饿死
读写锁场景下，饥饿最常见于“读霸占”：只要有一个读线程进来，后续读都能立刻获得许可，写线程始终卡在 m_readers > 0 条件上。这不是 bug，是多数 std::shared_mutex 实现的默认行为（C++17 起提供，但标准未规定公平性）。
立即学习“C++免费学习笔记（深入）”；
- 若使用
std::shared_mutex，不要假设lock_shared()和lock()有优先级 —— 它们没有 - 可改用
std::timed_mutex给写操作加超时：if (writer_mtx.try_lock_for(100ms)) { ... }，失败则退避或触发降级逻辑 - 更彻底的做法：在写请求到达时，设置一个“写意向”标志，并拒绝新的读请求（即升级为写优先模式），直到本次写完成
std::lock_guard 和 RAII 不解决饥饿，只防死锁
std::lock_guard 确保异常安全地释放锁，但它对线程调度毫无影响。有人误以为“用了 RAII 就不会饿”，其实恰恰相反：如果临界区执行时间波动大（比如读操作有时查缓存、有时查磁盘），会导致锁持有时间不可控，加剧不公平。
- 饥饿根源常在临界区内部耗时差异，而非锁管理本身
- 检查是否在锁内做了 I/O、内存分配、远程调用等阻塞操作 —— 这些必须移出临界区
- 若必须在锁内处理变长任务，考虑拆分为“获取数据快照 + 解锁 + 处理”，再用原子 flag 控制可见性
真正难的不是实现一个“看起来公平”的锁，而是识别哪些线程本不该长期等待 —— 比如监控线程每秒要刷一次状态，却因为日志线程总在抢锁而延迟 3 秒，这种饥饿往往藏在业务语义里，而不是并发原语文档中。
