reserve()调优后性能更差，因其预分配不小于n的最小质数个桶，易导致过度分配；应结合max_load_factor()与rehash()合理控制桶数，并在Release模式下实测验证。
为什么reserve()调优后性能反而更差？
直接调用 reserve(n) 不等于“分配 n 个桶”，它实际预分配的是**不小于 n 的最小质数个桶**（GCC libstdc++ 和 Clang libc++ 均如此）。若你传入的 n 接近但略小于某个质数阈值，reserve() 可能触发一次远超预期的内存分配（比如想 reserve 1000，结果分了 1009 个桶；但若传 1008，可能跳到 1013 或更大质数），而后续插入若远未填满，就会造成大量空桶 + 缓存行浪费。
- 查当前实现的质数表：GCC 在
libstdc++/src/c++11/hashtable_c++0x.cc里硬编码了质数序列，libc++ 也类似 —— 别猜，用bucket_count()实测 - 真正安全的
reserve()值：先估算最终元素总数N，再调用umap.max_load_factor(0.75); umap.reserve(N);，让标准库自己按负载因子反推桶数 - 避免在循环中反复
reserve()：它会清空哈希表并重建桶数组，等价于一次全量 rehash
load_factor() 超过 1.0 就一定慢？
不是。标准不强制要求 load_factor() > 1.0 就必须降速，关键看冲突链长度。现代 unordered_map（C++11 起）使用“桶+单向链表”结构，平均查找时间 ≈ 1 + load_factor() / 2（理想散列下），但真实场景中，只要哈希函数分布均匀，load_factor() 达到 1.2～1.5 仍可能比低负载但哈希碰撞严重的 0.6 更快。
- 真正拖慢的是长冲突链：用
umap.bucket_size(i)扫描最大桶长，若 > 8，优先检查自定义哈希函数是否退化（例如对指针地址哈希却忽略低比特） -
max_load_factor(0.5)并不总更好：它会让桶数翻倍，L1 cache miss 概率上升，尤其在小对象（如int→int）高频查询时，实测可能慢 10%～20% - 负载因子是动态的：插入/删除都会影响，不要只在初始化时设一次；批量插入后建议调用
rehash(0)强制按当前size()和max_load_factor()重算桶数
什么时候该用 rehash() 而不是 reserve()？
reserve(n) 是“我打算插入约 n 个元素，请提前准备好桶”，而 rehash(n) 是“请立刻把桶数设为至少 n”，它会强制触发 rehash（即使当前 size() 很小）。两者语义不同，误用会导致无谓开销。
- 用
rehash()的典型场景：你刚删掉大量元素，size()从 10000 降到 200，但bucket_count()还是 10007 —— 此时rehash(256)可收缩桶数组，减少内存占用和遍历开销 - 用
reserve()的典型场景：已知要插入 5000 个键，且不会中途删除 —— 先reserve(5000)，再循环insert()，避免多次扩容 - 注意：
rehash(0)是合法调用，它让容器按当前size()和max_load_factor()自动计算新桶数，比手算更可靠
自定义哈希与 reserve() 的隐式耦合
如果你用了自定义哈希函数（比如 std::hash<:string></:string> 替换为 SipHash），但没同步调整 max_load_factor()，reserve() 的效果会打折。因为 reserve 依赖默认负载策略，而新哈希的碰撞率可能显著不同。
立即学习“C++免费学习笔记（深入）”；
- 实测建议：对同一数据集，分别跑
max_load_factor(0.75)和max_load_factor(1.0)+reserve(N)，用chrono::high_resolution_clock测 insert + find 组合耗时 - 别忽略键类型的布局：
std::unordered_map<:string int></:string>中，std::string的 small string optimization（SSO）会影响哈希计算成本，进而改变最优负载区间 - 最易被忽略的一点：调试版本（Debug build）下
unordered_map通常禁用优化、增加检查逻辑，reserve()效果几乎不可见 —— 性能测试务必在 Release 模式下进行，且关闭_GLIBCXX_DEBUG等宏
