shared_mutex是C++17引入的读写锁，需显式启用C++17+标准，依赖特定平台支持；头文件为，读用shared_lock、写用unique_lock，不支持升级锁，适用读多写少场景。
shared_mutex 是 C++17 引入的，不是所有编译器默认启用
如果你在 std 命名空间里找不到 shared_mutex，大概率是编译器没开 C++17 或更高标准。GCC/Clang 需加 -std=c++17（或 c++20），MSVC 默认 19.28+ 支持，但项目属性里仍要确认「C++ 语言标准」设为 ISO C++17 标准或更高。
另外注意：std::shared_mutex 在 Windows 上依赖 SRWLOCK，VS2015 Update 3 起才完整支持；MinGW-w64 7.0+ 才稳定提供，旧版可能只有 boost::shared_mutex 可用。
- 头文件必须是
<shared_mutex></shared_mutex>，不是<mutex></mutex> - 它不支持拷贝，只支持移动（通常你也不需要移动）
- 构造后未初始化即使用会触发未定义行为——但它的默认构造函数是有效的，无需额外初始化
读写锁的两种锁类型：shared_lock 和 unique_lock
shared_mutex 的核心在于区分「共享读」和「独占写」。读操作用 std::shared_lock，写操作必须用 std::unique_lock（不能用 std::lock_guard，后者不支持 shared_mutex 的共享语义）。
常见错误是误用 lock_guard 包裹 shared_mutex，编译会直接报错：no matching function for call to ‘std::lock_guard<:shared_mutex>::lock_guard(...)’。
立即学习“C++免费学习笔记（深入）”；
-
shared_lock可多个同时持有，彼此不阻塞 -
unique_lock一旦被任一线程持有时，所有新来的shared_lock和其它unique_lock都会阻塞 -
unique_lock支持延迟锁定、条件变量配合、手动释放（unlock()），shared_lock同样支持这些操作
示例片段：
std::shared_mutex rw_mtx;
std::vector<int> data;
<p>void read_data() {
std::shared_lock<std::shared_mutex> lock(rw_mtx); // 允许多个线程并发读
for (int x : data) { /<em> ... </em>/ }
}</p><p>void write_data(int x) {
std::unique_lock<std::shared_mutex> lock(rw_mtx); // 写时排他
data.push_back(x);
}升级写锁（upgradeable lock）不存在于标准 shared_mutex
这是最容易踩的坑：C++ 标准 shared_mutex **不提供可升级锁**（即“先以共享方式锁住，后续按需升级为独占”）。有些开发者误以为 shared_lock 能调用 try_upgrade_to_unique()，其实那是 boost::shared_mutex 或某些自定义封装的接口。
标准库中，如果读逻辑中途发现需要写，唯一安全做法是先释放 shared_lock，再用 unique_lock 重新获取锁——但这中间存在竞态窗口（data 可能已被其它线程修改）。
- 若业务强依赖升级语义，得自己加一层保护（比如用原子标志 + 双重检查），或换用
boost::shared_mutex - 更常见的解法是：预判场景，把「读-判断-写」逻辑整体放在
unique_lock下，牺牲部分并发度换取正确性 - 注意
shared_lock析构时自动释放，别在作用域外保存其引用或试图手动unlock()后再用
性能与适用边界：别在临界区太短时硬套 shared_mutex
共享锁的实现比普通 mutex 更重——内部要维护读计数、写等待队列、唤醒策略等。当读操作极轻量（比如只读一个 int）、且读写比例不高时，用 shared_mutex 反而比 std::mutex 慢 10%~30%（实测 GCC 12 x86_64）。
它真正发挥价值的场景是：读操作耗时明显长于锁开销（如遍历容器、序列化结构体），且读线程远多于写线程（比如 10:1 以上）。
- 避免在循环内反复构造/析构
shared_lock，应尽量扩大其作用域覆盖整个读操作块 - 不要把它当成「比 mutex 更高级的替代品」来滥用；写多读少场景下，它可能成为瓶颈
- 调试时注意：Windows 上
shared_mutex在 contention 高时可能触发系统级等待，用perf或 VTune 看不到用户态锁等待，得查内核栈
shared_mutex 的设计意图很明确：解决「大量读者 + 少量写者」的公平调度问题。但它的 API 约束多、隐含成本高，用之前最好先确认你的读写模式真符合这个假设。
