std::shared_mutex是C++17引入的读写锁，需配合std::shared_lock（读）和std::unique_lock（写）使用，不可直接调用lock()；它专为读多写少场景设计，支持多线程并发读、单线程独占写，但写锁会阻塞所有新读锁获取。
std::shared_mutex 在 C++17 中怎么用
直接说结论：std::shared_mutex 是 C++17 引入的原生读写锁，但它本身不能直接加锁，必须配合 std::shared_lock（读锁）和 std::unique_lock（写锁）使用。别试图对它调用 lock()，会编译失败。
常见错误是把 std::shared_mutex 当成普通互斥量用，比如写 mtx.lock() —— 这根本不存在，std::shared_mutex 没有 lock() 成员函数。
-
std::shared_lock<code>std::shared_mutex用于多线程并发读，构造时自动获取共享锁，析构时释放 -
std::unique_lock<code>std::shared_mutex用于写操作，确保排他性；也可用std::scoped_lock（C++17 起支持多个std::shared_mutex） - 注意：
std::shared_lock不支持移动语义前的旧标准（C++14 及更早）需用std::shared_lock的替代方案（如boost::shared_lock），但标准库从 C++17 开始才真正可用
读多写少场景下，shared_lock 和 unique_lock 怎么配对
典型场景：一个缓存容器（如 std::map）被频繁读取、偶尔更新。读操作用 std::shared_lock，写操作用 std::unique_lock，两者互斥，但多个 shared_lock 可同时存在。
关键点不是“能不能并发读”，而是“写是否阻塞所有读”。答案是：是的，一旦有 std::unique_lock 持有锁，后续所有 std::shared_lock 都会阻塞，直到写锁释放。
立即学习“C++免费学习笔记（深入）”；
- 读操作示例：
std::shared_lock<std::shared_mutex> lock(rw_mutex); return cache.at(key);
- 写操作示例：
std::unique_lock<std::shared_mutex> lock(rw_mutex); cache[key] = value;
- 不要在持有
shared_lock期间尝试升级为写锁（C++ 标准不支持“锁升级”），必须先释放读锁，再获取写锁 —— 否则可能死锁 - 若需“检查-修改”原子性（如 double-checked locking），应改用其他同步机制（如
std::atomic+ 内存序 或std::mutex），别依赖 shared_mutex 升级
Windows 上编译报错 “shared_mutex not found” 怎么办
这通常不是代码问题，而是工具链没启用 C++17 或标准库不完整。MSVC 从 Visual Studio 2017 15.5 版本起才完全支持 std::shared_mutex，且需显式开启 C++17 标准。
- 确认编译器版本：VS2017 15.5+ 或 VS2019+；Clang ≥ 6.0；GCC ≥ 8.0（libstdc++ 需 ≥ 8.0）
- 编译选项必须包含
-std=c++17（GCC/Clang）或/std:c++17（MSVC） - Windows 下 MinGW-w64 若用旧版 libstdc++（如 GCC 7.x），即使加了 -std=c++17 也会链接失败，因为实现缺失；换用 LLVM-based MinGW 或升级 GCC
- 某些嵌入式 STL（如 uClibc++）或裁剪版标准库根本不提供
std::shared_mutex，此时只能退回到std::mutex或引入第三方（如 Boost.Thread 的shared_mutex）
性能比普通 mutex 好在哪？什么时候反而更慢
优势只在读操作远多于写操作，且读操作耗时明显（比如读取并解析一段 JSON）时才体现出来。std::shared_mutex 的内部实现（通常是 futex 或 Slim Reader/Writer Lock）比 std::mutex 更重，单次加锁开销更大。
- 纯内存读取（如访问一个
int）用shared_mutex反而更慢：锁开销压倒了并发收益 - 写操作频繁（比如每 10 次读就有 3 次写）时，
shared_mutex的公平性策略（部分实现偏向写者）会导致读线程饥饿，延迟升高 - 调试模式下（未优化）性能差异会被放大，Release 模式下差距收窄但仍需实测；建议用
std::chrono对比关键路径耗时，而不是凭感觉选 - 如果程序运行在 NUMA 架构上，
shared_mutex的缓存行竞争可能比预期更严重，尤其当多个线程在不同 socket 上争抢同一锁时
实际用的时候，别光看接口名字觉得“读写锁肯定比 mutex 高级”，先测，再换。很多所谓“适合读写锁”的场景，用 std::atomic 或无锁结构反而更稳。
