HashMap中为什么用hash(Object key)
为什么不直接用hahCode方法而是重新定义一个hash()方法,且使用(h = key.hashCode()) ^ (h >>> 16)运算呢
根据注释得出
计算key.hashCode()并将哈希值的较高位散列值与低位异或。因为该表使用2的幂掩码,所以仅在当前掩码之上的位数变化的散列集将始终冲突。(已知的例子包括在小表中保存连续整数的Float键集合。)。因此,我们应用一个转换,将高位的影响向下传播。在比特扩展的速度、效用和质量之间存在折衷。因为许多常见的散列集已经合理分布(因此不会从扩散中受益),并且因为我们使用树来处理箱中的大型冲突集,所以我们只是以尽可能最便宜的方式对一些移位的位进行异或运算,以减少系统损失,并纳入由于表界限的原因而永远不会在索引计算中使用的最高位的影响。
如果直接使用hashCode方法当hashmap n(长度)比较小时,比如n=8(111),根据hashmap中数组的下标算法(n - 1) & hash
那么每一次都只有hash值中的最低的3位参与运算
即
0000 0100 1011 0011 1101 1111 1110 0001
&
0000 0000 0000 0000 0000 0000 0000 0111
=
0000 0000 0000 0000 0000 0000 0000 0001
可以看出这样运算得出的下标更加容易冲突
所以为了让冲突更小,把hashCode求得的高16位与低16位先进行异或运算,这样每一次与 n - 1 & 运算的hash不再相同
至于为什么一定是异或运算而不是与或非,是因为&和|都会使得结果偏向0或者1 ,为了更随机, 所以用^