std::unordered_map非线程安全因其无内置同步机制，多线程写入或rehash时引发未定义行为；细粒度桶锁可折中提升并发，而无锁实现则面临内存序、ABA及回收等复杂难题。
为什么标准std::unordered_map不能直接用于多线程写入
它内部没有同步机制，多个线程同时调用 insert、erase 或甚至 find（当触发 rehash 时）都会导致未定义行为。常见表现是段错误、迭代器失效、数据丢失，而非报错——这会让问题更难复现。
关键点在于：哈希表的扩容（rehash）需要重排所有桶，此时整个结构处于不一致状态；而 std::unordered_map 对此无保护。
- 即使只读操作，在其他线程执行插入/删除时也可能崩溃（因桶指针被移动或释放）
-
const成员函数不等于线程安全，C++ 标准库容器绝大多数都不是线程安全的 - 加一个全局
std::mutex虽简单，但会严重限制吞吐——高并发下锁争用成为瓶颈
细粒度锁哈希表：按桶分段加锁是否足够
把哈希表分成 N 个桶（bucket），每个桶配一个独立 std::shared_mutex 或 std::mutex，插入/查找时只锁对应桶。这是最常用且效果显著的折中方案。
它能大幅降低锁冲突概率，尤其在 key 分布均匀、哈希函数质量好时。但要注意几个现实约束：
立即学习“C++免费学习笔记（深入）”；
- 桶数量通常固定（如 256 或 1024），不可动态扩展；扩容需重建锁数组，期间要停写或用读写锁保护元数据
-
erase操作仍需持有桶锁，且若需遍历链表删除节点，可能需额外保证节点生命周期（避免 ABA 或悬垂指针） - 如果大量 key 落在同一个桶（哈希碰撞集中），该桶锁会退化为全局瓶颈
- 使用
std::shared_mutex可提升读多写少场景的并发度，但注意其开销比std::mutex高，且 Windows 上实现较慢
无锁哈希表的关键难点在哪
真正无锁（lock-free）的哈希表极少在生产环境手写，因为涉及太多易错细节：内存序（std::memory_order 组合）、ABA 问题、内存回收（如何安全释放被替换的节点）、以及 rehash 的原子切换。
目前主流选择是复用成熟实现，而非从零造轮子：
-
folly::AtomicUnorderedMap（Facebook Folly）基于 hazard pointer 实现，支持并发 insert/find/erase，但不支持动态 rehash -
tsl::robin_map提供可选的细粒度锁版本（tsl::rh::thread_safe_robin_map），底层用 per-bucket mutex，接口接近std::unordered_map - 自己实现 CAS-based 插入时，必须对桶头指针做
compare_exchange_weak，且每次修改都要考虑 load-acquire / store-release 配对，稍错就导致可见性 bug - 无锁 ≠ 无等待（wait-free）：大多数无锁哈希表在冲突严重时仍可能重试多次，甚至饿死某个线程
实际项目中怎么选：性能指标和取舍点
先测再选。用真实 workload（key 分布、读写比、平均 value 大小）压测，而不是凭直觉。
- 读写比 > 9:1 → 优先考虑
std::shared_mutex+ 细粒度桶锁，或tsl::rh::thread_safe_robin_map - 写多读少、且无法接受任何锁阻塞 → 查看
folly::AtomicUnorderedMap是否满足语义（它不保证迭代器一致性，也不支持 erase 后立即对 find 不可见） - value 很小（如
int）、key 是整数且范围可控 → 考虑分段数组替代哈希表，完全规避哈希和锁 - 调试困难度：无锁代码出问题往往表现为偶发 crash 或数据不一致，core dump 很难定位；细粒度锁的问题更容易通过锁竞争分析工具（如 Linux
perf record -e sched:sched_lock_wait）发现
真正的复杂点不在“怎么写”，而在“怎么验证正确性”——尤其是内存序和释放时机。哪怕抄一段已发表的无锁哈希表代码，改一个 memory_order 参数，都可能引入竞态。
