【C++】unordered_map在Windows和Linux上的不同行为

我目前手头上的项目，需要编译在板端Linux上运行，但是日常daily调试多在Windows上开发。这就涉及到同一份代码在多平台上的编译个运行。有一次遇到了一个奇怪的现象：跑同样的一份代码，Windows和Linux出来的结果是不一致的。最终确定到不一致的原因出现在unordered_map上，就把这次记录总结下来。

这次不一致发生在：处理一个状态序列的投票操作。从编程的角度而言，最适合投票操作的容器就是键值对，key放置投票的内容，value放置投票的次数。在C++中，STL提供了两个相关容器：map和unordered_map。在代码上选择了unordered_map来实现。

问题复现

我把这个问题简化：假设车的类型有四种情况，分别为UNKNOWN、SMALL、MIDDLE、BIG。现有15次的估计，以出现次数最多的类型作为其最终类型。代码非常简单：

#include <iostream>
#include <unordered_map>
#include <string>int main()
{std::unordered_map<std::string, int> vehs;vehs["UNKNOWN"] = 5;vehs["SMALL"] = 3;vehs["MIDDLE"] = 5;vehs["BIG"] = 2;std::string max_type;int max_times = -1;auto iter = vehs.begin();for (; iter != vehs.end(); ++iter) {if (iter->second > max_times) {max_times = iter->second;max_type = iter->first;}std::cout << iter->first << " ";}std::cout << std::endl;std::cout << "max_type : " << max_type << std::endl;return 0;
}

在Windows平台下，编译并运行代码：

BIG UNKNOWN SMALL MIDDLE
max_type : UNKNOWN

在Linux平台下，编译并运行代码：

BIG MIDDLE SMALL UNKNOWN
max_type : MIDDLE

可以看到，在Windows和Linux两个平台下的运行结果中，出现次数最多的车的类型，一个为UNKNOWN，一个为MIDDLE。主要原因是这两种类型都是5次（最多）。这时，unordered_map的遍历顺序就很重要了，这将直接关系到最终的输出结果。通过打印结果可以看到，两个平台下的遍历顺序是不一致的。

在C++中，STL提供了两个键值对容器：map和unordered_map。上面的代码，采用的是unordered_map容器，如果将其改成map容器呢？还会发生这种不一致的结果么？

std::map<std::string, int> vehs;    // 将unordered_map修改为map

此时再在Windows和Linux平台下，分别编译并运行代码，最终的输出都是一致的：

BIG MIDDLE SMALL UNKNOWN
max_type : MIDDLE

也就是说，这种平台不一致性只发生在unordered_map容器上，而不发生在map容器上。

原因分析

map和unordered_map分别在Windows和Linux上的不同运行结果，主要体现在遍历顺序上。对于map而言，两个平台上的遍历顺序是一致的；而对于unordered_map而言，两个平台上的遍历顺序是不一致的。

遍历顺序的不同，究其根本，主要体现在其内部构造的不同：

map的内部构造：

map的内部实现了一个红黑树（红黑树是非严格平衡二叉搜索树，而AVL是严格平衡二叉搜索树），红黑树具有自动排序的功能，因此map内部的所有元素都是有序的。红黑树的每一个节点都代表着map的一个元素。因此，对于map进行的查找，删除，添加等一系列的操作都相当于是对红黑树进行的操作。

unordered_map的内部构造：

unordered_map的内部实现了一个哈希表（也叫散列表，通过把关键码值映射到Hash表中一个位置来访问记录，查找的时间复杂度可达到O(1)，其在海量数据处理中有着广泛应用）。因此，其元素的排列顺序是无序的。

两者在运行效率和占用内存的对比：

运行效率方面：unordered_map最高，而map效率较低，但提供了稳定效率和有序的序列
占用内存方面：map内存占用略低，unordered_map内存占用略高，而且是线性成比例的

需要无序容器，快速查找删除，不担心略高的内存时可以选择unordered_map；需要有序容器稳定查找删除效率，内存很在意时候用map。

因此，如果需要使用map，那么key需要定义operator<，用于进行有序的排序；如果需要使用unordered_map，那么key需要定义hash_value函数并且定义operator==，用于hash值的计算。而：

当使用map时，Windows和Linux对于operator<的定义都是一致的
当使用unordered_map时，Windows和Linux对于operator==的定义都是一致的，对于hash_value函数的定义是不一致的

从而，在使用unordered_map时，Windows和Linux使用两种不同的哈希函数，产生不同的哈希码，从而依次产生不同的存储区放置，导致在迭代时产生不同的顺序。