HashMap源码的解读-为何存取的性能很高的一个重要点

  相信HASHMap的原理大家都看过，这边就不再复习了，直接上源码，put方法：

public V put(K key, V value) {  
        //当key为null，调用putForNullKey方法，保存null与table第一个位置中，这是HashMap允许为null的原因  
        if (key == null)  
            return putForNullKey(value);  
        //计算key的hash值  
        int hash = hash(key.hashCode());                  ------(1)  
        //计算key hash 值在 table 数组中的位置  
        int i = indexFor(hash, table.length);             ------(2)  
        //从i出开始迭代 e,找到 key 保存的位置  
        for (Entry<K, V> e = table[i]; e != null; e = e.next) {  
            Object k;  
            //判断该条链上是否有hash值相同的(key相同)  
            //若存在相同，则直接覆盖value，返回旧value  
            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {  
                V oldValue = e.value;    //旧值 = 新值  
                e.value = value;  
                e.recordAccess(this);  
                return oldValue;     //返回旧值  
            }  
        }  
        //修改次数增加1  
        modCount++;  
        //将key、value添加至i位置处  
        addEntry(hash, key, value, i);  
        return null;  
    }  

通过看注释应该都了解了put方法的过程了吧，这边重点看下（1）、（2）两个步骤，这里是HashMap的精华所在：

static int hash(int h) {  
        h ^= (h >>> 20) ^ (h >>> 12);  
        return h ^ (h >>> 7) ^ (h >>> 4);  
    } 

首先是hash方法，该方法为一个纯粹的数学计算，就是计算h的hash值。

static int indexFor(int h, int length) {  
        return h & (length-1);  
    } 

我们知道对于HashMap的table而言，数据分布需要均匀（最好每项都只有一个元素，这样就可以直接找到），不能太紧也不能太松，太紧会导致查询速度慢，太松则浪费空间。计算hash值后，怎么才能保证table元素分布均与呢？我们会想到取模，但是由于取模的消耗较大，HashMap是这样处理的：

HashMap的底层数组长度总是2的n次方，在构造函数中存在：capacity <<= 1;这样做总是能够保证HashMap的底层数组长度为2的n次方。当length为2的n次方时，h&(length - 1)就相当于对length取模，而且速度比直接取模快得多，这是HashMap在速度上的一个优化点。

【运算简单讲解】：当然&运算相信很多人都忘记怎么运算的吧，这边再次复习一下：

逻辑上来说，假如有两个简单命题A和B，还有一个复合命题A与B。那么复合命题A与B的值就跟A的值和B的值有关。当且仅当A和B都为真时，A与B为真。在二进制中，一般是0为假，1为真，所以如果是1与1的话，结果就是1。其他的，如0与1，1与0，0与0的结果都是0...假设有一个数是11001,另一个是01101，那么它们与的结果就是：01001.对应的位做与运算就能得到结果。

而在JDK1.8中，对HashMap也做了性能上的优化，主要有2点：

1、在hash碰撞比较剧烈的时候，即默认一个Entry上的元素大于8的时候，会由链表存储改为红黑树进行存储。

2、在扩容的时候，也进行了改进，比如由16 -> 32时，index为15的桶中的元素不会重新计算hash值，而是在hashcode的基础上，进行高一位的计算，也就是 

 

newTab[e.hash & (newCap - 1)] = e;

元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：

因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”，可以看看下图为16扩充为32的resize示意图：

这个设计确实非常的巧妙，既省去了重新计算hash值的时间，而且同时，由于新增的1bit是0还是1可以认为是随机的，因此resize的过程，均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。有一点注意区别，JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，但是从上图可以看出，JDK1.8不会倒置。有兴趣的同学可以研究下JDK1.8的resize源码，写的很赞。