std::shared_mutex 更适合读多写少场景，因其允许多个读线程并发访问，而 std::mutex 强制所有操作串行；但需注意 c++17 起支持、非递归、读写锁不可混用、无读转写原子操作及性能权衡。
std::shared_mutex 为什么比 std::mutex 更适合读多写少
因为 std::shared_mutex 允许多个读线程同时进入临界区，而写线程独占——这直接对应“读多写少”的真实负载。用 std::mutex 的话，哪怕全是读操作，也会强制串行，吞吐量掉得明显。
但注意：它不是银弹。C++17 才正式标准化（GCC 8+、Clang 6+、MSVC 2015 Update 3 起支持），老项目若还在用 C++14 或更低，std::shared_mutex 根本不可用，得退到 boost::shared_mutex 或手写读写锁封装。
- 读操作用
lock_shared()/unlock_shared()，或更安全的std::shared_lock<:shared_mutex></:shared_mutex> - 写操作仍用
lock()/unlock()，或std::unique_lock<:shared_mutex></:shared_mutex> - 不支持递归：同一个线程重复调用
lock_shared()是未定义行为
std::shared_lock 和 std::unique_lock 的选择逻辑
别图省事全用 std::unique_lock —— 它会把读操作也变成排他式，彻底废掉 std::shared_mutex 的意义。读场景必须用 std::shared_lock，它在构造时调用 lock_shared()，析构自动 unlock_shared()，RAII 安全又简洁。
示例对比：
立即学习“C++免费学习笔记（深入）”；
// ✅ 正确：读用 shared_lock std::shared_lock<std::shared_mutex> lock(mutex_); return data_; // ❌ 错误：读用 unique_lock → 实际变成写锁语义 std::unique_lock<std::shared_mutex> lock(mutex_); // 这里已阻塞其他所有读写 return data_;
-
std::shared_lock构造可带超时参数（std::defer_lock、std::try_to_lock、std::chrono::milliseconds），适合避免读等待过久 -
std::unique_lock支持延迟锁定和条件变量配合，写操作涉及复杂同步时仍需它 - 两者不能混用同一把锁实例：比如先用
shared_lock持有读锁，再试图用unique_lock上写锁 → 死锁风险极高
写优先还是读优先？标准库没给你选
std::shared_mutex 的调度策略由实现定义，标准不保证读优先或写优先。实际中，libstdc++（GCC）和 libc++（Clang）都偏向“写饥饿”：如果写线程在等待，新来的读线程可能被拦住，防止写操作无限排队。但这不是规范承诺，只是当前实现倾向。
这意味着：如果你的场景对写延迟极度敏感（比如实时配置更新），不能依赖“写一定快”，得加监控或降级手段；如果读吞吐是命脉，也要警惕写请求积压导致读锁迟迟无法获取（尤其在高并发写突增时）。
- 没有
try_lock_upgrade()这种“读转写”原子操作 —— C++20 也没加，想升级必须先释放读锁，再争写锁，中间存在竞态窗口 - 若真需要读转写，常见做法是用双重检查 + 版本号，或改用
std::atomic<int></int>做轻量状态标记 - Windows 上
SRWLock有明确写优先策略，但跨平台代码不能假设这个行为
性能陷阱：shared_mutex 不是零成本抽象
比起 std::mutex，std::shared_mutex 内部状态更复杂（要跟踪读计数、写等待队列等），单次锁操作开销略高。在读操作极短（比如只读一个 int）、且线程数不多时，反而可能更慢。
是否值得用，得看读写比例和临界区长度。粗略经验：读操作平均耗时 > 100ns，且读:写 ≥ 5:1 时，收益才明显。
- 不要在 hot path 上频繁构造/析构
std::shared_lock—— 把它作为函数局部变量没问题，但别在循环内反复 new/delete 锁对象 - 调试构建下性能失真严重：libstdc++ 的 debug mode 会对
shared_mutex做额外检查，压测务必用-O2 -DNDEBUG - Valgrind/Helgrind 对
shared_mutex支持有限，检测读写竞争不如对普通 mutex 可靠，得靠压力测试 + 日志观察
真正难的是平衡：锁粒度太粗，读写互相拖累；太细，又引入管理开销和死锁风险。shared_mutex 只解决“读并发”这一环，数据结构本身是否无锁友好、内存布局是否 cache-line 友好，这些往往比锁类型影响更大。
