哈希冲突本身无需加锁，真正需加锁的是多线程并发访问同一unordered_map实例；读多写少时应使用std::shared_mutex，读用shared_lock、写用unique_lock，并避免在锁内执行耗时操作。
哈希冲突本身不需要加锁
哈希冲突是 unordered_map 内部行为，发生在插入/查找时多个键映射到同一桶（bucket），标准库用链地址法处理——每个桶挂一个链表或动态数组。这个过程完全在容器内部完成，**不涉及用户可见的共享状态修改**，所以“哈希冲突时加锁”这个说法本身就是误解。真正需要加锁的，是**多线程并发访问同一个 unordered_map 实例**，无论是否发生冲突。
读多写少场景必须用 std::shared_mutex
若多个线程只读不写（比如查配置、查缓存），用 std::mutex 会把所有读操作串行化，性能断崖式下降。正确做法是用 C++17 的 std::shared_mutex：
-
std::shared_lock<:shared_mutex></:shared_mutex>用于读操作，允许多个线程同时持有 -
std::unique_lock<:shared_mutex></:shared_mutex>用于写操作（insert、erase、clear），独占访问 - 注意：
operator[]和at()是非 const 成员函数，即使只读也会触发写权限检查，应改用find()+ 解引用
避免在锁内做耗时操作
unordered_map 的单次查找平均 O(1)，但高冲突下可能退化为 O(n)；如果在锁内执行长循环、字符串拼接、网络调用等，会严重拖慢其他线程。关键原则：
- 锁的范围越小越好：只包裹真正访问/修改容器的代码段
- 不要在锁里调用可能阻塞或重分配内存的操作（如
rehash()） - 写操作前可先用
find()判断是否存在，避免无谓的operator[]触发默认构造
自定义哈希函数不解决线程安全问题
优化哈希函数（比如用 MurmurHash 替代默认 std::hash<:string></:string>）能降低冲突率、提升单线程性能，但它对线程安全零影响。线程安全只取决于你如何同步访问容器本身。常见误区：
- 以为“冲突少了就不用锁”——错，只要并发读写同一容器，就必须同步
- 在哈希函数里访问全局状态（如静态计数器）——这反而引入新竞争点，需额外加锁
- 重载
std::hash时返回随机值或依赖时间——破坏哈希一致性，导致find失效
最易被忽略的是：即使只读，若容器在别处被修改（比如另一个线程调用了 insert），未加锁的读操作仍可能看到部分更新的桶结构，引发未定义行为。锁不是选配，是底线。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
