HashMap源码解析

Java 8系列之重新认识HashMap
关于HashMap，上面链接里美团团队出的文章已经很好了。这篇博客详细聊一下HashMap里几个关键的算法。

二次hash算法

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

源码只有一行，分为3步：

• h = key.hashCode(),取到哈希码
• h >>> 16，哈希码无符号右移16位（原长度32位），高位补0。这一步相当于把哈希码的高16位变成低位。
• h 和右移的结果做异或。由于h >>> 16后高16位为0，任何数和0异或都是其本身，所以这一步保证了二次hash的结果中，高16位不变，低16位有key.hashCode()高位和低位的特征。

为什么要这样做呢？和hashMap中下标计算有关，往下看。

取下标算法

n = table.length;
index =  (n-1) & hash;

由于n = table.length必为2的x次幂，(n-1) & hash时：

• 只要x <= 16即数组长度小于65535时,hash中只有低16位参与了运算。所以二次hash算法中低位结合了高位的特征，就是为了减小hash碰撞。
• (n-1) & hash等效于hash / n，即求余操作。举个栗子，n=16时，如下：

hash值   10101010
n-1      00001111
——————————————————
&        00001010  // 和1与时不变，和0与时=0

通过位运算实现了等效于求余的算法，效率更高。

tableSizeFor()

把构造函数传入的表示长度的任意数字优化为最接近它的2的n次幂的值，比如传入6，最终为8，传入129，最终为256。

    static final int MAXIMUM_CAPACITY = 1 << 30;
    /**
     * Returns a power of two size for the given target capacity.
     */
    static final int tableSizeFor(int cap) {
        int n = cap - 1;
        n |= n >>> 1;
        n |= n >>> 2;
        n |= n >>> 4;
        n |= n >>> 8;
        n |= n >>> 16;
        return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
    }

下面分析这个算法：
首先，为什么要对cap做减1操作。int n = cap - 1;
这是为了防止，cap已经是2的幂。如果cap已经是2的幂， 又没有执行这个减1操作，则执行完后面的几条无符号右移操作之后，返回的capacity将是这个cap的2倍。如果不懂，要看完后面的几个无符号右移之后再回来看看。
下面看看这几个无符号右移操作：
如果n这时为0了（经过了cap-1之后），则经过后面的几次无符号右移依然是0，最后返回的capacity是1（最后有个n+1的操作）。
这里只讨论n不等于0的情况。
第一次右移

n |= n >>> 1;

由于n不等于0，则n的二进制表示中总会有一bit为1，这时考虑最高位的1。通过无符号右移1位，则将最高位的1右移了1位，再做或操作，使得n的二进制表示中与最高位的1紧邻的右边一位也为1，如000011xxxxxx。
第二次右移

n |= n >>> 2;

注意，这个n已经经过了n |= n >>> 1; 操作。假设此时n为000011xxxxxx ，则n无符号右移两位，会将最高位两个连续的1右移两位，然后再与原来的n做或操作，这样n的二进制表示的高位中会有4个连续的1。如00001111xxxxxx 。
第三次右移

n |= n >>> 4;

这次把已经有的高位中的连续的4个1，右移4位，再做或操作，这样n的二进制表示的高位中会有8个连续的1。如00001111 1111xxxxxx 。
以此类推
注意，容量最大也就是32bit的正数，因此最后n |= n >>> 16; ，最多也就32个1，但是这时已经大于了MAXIMUM_CAPACITY ，所以取值到MAXIMUM_CAPACITY 。
举个栗子，如果构造函数里传入的数组长度是13，二进制为1101，经过n |= n >>> 1后还是1101,再n |= n >>> 2，为1111，1111后续右移4、8、16都为0000，再求或还是它本身。最后return n+1，即为1111 + 1 = 10000，即十进制的16，大功告成。

resize() 扩容算法

java 8 的扩容算法因为引入了红黑树，所以比较复杂，我们只提其中比较关键的地方：扩容后怎么确认新下标？
首先要知道扩容是2倍扩容，长度依然为2的次幂。
常规思路当然是重走一次index = (table.length-1) & hash，java 8之前确实是这样做的。

java8优化了这个算法：只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap，即hash & oldCap == 0”。
上面这句话是啥意思？举个例子：

// 假设hash值为10101010，原数组长度为8，扩容后为16，根据(table.length-1) & hash 即为
         10101010
oldCap-1 00000111
——————————————————
  &      00000010

         10101010
newCap-1 00001111
——————————————————
  &      00001010
//  oldIndex即为hash前三位的值010，newIndex是hash前四位的值1010。
//  关键在新增的这一位，为0时 oldIndex=newIndex，位置不变；为1时newIndex = oldIndex + oldCap
// 所以这里无需再计算(table.length-1) & hash，只要判断新增的这一位是0还是1就可以；

         10101010
oldCap   00001000
——————————————————
  &      00001000
// 直接hash & oldCap == 0，true 时新增的bit为0；index不变，false 时为1，newIndex = oldIndex + oldCap

总结

所以HashMap的长度为什么要优化为2的次幂？从上面的算法可以看出：

1. 取下标算法(table.length-1) & hash ，当length为2的次幂时，等效于求余，比求余效率更高。
2. 扩容时只需要判断新增的那个bit即可确定下标。