std::map 多线程读写不安全，因其非线程安全，并发调用 operator[]、insert 或 erase 可能引发数据竞争、崩溃或迭代器失效；需用 mutex 或 shared_mutex 封装保护所有访问。
为什么不能直接用 std::map 多线程读写？
因为 std::map 本身不是线程安全的：多个线程同时调用 operator[]、insert() 或 erase() 可能导致数据竞争，甚至崩溃。哪怕只是“读+读”，只要中间有写操作，就可能触发迭代器失效或内部红黑树结构损坏——标准库不保证任何并发访问的安全性。
常见错误现象包括：segmentation fault、double free、迭代器指向野地址，或者看似正常但结果随机出错。
最简可行方案：封装 std::map + std::mutex
不需要重写底层，只需把所有访问路径串行化。关键不是锁粒度多细，而是确保所有修改和依赖一致性的读操作都受同一把锁保护。
- 用
mutable std::mutex mtx_成员（mutable允许在const成员函数中加锁） -
get()和set()必须全程持有锁；size()、empty()同样需要锁，因为它们读取内部计数器 - 避免在锁内做耗时操作（比如 I/O、长循环），否则会阻塞其他线程
- 不要返回内部
std::map的引用或迭代器——它们在锁释放后立即失效
示例片段：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
template<typename K, typename V>
class ThreadSafeMap {
mutable std::mutex mtx_;
std::map<K, V> map_;
public:
V get(const K& key) const {
std::lock_guard<std::mutex> lock(mtx_);
auto it = map_.find(key);
if (it != map_.end()) return it->second;
throw std::out_of_range("key not found");
}
void set(const K& key, const V& value) {
std::lock_guard<std::mutex> lock(mtx_);
map_[key] = value; // operator[] 自动插入或覆盖
}
};
读多写少场景下，std::shared_mutex 能提升多少性能？
如果读操作远多于写操作（比如配置缓存、路由表），用 std::shared_mutex（C++17）可允许多个线程并发读，仅写操作独占锁。实测在 8 核机器上，纯读吞吐量能提升 3–5 倍，但写操作延迟略增（因需等待所有读锁释放）。
-
std::shared_lock<std::shared_mutex>用于读，std::unique_lock<std::shared_mutex>用于写 - 注意：GCC 8+、Clang 7+ 才完整支持
std::shared_mutex；MSVC 支持但早期版本有竞态 bug - 不要混用
std::shared_lock和std::lock_guard—— 它们不兼容
哪些操作必须小心处理？
看似简单的操作，一旦脱离原子性，就会埋雷：
-
if (!map.contains(k)) map[k] = v;—— 这是典型的“检查后执行”（check-then-act）竞态，必须整个逻辑块加锁 -
auto val = map[k]; map.erase(k);—— 两次锁，中间可能被其他线程修改，应合并为一次加锁内的操作 - 遍历：用
std::vector<std::pair<K,V>> snapshot;先拷贝键值对再解锁，别边锁边遍历并做业务逻辑 - 移动语义：若
V是大对象，set()接收V&&并用std::move插入，避免无谓拷贝
真正麻烦的从来不是加锁本身，而是边界条件——比如异常抛出时锁是否自动释放（std::lock_guard 保证了这点），或者某个函数悄悄调用了未加锁的底层接口。
