std::shared_mutex不支持锁升级，故无法在持有共享锁时安全转为独占锁；正确做法是读操作用shared_lock、写操作统一用unique_lock，避免竞态与死锁。
shared_mutex 能解决读多写少场景下的并发性能问题，但直接用它实现线程安全字典时，std::shared_mutex（C++17）本身不提供“升级锁”能力，你无法在已持共享锁的前提下安全地转为独占锁——这是最容易卡住的地方。
为什么不能在 shared_lock 里直接 upgrade_to_unique_lock
C++ 标准库的 std::shared_mutex 不支持锁升级。常见错误是：先用 std::shared_lock 查 key，发现不存在再想“升级”去插入，结果只能释放再重拿 std::unique_lock，中间存在竞态窗口——别的线程可能在这间隙完成插入，导致重复写或覆盖。
- 标准库没有
upgrade_lock或try_upgrade_to_unique这类接口 - Boost 提供了
boost::shared_mutex+boost::upgrade_lock，但纯 C++17 不行 - 强行用
std::shared_lock+std::unique_lock套嵌，会死锁（同一线程重复加锁）
安全写法：读操作用 shared_lock，写操作统一走 unique_lock
放弃“先读后写”的优化幻想，对所有写操作（insert、erase、[]=、update）都使用 std::unique_lock；读操作（at、find、count）用 std::shared_lock。虽然写吞吐下降，但逻辑清晰、无竞态、符合标准库约束。
-
operator[]必须用std::unique_lock：它可能插入默认值，属于写行为 -
at()和find()可安全用std::shared_lock，只读不改结构 - 若需“查不到就设默认值”，应由调用方显式处理（先 shared_lock 读，失败后 unique_lock 再写），而不是封装进一个函数里假装原子
template<typename K, typename V>
V& thread_safe_map<K, V>::operator[](const K& k) {
std::unique_lock<std::shared_mutex> lock(mtx_);
return data_[k]; // 可能触发插入
}
注意 shared_mutex 的平台兼容性与性能陷阱
std::shared_mutex 在 Windows 上（MSVC）底层常映射为 SRWLock，性能好；但在某些旧版 libstdc++（如 GCC 8 之前）中，它只是基于 std::mutex 模拟的，读并发形同虚设，甚至比普通 mutex 更慢。
立即学习“C++免费学习笔记（深入）”；
- 检查编译器和 STL 版本：
__cplusplus >= 201703L且_GLIBCXX_RELEASE >= 9（GCC 9+）较稳妥 - Linux 下可考虑
pthread_rwlock_t替代（需手动封装），但失去 RAII 和跨平台性 - 高竞争写场景下，
shared_mutex的写饥饿问题明显——持续读会阻塞写，必要时加写优先策略（比如用std::mutex+std::condition_variable手动调度）
一个最小可用的 thread_safe_map 实现骨架
不带异常安全增强、不支持迭代器遍历（因遍历时锁难管理），只保核心读写语义正确：
template<typename K, typename V>
class thread_safe_map {
mutable std::shared_mutex mtx_;
std::map<K, V> data_;
public:
V& operator[](const K& k) {
std::unique_lock<std::shared_mutex> lock(mtx_);
return data_[k];
}
V at(const K& k) const {
std::shared_lock<std::shared_mutex> lock(mtx_);
auto it = data_.find(k);
if (it == data_.end()) throw std::out_of_range("key not found");
return it->second;
}
size_t count(const K& k) const {
std::shared_lock<std::shared_mutex> lock(mtx_);
return data_.count(k);
}
};
真正棘手的部分不在锁怎么加，而在于你是否意识到：任何试图把“读-判断-写”压缩成单个接口的行为，都在绕开 C++17 shared_mutex 的能力边界。要么接受两次锁开销，要么换 Boost，要么自己用更低层原语实现——没第三条捷径。
