std::shared_mutex 支持并发读，std::mutex 不支持
当多个线程只读不写时，std::shared_mutex 允许它们同时进入临界区；而 std::mutex 强制串行访问，哪怕全是读操作也会排队等待。这是最核心的差异。
典型场景：缓存查找、配置表遍历、只读状态快照等——读多写少（比如 95% 读 + 5% 写）时，std::shared_mutex 能显著降低读操作的延迟和锁竞争。
-
std::shared_mutex::lock_shared()：获取共享锁，允许多个线程同时持有 -
std::shared_mutex::lock()：获取独占锁，会阻塞所有共享锁请求，直到当前写锁释放 -
std::mutex::lock()：无论读写，一律互斥，无共享语义
std::shared_mutex 的开销比 std::mutex 高，别在简单场景滥用
std::shared_mutex 内部需维护读写状态计数、唤醒策略（如优先写者或公平调度），实现更复杂。在低并发或读写比例接近的场景下，它反而可能比 std::mutex 慢。
实测常见表现：
立即学习“C++免费学习笔记（深入）”；
- 单线程读/写：
std::shared_mutex开销高约 1.5–3×（取决于标准库实现，如 libstdc++ vs libc++） - 10 线程纯读：
std::shared_mutex吞吐可提升 5–8×；但若混入频繁写操作，优势迅速消失 - windows 上
SRWLock底层实现较轻量；linux glibc 中pthread_rwlock_t封装有一定开销
注意 C++17 起才可用，且部分旧编译器默认未启用
std::shared_mutex 是 C++17 引入的标准组件。若用 GCC 7+ 或 Clang 5+，需确认编译选项包含 -std=c++17（而非 c++14）；MSVC 2017 Update 3 起支持，但早期版本需手动开启 _HAS_CXX17 宏。
常见错误现象：
- 编译报错：
Error: 'shared_mutex' is not a member of 'std' - 链接时报
undefined reference to 'std::shared_mutex::lock()'—— 往往是 ODR 使用了不同标准版本的库
替代方案（C++14 及以前）：boost::shared_mutex 或平台原生 API（如 pthread_rwlock_t / SRWLOCK），但失去跨平台一致性。
std::shared_lock 和 std::unique_lock 的 RAII 用法必须匹配
不能对 std::shared_mutex 直接调用 lock() 后裸用 unlock()；必须配合 std::shared_lock（读）或 std::unique_lock（写）管理生命周期，否则极易死锁或未定义行为。
std::shared_mutex rw_mtx; std::vector data; // ✅ 正确：RAII 自动管理共享锁 void read_data() { std::shared_lock lock(rw_mtx); for (int x : data) { / ... / } } // lock 析构自动 unlock_shared()
// ✅ 正确：写操作用 unique_lock void update_data(int x) { std::unique_lock lock(rw_mtx); data.push_back(x); } // lock 析构自动 unlock()
// ❌ 危险：裸调用 lock_shared() 且忘记 unlock_shared() void bad_read() { rw_mtx.lock_shared(); // 若抛异常，这里就泄漏了 // ... rw_mtx.unlock_shared(); }
实际中，读写锁的“写饥饿”问题（大量读请求持续到达导致写操作长期等待）容易被忽略。标准库不保证写优先，也无超时接口（try_lock_for 仅对独占锁有效，try_lock_shared_for C++20 才加入）。需要写优先逻辑时，得自己封装或换用第三方方案。