std::shared_mutex不能直接替代std::mutex，因其不支持递归独占锁、读锁升级为写锁会死锁、写锁期间禁止加读锁，仅提供严格多读单写语义，且底层非简单封装。
std::shared_mutex 为什么不能直接替代 std::mutex
因为 std::shared_mutex 不支持独占式递归加锁，也不允许同一个线程先持读锁再试图加写锁（会死锁），更不能在持有写锁时再加任何读锁。它只提供严格的“多读单写”语义，底层靠原子状态+等待队列实现分离，不是对 std::mutex 的简单包装。
常见错误现象：std::system_error: Resource deadlock avoided —— 多数是线程自己试图升级读锁为写锁，或跨作用域混用锁类型。
- 读操作必须用
std::shared_lock<:shared_mutex></:shared_mutex>（非std::unique_lock） - 写操作必须用
std::unique_lock<:shared_mutex></:shared_mutex>或直接调用lock()/unlock() - 不能把
std::shared_lock和std::unique_lock混用于同一把std::shared_mutex实例的同一时间点（它们互斥）
读写分离的实际写法：两个典型模式
核心在于“读不阻塞读，但阻塞写；写阻塞一切”。std::shared_mutex 本身不记录谁在读/写，全靠 RAII 锁对象的构造/析构触发状态变更。
示例：一个带缓存的配置读取器
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
class ConfigCache {
mutable std::shared_mutex mtx_;
std::string data_;
public:
std::string get() const {
std::shared_lock<std::shared_mutex> lock(mtx_); // ✅ 允许多个线程同时进入
return data_;
}
void set(const std::string& s) {
std::unique_lock<std::shared_mutex> lock(mtx_); // ✅ 写时自动排他
data_ = s;
}
};
-
get()用mutable+const成员函数 +std::shared_lock，满足只读接口语义 -
set()用std::unique_lock，确保写入期间无并发读或写 - 不要手动调用
mtx_.lock_shared()或mtx_.lock()—— RAII 更安全，异常也可靠
std::shared_mutex 在 Windows 上的兼容性坑
VS 2015 初始实现有严重 bug：多个 std::shared_lock 可能无法正确唤醒等待中的 std::unique_lock，导致写操作无限期挂起。这个问题直到 VS 2019 16.8+ 才彻底修复。
如果你的项目需支持旧版 MSVC：
- 确认编译器版本 ≥ 16.8，或使用
_HAS_CXX17宏检查 - Linux/macOS 下（libstdc++/libc++）基本无此问题，但要注意 glibc 版本 ≥ 2.26 才完整支持
pthread_rwlock后端 - 生产环境建议加运行时检测：启动时尝试构造/销毁一对
std::shared_lock和std::unique_lock，超时则 fallback 到std::mutex+ 引用计数模拟
性能关键点：shared_lock 构造开销比 unique_lock 高
std::shared_lock 内部要执行原子读-修改-写（如 fetch_add 计数器），而 std::unique_lock 多数路径只需一次原子 store。高频读场景下，这个差异会被放大。
- 避免在 tight loop 里反复构造/析构
std::shared_lock，应尽量延长其生命周期 - 不要为了“看起来对称”而在写操作里用
std::shared_lock（它不提供写权限） - 若读操作极轻量（比如只读一个
int），考虑用std::atomic替代，完全规避锁开销
读写分离不是银弹——当写操作占比超过 15%，或读操作本身很重，std::shared_mutex 的调度开销可能反超普通互斥锁。实测比对不能跳过。
