std::shared_lock只是sharedmutex的raii封装，不实现读写锁逻辑；真正提供多读单写语义的是std::shared_mutex等底层互斥体，二者配合才能实现读并发、写独占。
std::shared_lock 本身不实现读写锁，它只是共享所有权的 RAII 封装
很多人以为 std::shared_lock 是“读锁”，甚至能和 std::unique_lock 配合自动实现多读单写——其实不是。std::shared_lock 只负责在构造时调用底层 shared_lockable 对象（如 std::shared_mutex）的 lock_shared()，析构时调用 unlock_shared()。它自己不调度、不阻塞、不判断读写冲突。
真正承担读写语义的是它所包装的互斥体类型。C++17 起，std::shared_mutex 才是标准中首个满足 SharedMutex 概念的类型；C++20 还补充了更轻量的 std::shared_timed_mutex（但实际使用中几乎被弃用）。
-
std::shared_lock必须搭配std::shared_mutex（或自定义满足SharedMutex的类型），单独用它毫无意义 - 不能拿
std::mutex初始化std::shared_lock，编译直接报错：no matching constructor -
std::shared_lock支持移动，但不支持拷贝——这是为了防止意外延长共享持有时间
怎么配对使用 std::shared_mutex + std::shared_lock 实现多读单写
核心逻辑就一条：读操作用 std::shared_lock<:shared_mutex></:shared_mutex>，写操作用 std::unique_lock<:shared_mutex></:shared_mutex>。两者底层都操作同一个 std::shared_mutex 实例，由该互斥体内部保证“多个 shared_lock 可同时持有，但会阻塞 unique_lock；而 unique_lock 持有时，所有 new shared_lock 都要等待”。
典型用法：
立即学习“C++免费学习笔记（深入）”；
std::shared_mutex rw_mutex;
std::vector<int> data;
<p>// 读路径
void read_data() {
std::shared_lock<std::shared_mutex> lock(rw_mutex); // → 调用 lock_shared()
for (int x : data) { /<em> ... </em>/ }
}</p><p>// 写路径
void write_data(int x) {
std::unique_lock<std::shared_mutex> lock(rw_mutex); // → 调用 lock()
data.push_back(x);
}- 读操作必须用
std::shared_lock（不能用std::unique_lock），否则失去并发读能力 - 写操作可以用
std::unique_lock或直接rw_mutex.lock()，但推荐前者——便于异常安全和延迟锁定 - 不要混用
std::shared_timed_mutex和std::shared_lock：它虽兼容，但性能差、API 冗余，C++20 已标记为 deprecated
为什么有时候读操作还是被写操作卡住？常见阻塞原因
即使代码写对了，实测仍可能发现读延迟高、吞吐上不去——问题往往不在 std::shared_lock，而在锁粒度或竞争模式。
- 写操作太频繁或太长：哪怕只有一小段临界区，只要写锁没释放，所有新进的
std::shared_lock都得排队等，旧读锁不受影响，但新读请求会被阻塞 - 误在循环内反复构造/析构
std::shared_lock：比如在遍历容器时每轮都加锁解锁，开销远大于一次锁住整个遍历 - 锁对象生命周期超出必要范围：例如把
std::shared_mutex声明为全局变量，导致模块间无意共享，放大争用 - 调试器或日志打点在临界区内：看似无关，但若日志函数内部有锁或系统调用，可能间接拖慢锁持有时间
Windows / GCC / Clang 下的兼容性与性能提醒
std::shared_mutex 在不同平台实现差异明显，直接影响你能否真拿到“多读并发”收益。
- Linux（GCC/Clang + glibc）：底层通常映射到
futex或pthread_rwlock_t，读写分离做得比较干净，多读性能好 - Windows（MSVC）：早期版本（VS2015/2017）用临界区模拟，读写都串行化；VS2019 起才用
SRWLock，真正支持无锁读并发 - macOS：libc++ 直到 Xcode 14（2022）才完成
std::shared_mutex的完整实现，旧版本可能静默退化为普通互斥体 - 别依赖
try_lock_shared()的“零开销”：它在某些实现里仍是系统调用，高频率轮询反而比阻塞式更伤性能
真实项目里，如果读写比极高且对延迟敏感，先确认目标平台的 std::shared_mutex 是否真正启用硬件级读写分离——不然花力气改锁策略，效果可能不如换个更激进的无锁结构或分片设计。
