std::unordered_map不能直接用于多线程高频写场景，因其无内置同步机制，桶数组与节点链接修改非原子，多线程insert/erase会引发段错误、迭代器失效或数据损坏；标准库不保证任何并发安全，包括读-读。
为什么 std::unordered_map 不能直接用于多线程高频写场景
因为它的内部没有对插入、删除做原子保护，多个线程同时 insert() 或 erase() 会触发未定义行为——常见表现是段错误、迭代器失效、桶链表断裂，甚至静默数据损坏。标准库不承诺线程安全，连“读-读”并发都不保证（因 rehash 可能修改桶数组指针）。真正需要无锁，就得从内存模型和原子操作出发，绕过互斥锁的调度开销和争用停顿。
如何用 std::atomic + CAS 实现桶节点的无锁插入
核心是把每个哈希桶的头指针声明为 std::atomic<node></node>，插入新节点时用循环 CAS 替换头指针。关键不是“一次成功”，而是“失败后重试前重新读取最新头指针”，否则会丢失其他线程已插入的节点。
常见错误是写成单次 compare_exchange_weak() 就放弃；正确做法是：
- 先读取当前
head.load()得到旧值 - 构造新节点，
next指向该旧值 - 用
compare_exchange_weak(head, expected, new_node)尝试更新 - 若失败，
expected已被自动更新为当前实际值，直接跳回第二步重试
示例片段：
Node* old_head = head.load();
do {
new_node->next = old_head;
} while (!head.compare_exchange_weak(old_head, new_node));
为什么删除操作比插入更难，且必须引入标记-清除（tagged pointer）
单纯 CAS 替换头指针无法安全删除：线程 A 正在遍历链表，线程 B 删除了中间节点并释放内存，A 接着访问就会 dangling。解决方案是两阶段：先用高位 bit 标记节点为“逻辑删除”，再由后续插入/查找线程物理回收。这要求指针本身可携带 tag —— 在 x86_64 上，用户态地址低 16 位通常为 0，可用最低 bit 做 tag。
实际操作需：
- 将原始指针转为
uintptr_t，用位运算存取 tag - 所有 CAS 都作用于带 tag 的整数，而非裸指针
-
compare_exchange_weak必须用std::atomic<uintptr_t></uintptr_t>，否则无法原子更新指针+tag - 查找时遇到带 tag 节点，要跳过并帮助清理（如尝试 unlink）
哈希表扩容时如何避免全局停顿与 ABA 问题
扩容不能简单替换整个桶数组指针，否则正在遍历的线程可能跨桶访问到已释放内存。主流做法是分阶段迁移：新老桶数组共存，每次插入/查找都检查目标桶是否已迁移，未迁则顺带迁移一个节点。CAS 更新桶指针时，ABA 是真实风险——比如桶 A→B→A，但中间 B 已被释放重用，导致误判。
缓解方式包括：
- 用双字 CAS（如
__atomic_compare_exchange带 double-width 支持），把版本号和指针打包进一个 128-bit 原子变量 - 或改用 hazard pointer / epoch-based reclamation 管理内存生命周期，让旧桶数组延迟到所有线程都确认不再使用后再释放
- 禁止桶指针直接指向堆内存，统一用池化分配器管理，降低地址复用概率
这些机制不是锦上添花，而是无锁结构能存活的前提——漏掉任意一环，崩溃或数据错乱只是时间问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
