c++oding="utf-8" ?>
关键不是预分配与否，而是桶数是否匹配实际负载；load_factor() 在1.2～1.5时缓存利用率高、命中率更优，因桶数组紧凑且链表平均长度可控；超2.0才真正危险。
直接调用 reserve(n) 通常不会提升命中率，反而可能因桶数过度分配导致 L1 cache miss 上升——关键不是“有没有预分配”，而是“桶数是否匹配实际负载”。
为什么 load_factor() 高了反而 hit rate 更高？
命中率（hit rate）在这里指缓存友好性下的实际访问效率，不是指哈希表的查找成功比例。当 load_factor() 在 1.2～1.5 区间时，只要哈希函数分布均匀，桶内链表平均长度仍可控（≈1 + load_factor()/2），且桶数组更紧凑，L1 cache line 利用率更高；而设成 0.5 后桶数翻倍，每个 cache line 可能只装 1～2 个桶指针，空桶散列导致大量 cache miss。
- 实测中，
int→int映射在load_factor() ≈ 1.3时查询吞吐最高，比 0.5 快 12%～18% - 若观察到
bucket_size(i) > 8的桶大量出现，问题不在负载因子，而在哈希函数退化（比如对指针地址哈希却忽略低比特） -
load_factor() > 2.0才真正危险：此时平均链长超 2，冲突概率陡增，但不等于立即变慢——得看最大桶长是否突破硬件 prefetch 范围
如何用 bucket_count() 和 max_load_factor() 反推合理桶数？
别猜质数表。GCC 和 libc++ 的 reserve(n) 实际分配的是 ≥n 的最小质数，例如传 1000 得到 1009，传 1014 却跳到 1019。正确做法是让标准库自己算：
- 先调
umap.max_load_factor(0.75)—— 这步不分配内存，只改阈值 - 再调
umap.reserve(N)，其中 N 是你确认的最终元素总数 - 立刻检查
umap.bucket_count()，确认是否落在预期区间（比如 N=5000 → bucket_count() 应在 6600～6700 左右） - 如果偏差大（如得到 7001），说明当前质数表跳变剧烈，可手动
rehash(6667)强制设桶数（6667 是质数，且 5000/6667 ≈ 0.75）
rehash(0) 是收缩桶数组最安全的操作
批量删除后 size() 大幅下降，但 bucket_count() 滞后不变，遍历和迭代性能会明显劣化。此时 rehash(0) 不是“清空重来”，而是按当前 size() 和已设的 max_load_factor() 重新计算桶数并重建——它不拷贝元素，只调整桶指针数组。
- 错误做法：
reserve(size())—— 它会触发一次无谓扩容，因为reserve()语义是“为插入准备”，不是“为现状适配” - 正确时机：删掉 ≥70% 元素后、或插入前发现
load_factor() 且后续无大量插入 - 注意：MSVC 的
rehash(0)行为略有不同，建议统一用 GCC/Clang 测试后再上线
真正影响命中率的从来不是 load_factor() 数值本身，而是它背后反映的桶密度与 cache line 对齐关系。每次调 reserve() 或 rehash() 后，务必用 bucket_count() 和 bucket_size(i) 扫描真实分布，而不是依赖理论值。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
