shared_mutex默认写者优先，当有线程调用lock()后，后续所有lock_shared()均被阻塞，导致读线程饥饿；其不保证FIFO公平性，且析构时误用锁、混用锁类型或Windows平台实现缺陷均可能引发卡顿。
shared_mutex 被多个线程反复 lock_shared 后突然卡住
这不是死锁，而是典型的「写优先饥饿」现象：shared_mutex 在 C++17 中默认采用写者优先策略。只要有一个线程调用了 lock()（独占锁），后续所有 lock_shared() 都会阻塞，哪怕写线程还没真正进入临界区——它只是在排队等待。常见于读多写少但写操作偶发的场景，比如配置热更新+高频日志读取。
排查时先用 gdb attach 进程，执行 info threads 看哪些线程状态是 pthread_cond_wait 或 __lll_lock_wait，再对每个线程用 bt 查栈：如果一堆线程卡在 std::shared_mutex::lock_shared()，而另一个线程停在 std::shared_mutex::lock() 附近（哪怕还没进临界区），基本就是这个原因。
- 临时验证：把写线程的
lock()换成try_lock()，失败则退避重试，观察读线程是否恢复 - 注意
shared_mutex不保证公平性，C++ 标准没规定调度顺序，不同 STL 实现（libstdc++ / libc++）行为可能不一致 - 别依赖「先到先服务」——它不提供 FIFO 保证
析构时 shared_mutex 还被持有导致程序 hang 住
最常发生在类成员变量是 std::shared_mutex，而析构函数里又调用了需要加锁的逻辑（比如清空缓存、通知 observer），形成隐式递归或资源释放顺序错误。典型错误是：在 ~MyClass() 里调用 clear_cache()，而该函数开头就 lock_shared()，此时对象已开始析构，但锁还活着，其他线程可能正等着它。
更隐蔽的是 RAII 对象生命周期管理不当：比如用 std::shared_ptr 管理一个带 shared_mutex 的对象，而回调函数里又通过该指针访问成员——析构途中回调触发锁请求，直接卡死。
立即学习“C++免费学习笔记（深入）”；
- 检查所有持有
shared_mutex的对象，确保析构函数里不调用任何需加锁的成员函数 - 避免在锁保护的代码块内 new/delete 或调用可能触发析构的函数（如
std::map::erase()可能调用 value 的析构） - 用
std::unique_lock<:shared_mutex></:shared_mutex>而不是裸调lock()/unlock()，确保异常安全，但更要确认 lock 对象的生存期不跨析构边界
混用 shared_mutex 和普通 mutex 导致锁顺序不一致
当代码中同时存在 std::mutex 和 std::shared_mutex，且不同线程以不同顺序获取它们时，就构成经典死锁条件。例如线程 A 先 lock mtx_a（mutex），再 lock_shared sh_mtx_b（shared_mutex）；线程 B 反过来先 lock_shared sh_mtx_b，再 lock mtx_a。即使都是读操作，lock_shared 仍算作一次锁获取，参与死锁检测（尤其在 sanitizer 模式下）。
Clang 的 -fsanitize=thread 能捕获这类问题，报错类似：WARNING: ThreadSanitizer: lock-order-inversion，后面跟着两个锁的地址和调用栈。
- 统一锁粒度：要么全用
shared_mutex（读多写少），要么全用mutex（简单粗暴） - 若必须混用，严格定义全局锁顺序，比如「所有 shared_mutex 地址小于所有 mutex 地址」，并在每次加锁前按地址升序 acquire
- 避免在 shared_mutex 保护区内调用外部接口（如回调、虚函数），因为无法控制对方是否会拿别的锁
Windows 上 shared_mutex 性能差还容易假死
MSVC 的 std::shared_mutex 在 Windows 上基于 SRWLock 实现，但早期版本（VS2017/2019）有 bug：当大量线程频繁切换读写状态时，unlock_shared() 可能迟迟不唤醒等待的写线程，表现为写操作无限期挂起。现象是 gdb 看不到阻塞，但 top 显示 CPU 低、线程数高、业务无响应。
根本原因是 Windows 内核 SRWLock 的 writer-wakeup 机制在高并发下失效，不是用户代码写错了。libc++ 和 libstdc++ 在 Linux/macOS 上通常更稳定，但 Windows 用户几乎只能绕开。
- 升级到 VS2022 17.4+，微软修复了部分 wakeup 延迟问题
- 改用第三方实现，比如
abseil::Mutex（支持 reader-writer 模式）或folly::RWSpinLock - 极端情况下，用两个
std::mutex模拟：一个控制写权限，一个控制读者计数——虽然繁琐，但可控
shared_mutex 的坑不在语法，而在它把并发语义交给了平台和 STL 实现去博弈。真要稳定，得盯着调用栈、锁状态、平台版本三者交叉验证，而不是只看自己的代码有没有 lock/unlock 匹配。
