c++中如何使用unordered_map_c++哈希表容器用法详解

unordered_map需包含头文件，属std命名空间，底层为哈希表，平均O(1)、最坏O(n)；声明为std::unordered_map，Key需支持==和哈希函数；operator[]会默认构造value，at()抛异常，insert/emplace不覆盖且返回插入结果；仅支持迭代器遍历，不维护顺序；建议预reserve避免rehash，合理设置max_load_factor优化性能。

unordered_map 的基本声明和头文件依赖

必须包含 头文件，且命名空间为 std。它不是传统顺序容器，不保证元素顺序，底层是哈希表实现，平均时间复杂度为 O(1) 的查找、插入、删除 —— 但最坏情况（大量哈希冲突）会退化到 O(n)。

声明格式为：std::unordered_map，日常使用只需前两个模板参数：

std::unordered_map word_count;
std::unordered_map id_to_name;

注意：Key 类型必须支持 == 比较，且必须有对应的哈希函数。内置类型（int、long、std::string 等）已提供特化，自定义结构体需手动提供 std::hash 特化或传入自定义 Hash 函数对象。

插入与访问：operator[]、insert 和 at 的区别

operator[] 最常用，但有副作用：若 key 不存在，会默认构造 value 并插入（对 int 是 0，对 std::string 是空串）。这在只读场景下容易误插脏数据。

• word_count["hello"]++; → 若无 "hello"，先插入 {"hello", 0}，再 ++ 变成 1
• word_count.at("hello") → 若 key 不存在，抛出 std::out_of_range 异常，适合明确要求 key 必须存在时
• word_count.insert({key, value}) 或 word_count.emplace(key, value) → 不覆盖已有 key，返回 std::pair，second 表示是否插入成功

推荐在计数类逻辑中用 operator[]，在配置加载、映射查表等关键路径中优先用 at() 或检查 insert 返回值。

遍历 unordered_map：为什么不能用下标？

unordered_map 不支持随机访问，没有 operator[] 以外的下标语法，也不能用 at(i) 或 data()。只能通过迭代器遍历：

for (const auto& pair : word_count) {
    std::cout << pair.first << ": " << pair.second << "\n";
}

注意：pair.first 是 key，pair.second 是 value；若需修改 value，用 auto& 而非 const auto&；若要按 key 排序输出，得先拷贝到 std::vector 再 std::sort —— 它本身不维护顺序。

另外，迭代器失效规则比 map 更宽松：只有触发 rehash（如 rehash() 或插入导致负载因子超限）时，所有迭代器才失效；单次 insert/erase 不会使其他迭代器失效（除非 rehash 发生）。

性能调优：load_factor、reserve 和 hash 冲突处理

默认最大负载因子是 1.0，即平均每个桶最多 1 个元素。当 size() / bucket_count() > max_load_factor() 时自动 rehash，开销较大。若已知最终规模，应提前 reserve(n)（分配至少能容纳 n 个元素的桶数），而非 resize(n)（那是 vector 的）。

• word_count.reserve(10000); → 避免多次 rehash
• word_count.max_load_factor(0.75); → 主动降低负载以减少冲突（但增加内存占用）
• 若自定义类型作 key 且哈希分布差（如全返回 0），会导致单链过长，退化为链表查找 —— 此时必须重写哈希函数，不能只重载 operator==

调试时可打印 word_count.load_factor() 和 word_count.bucket_count() 观察实际分布。真正影响性能的往往不是哈希函数本身，而是 key 的实际分布是否均匀 —— 比如用连续整数作 key，std::hash 是良构的；但用指针地址作 key，在 ASLR 下可能集中于某几段值域，仍需谨慎。