C++ unordered_map 与 map 的比较及选用

C++ unordered_map 与 map 的比较及选用

C++ STL 中 std::unordered_map 和 std::map 都是关联容器，用于存储键值对，但它们在实现和特性上有所不同，列举如下：

特性	std::map	std::unordered_map
底层数据结构	红黑树 (自平衡二叉搜索树)	哈希表
元素顺序	按键严格排序 (默认升序)	无序 (顺序由哈希值决定，不可预测)
查找时间复杂度	O(log n)	平均 O(1)，最坏情况 O(n)
插入/删除时间复杂度	O(log n)	平均 O(1)，最坏情况 O(n)
内存占用	通常较低 (树结构，无额外桶开销)	通常较高 (哈希表需预留桶空间以减少冲突)
键类型要求	键需支持 < 操作或提供自定义比较器	键需支持哈希函数 (std::hash) 和 == 比较
迭代器稳定性	稳定 (插入删除通常不会使现有迭代器失效，除非指向被删元素)	插入可能导致 rehash，使所有迭代器失效
范围查询	支持 (如 lower_bound(), upper_bound())	不支持

📌 何时选择 unordered_map 替代 map

是否用 unordered_map 替代 map，主要取决于我们的需求：

1. 追求极致查找、插入和删除速度：当你需要频繁进行查找、插入和删除操作，并且不关心元素的顺序时，应优先考虑 unordered_map，因其平均时间复杂度为 O(1) 。这在处理大量数据时性能优势非常明显。
2. 无需有序遍历或范围查询：如果你的应用场景不需要按键的顺序遍历，也不需要进行范围查询（例如“找出所有键在 A 到 C 之间的元素”），那么 unordered_map 通常是更优选择。
3. 键类型具有良好的哈希函数：确保你的键类型（如内置类型 int, string 等）在 std::hash 特化后能有效减少冲突。对于自定义类型，你需要为其提供良好、均匀的哈希函数。

对于本项目（我的这个应用）而言，快速查找相当重要，因此选择使用了 unordered_map 来提升性能。

📌 何时应坚持使用 map

尽管 unordered_map 在平均性能上更优，但以下情况 map 不可替代：

1. 需要元素有序或有序遍历：当业务逻辑要求元素按键的顺序存储、访问或输出时（例如按学号排序学生信息、按时间戳记录日志），必须使用 map。
2. 需要进行范围查询：如果你需要查找某个键范围内的所有元素（例如查找所有名字在 “A” 到 “C” 之间的学生），map 支持的 lower_bound() 和 upper_bound() 操作是 unordered_map 无法提供的。
3. 要求稳定的最坏情况性能：map 的 O(log n) 时间复杂度非常稳定。如果你所处的环境（如实时系统）无法承受哈希表最坏情况下 O(n) 的性能波动，map 更可靠。
4. 内存敏感或无法预留空间：在内存受限的环境（如嵌入式系统）中，map 通常比 unordered_map 更节省内存，因为后者需要预分配桶数组以避免频繁 rehash。
5. 自定义类型无良好哈希函数：如果为你的自定义键类型设计一个低碰撞的哈希函数很困难，但实现比较运算符 (<) 很容易，那么使用 map 会更简单。

💡 优化 unordered_map 的技巧

如果决定使用 unordered_map，可以通过以下方式提升其性能：

• 预留空间 (reserve())：如果提前知道要存储的元素数量，使用 reserve() 预分配足够的桶数，可以避免插入过程中的多次 rehash。
• 关注负载因子：负载因子（元素数/桶数）过高会增加冲突。默认最大负载因子通常为 1.0，超过则会自动 rehash。必要时可使用 rehash() 或 max_load_factor() 手动调整。
• 设计良好的自定义哈希函数：对于自定义类型作为键，设计一个分布均匀的哈希函数至关重要，能有效减少冲突。

💎 总结

选择 std::map 还是 std::unordered_map，本质上是在元素有序性、范围查询能力和平均操作速度、内存开销之间做权衡。

• 需要排序、范围查询或稳定性能？ → 选 map
• 追求极致的查找、插入速度且不关心顺序？ → 选 unordered_map

对于大多数纯粹的查找场景（如缓存、词频统计、快速配置查询），unordered_map 因其平均 O(1) 的时间复杂度而成为首选。C++11 标准将其引入后，为不需要顺序的场景提供了高性能的哈希表实现。