Java中使用Integer作为HashMap键的疑问及hashCode实现探讨

嘿，这个问题挺有代表性的，我来帮你理清楚这两个疑问：

1. 你关于Integer作为HashMap键的结论是否正确？ #

结论是错误的，你忽略了HashMap本身对哈希值的二次处理逻辑。

咱们先看JDK中HashMap的哈希计算逻辑（以JDK8为例）：

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

当你把Integer作为键放入HashMap时，不会直接用Integer.hashCode()的返回值来计算桶索引，而是先通过上面的hash方法做扰动处理：把hashCode的高16位和低16位进行异或，这样能让高16位的特征也参与到桶索引的计算中。

之后，HashMap会用这个扰动后的哈希值和桶容量（默认是16，且始终是2的幂）做位运算（hash & (capacity - 1)）来确定桶的索引。举个具体的例子：

• 当i=1时，hashCode是1，扰动后的值是1 ^ (1 >>>16) = 1，桶索引是1 & 15 =1
• 当i=2时，扰动后的值是2，桶索引是2&15=2
• ...
• 当i=16时，hashCode是16，扰动后的值是16 ^ 0 =16，桶索引是16&15=0

可以看到，连续的Integer键会被分配到不同的桶中，完全不会出现“都放入同一个桶”的情况。所以Integer不仅不是HashMap键的最差候选，反而是非常优秀的键类型——因为它的哈希值计算高效，且经过HashMap的扰动后分布很均匀。

2. 为何Integer的hashCode()不采用复杂方式实现？ #

主要有这几个原因：

• 本身值的分布已经足够均匀：Integer的底层是int值，int本身在整个范围内是均匀分布的，不需要额外的哈希算法来调整分布。
• HashMap已经做了二次哈希处理：正如上面提到的，HashMap会对所有键的hashCode做扰动处理，Integer如果再自己做复杂哈希，反而可能破坏原本的均匀性，还会增加不必要的计算开销。
• 符合基础类型包装类的设计定位：Integer作为int的包装类，追求的是简单、高效的映射，直接返回底层int值是最直观、性能最优的实现方式，同时也完美符合hashCode的约定——两个equals的Integer（即int值相等），hashCode必然相等。
• 避免哈希冲突的额外风险：复杂的哈希算法可能会引入新的冲突场景，而直接返回int值的方式，冲突只可能出现在两个不同的Integer对象但int值相等的情况（但这种情况equals也会返回true，符合哈希表的要求）。

内容的提问来源于stack exchange，提问作者oreh