哈希表冲突导致插入变慢需控制负载因子并定制哈希：构造时用reserve()预分配桶数，自定义key需合理组合字段避免聚集，慎用std::string作key；absl::flat_hash_map因连续存储和探测法更缓存友好；分片可提升并发性能，但须保障哈希映射均衡；哈希函数质量优先于容器选型。
哈希表冲突导致 std::unordered_map 插入变慢怎么办？
高吞吐下冲突多，本质是桶数不足或哈希分布不均，不是单纯换容器就能解决的。关键在控制负载因子和定制哈希。
- 默认
std::unordered_map在负载因子 > 1.0 时自动 rehash，但 rehash 是 O(N) 操作，会卡住线程；建议构造时用reserve()预分配足够桶数，比如预估 100 万条数据，直接reserve(2000000) - 自定义类型做 key 时，
std::hash特化若只返回id字段，而大量数据id连续（如递增 ID），会导致哈希值聚集在同一段桶区间——改用std::hash_combine或异或多个字段 - 避免用
std::string作 key：每次计算哈希要遍历字符串，且小字符串容易哈希碰撞；可考虑存std::string_view+ 外部字符串池，或用固定长度 ID 替代
为什么 absl::flat_hash_map 比 std::unordered_map 更适合高吞吐？
它把 key/value 存在连续内存块里，没有指针跳转、无动态分配节点，缓存友好性高，冲突处理也更轻量。
-
absl::flat_hash_map使用探测法（probe sequence）而非链地址法，查找失败时平均只需几次 cache line 访问；而std::unordered_map每次冲突都要跳指针，容易 cache miss - 它要求 key 可默认构造、可移动、支持 ==，且不保证迭代器稳定——如果业务需要遍历时插入/删除，不能直接替换
- 编译时需开启
-O2以上，否则探测循环可能未被优化，性能反不如标准库
冲突太多时，std::unordered_map::bucket_count() 和 load_factor() 怎么看？
这两个值必须一起看，单独看没意义。桶太少但元素少，没问题；桶多但元素更密，反而更糟。
- 运行时检查：打印
map.bucket_count()和map.load_factor()，理想负载因子控制在 0.5～0.75；超过 0.8 就该reserve()了 - 注意
bucket_count()返回的是当前桶数量，不是质数——GCC 实现用质数，Clang/libc++ 用 2 的幂，不同 STL 行为不一致，别硬编码桶数 - 调试时加个断点观察
map.begin()->second所在桶号：map.bucket(*map.begin())，如果多个 key 返回相同桶号且load_factor()很低，基本确定是哈希函数写错了
并发写入哈希表时，用读写锁还是分片？
单把锁保护整个 std::unordered_map 是性能瓶颈；分片能线性扩展，但要注意哈希值到分片的映射不能有偏斜。
立即学习“C++免费学习笔记（深入）”；
- 分片数建议设为 CPU 核心数的 2–4 倍，比如 32 核机器用 64 个
absl::flat_hash_map实例，用hash(key) & 0x3F映射（比取模快） - 避免用
std::mutex包裹每个分片——C++20 前没有无锁 mutex，争用仍存在；改用std::shared_mutex（读多写少）或原子计数器+双检锁初始化 - 如果写操作带条件（如“不存在才插入”），分片后无法原子跨片判断，得退回到全局锁或改用
folly::AtomicUnorderedMap这类专用结构
哈希表优化最易被忽略的点：哈希函数质量永远优先于容器选型。一个糟糕的 operator() 特化，能让再快的底层结构退化成链表。上线前务必用真实数据跑一次哈希分布直方图。
