因为其桶数组与节点链接修改非原子，无内置同步机制；高频写入时粗粒度锁导致严重争用，吞吐量断崖下跌。
为什么 std::unordered_map 不能直接用于多线程高频写入场景
因为它的内部结构（桶数组 + 链表/红黑树）在插入、扩容、删除时都依赖互斥锁保护，一旦多个线程同时调用 insert 或 erase，会频繁争抢同一把锁，吞吐量断崖式下降。更关键的是，标准库没提供原子化地「读-改-写」单个桶的能力——而无锁哈希表的核心，恰恰要靠每个桶的独立原子控制来解耦竞争。
用 std::atomic 存桶指针时，为什么必须用 tagged pointer 技术避免 ABA 问题
CAS 循环中，若一个桶节点被释放 → 再分配 → 再被 CAS 成功，编译器和 CPU 看到的是相同地址，但语义已变。不加 tag 的纯指针比较会误判为「未变更」，导致链表断裂或重复插入。正确做法是把低 2–3 位腾出来存版本号或标记位：
-
uintptr_t对齐到 8 字节时，低 3 位恒为 0，可安全用于版本计数 - 每次 CAS 前，用
old_ptr & ~0x7提取真实地址，用(old_version + 1) & 0x7更新 tag - 实际存储时用
(real_ptr | new_tag)合并，CAS 比较整个uintptr_t
哈希桶数组扩容时如何做到无锁且不阻塞读写
核心是两阶段切换：先原子发布新桶数组指针，再逐个迁移旧桶。迁移本身不加锁，但每个桶用独立的 std::atomic<bool></bool> 标记是否完成迁移；读操作遇到正在迁移的桶，就同时查新旧两个桶。
- 扩容触发条件建议设为「负载因子 > 0.75 且当前无进行中的扩容」，避免频繁触发
- 迁移线程应主动让出 CPU（
std::this_thread::yield()），防止独占核心饿死其他线程 - 读操作对旧桶的访问需用
memory_order_acquire，确保看到迁移完成后的最新状态 - 绝对不要在扩容中直接
delete[]旧数组——要等所有线程确认不再访问后，由专门的回收线程延时释放
insert() 中的 CAS 循环为什么不能简单 while(true)，而要加指数退避
高竞争下，无数线程在同一地址上空转 CAS，不仅浪费 CPU，还会因缓存行乒乓（cache line bouncing）拖垮整个内存子系统性能。退避不是为了「等锁释放」，而是给其他线程机会完成操作、降低总线争用。
- 初始休眠 0 次，失败后休眠 1、2、4… 次
PAUSE指令（x86）或std::this_thread::yield() - 超过 16 轮仍未成功，建议记录日志并检查哈希函数是否严重倾斜
- 注意：
std::atomic::compare_exchange_weak可能伪失败，必须在循环内重读当前值，不能复用旧快照
真正难的不是写出 CAS 循环，而是判断哪个内存序够用、哪个地方该用 acquire 而不是 relaxed、以及如何让迁移逻辑与读写逻辑在无锁前提下达成一致的可见性边界——这些细节错一点，bug 就只在百万级 QPS 下偶发出现。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
