HashMap JDK1.7和1.8区别（完整版）

不说废话了，开门见山，看网上的总结都比较片面，整个全乎的。

存储方式

这点大家耳熟能详，JDK1.7采用的是数组+链表的形式，而JDK1.8在数组容量大于64且链表长度大于8的情况下会使用红黑树。源码里也有很详细的解释，这里不过多赘述。
详情可以参考我另一篇博客
HashMap部分源码的理解

初始化方式

在JDK1.7中，table数组默认值为EMPTY_TABLE，在添加元素的时候判断table是否为EMPTY_TABLE来调用inflateTable。在构造HashMap实例的时候默认threshold阈值等于初始容量。当构造方法的参数为Map时，调用inflateTable(threshold)方法对table数组容量进行设置。

public HashMap(Map<? extends K, ? extends V> m) {
     
    this(Math.max((int) (m.size() / DEFAULT_LOAD_FACTOR) + 1,
                    DEFAULT_INITIAL_CAPACITY), DEFAULT_LOAD_FACTOR);
    inflateTable(threshold);

    putAllForCreate(m);
}

而在JDK1.8中初始化的过程则是直接集成到了resize()函数中

扰动函数变化

在JDK1.7中的扰动函数源码

final int hash(Object k) {
     
        int h = hashSeed;
        if (0 != h && k instanceof String) {
     
            return sun.misc.Hashing.stringHash32((String) k);
        }
 
        h ^= k.hashCode();
 
        // This function ensures that hashCodes that differ only by
        // constant multiples at each bit position have a bounded
        // number of collisions (approximately 8 at default load factor).
        h ^= (h >>> 20) ^ (h >>> 12);
        return h ^ (h >>> 7) ^ (h >>> 4);
}

而在JDK1.8中

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

上面两段源码分别是两个版本的扰动函数，可以看到1.8中简化了不少

我们可以看到，以352个字符串来做测试，在bits较低的情况下，扰动函数的collisions概率会有10%左右的降低
至于扰动函数的作用，涉及到另一段源码

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

这个函数就是用来取下标的，但这时，就算散列值分布再松散，只取最后几位的话碰撞依然会很严重，在随机少量的情况下影响尤为大，所以引入了扰动函数来减少hash碰撞，而至于为什么JDK1.8进行了缩减，可能是因为做多了离散分布提升不明显，还是为了效率考虑，进行了缩减。

存放数据的规则

这点源码包括我的另一篇博客说的比较清楚了
HashMap部分源码的理解

插入数据的方式

在1.7中使用的是头插法，1.8改成了尾插法，为了避免头插法导致的在多线程的情况下hashmap在put元素时产生的环形链表的问题，但1.8仍然存在数据覆盖的问题，所以仍然不是线程安全的
那么具体而言呢？
JDK1.8数据覆盖
JDK1.7环形链表
这两篇文章写得非常好，
TIPS:请大家读的时候务必自己参照源码，否则理解起来比较困难

扩容后存储位置的计算方式

这一点在之前的面试中我遗漏了，现在好好补充一下
扩容也是就是resize()方法，在两个版本中都有对应的源码

扩容的情况

存在两种情况：

• 设定threshold, 当threshold = 默认容量（16） * 加载因子（0.75）的时候，进行resize()

• 如上文所说，treeifyBin首先判断当前hashMap的长度，如果不足64，只进行resize，扩容table，同时最小树形化容量阈值：即 当哈希表中的容量 > 该值时，才允许树形化链表，因为树化本身就是一个效率不高的操作，因为红黑树非常复杂，涉及到了自旋的问题，所以hashmap的设计者也将树化的长度设置为8，因为经过概率计算，8是一个比较难达到的链表长度，在链表长度比较小的时候，虽然是O（n），但并不会对效率有什么影响。

在JDK1.7中，源码如下

void resize(int newCapacity) {
     
　　　　Entry[] oldTable = table;
　　　　int oldCapacity = oldTable.length;
　　　　//判断是否有超出扩容的最大值，如果达到最大值则不进行扩容操作
　　　　if (oldCapacity == MAXIMUM_CAPACITY) {
     
　　　　　　threshold = Integer.MAX_VALUE;
　　　　　　return;
　　　　}
 
　　　　Entry[] newTable = new Entry[newCapacity];
　　　　// transfer()方法把原数组中的值放到新数组中
　　　　transfer(newTable, initHashSeedAsNeeded(newCapacity));
　　　　//设置hashmap扩容后为新的数组引用
　　　　table = newTable;
　　　　//设置hashmap扩容新的阈值
　　　　threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
　　}
 
void transfer(Entry[] newTable, boolean rehash) {
     
　　　　int newCapacity = newTable.length;
　　　　for (Entry<K,V> e : table) {
     
　　　　　　while(null != e) {
     
　　　　　　　　Entry<K,V> next = e.next;
　　　　　　　　if (rehash) {
     
　　　　　　　　　　e.hash = null == e.key ? 0 : hash(e.key);
　　　　　　　　}
　　　　　　　　//通过key值的hash值和新数组的大小算出在当前数组中的存放位置
　　　　　　　　int i = indexFor(e.hash, newCapacity);
　　　　　　　　e.next = newTable[i];
　　　　　　　　newTable[i] = e;
　　　　　　　　e = next;
　　　　　　}
　　　　}
　　}

可以看到在1.7中，借助transfer()方法（jdk1.8中已移除），在扩容的时候会重新计算threshold，数组长度并进行rehash，这样的效率是偏低的
在1.8中

final Node<K,V>[] resize() {
     
        Node<K,V>[] oldTab = table;//首次初始化后table为Null
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;//默认构造器的情况下为0
        int newCap, newThr = 0;
        if (oldCap > 0) {
     //table扩容过
             //当前table容量大于最大值得时候返回当前table
             if (oldCap >= MAXIMUM_CAPACITY) {
     
                threshold = Integer.MAX_VALUE;
                return oldTab;
            }
            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                     oldCap >= DEFAULT_INITIAL_CAPACITY)
            //table的容量乘以2，threshold的值也乘以2           
            newThr = oldThr << 1; // double threshold
        }
        else if (oldThr > 0) // initial capacity was placed in threshold
        //使用带有初始容量的构造器时，table容量为初始化得到的threshold
        newCap = oldThr;
        else {
       //默认构造器下进行扩容  
             // zero initial threshold signifies using defaults
            newCap = DEFAULT_INITIAL_CAPACITY;
            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
        }
        if (newThr == 0) {
     
        //使用带有初始容量的构造器在此处进行扩容
            float ft = (float)newCap * loadFactor;
            newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                      (int)ft : Integer.MAX_VALUE);
        }
        threshold = newThr;
        @SuppressWarnings({
     "rawtypes","unchecked"})
        Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
        table = newTab;
        if (oldTab != null) {
     
            for (int j = 0; j < oldCap; ++j) {
     
                HashMap.Node<K,V> e;
                if ((e = oldTab[j]) != null) {
     
                    // help gc
                    oldTab[j] = null;
                    if (e.next == null)
                        // 当前index没有发生hash冲突，直接对2取模，即移位运算hash &（2^n -1）
                        // 扩容都是按照2的幂次方扩容，因此newCap = 2^n
                        newTab[e.hash & (newCap - 1)] = e;
                    else if (e instanceof HashMap.TreeNode)
                        // 当前index对应的节点为红黑树，这里篇幅比较长且需要了解其数据结构跟算法，因此不进行详解，当树的高度小于等于UNTREEIFY_THRESHOLD则转成链表
                        ((HashMap.TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                    else {
      // preserve order
                        // 把当前index对应的链表分成两个链表，减少扩容的迁移量
                        HashMap.Node<K,V> loHead = null, loTail = null;
                        HashMap.Node<K,V> hiHead = null, hiTail = null;
                        HashMap.Node<K,V> next;
                        do {
     
                            next = e.next;
                            if ((e.hash & oldCap) == 0) {
     
                                // 扩容后不需要移动的链表
                                if (loTail == null)
                                    loHead = e;
                                else
                                    loTail.next = e;
                                loTail = e;
                            }
                            else {
     
                                // 扩容后需要移动的链表
                                if (hiTail == null)
                                    hiHead = e;
                                else
                                    hiTail.next = e;
                                hiTail = e;
                            }
                        } while ((e = next) != null);
                        if (loTail != null) {
     
                            // help gc
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        if (hiTail != null) {
     
                            // help gc
                            hiTail.next = null;
                            // 扩容长度为当前index位置+旧的容量
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }

从上面的源码中可以分析出扩容分为三种情况：
第一种是初始化阶段，此时的newCap和newThr均设为0，从之前的源码可知，第一次扩容的时候，默认的阈值就是threshold = DEFAULT_INITIAL_CAPACITY * DEFAULT_LOAD_FACTOR = 12。而 DEFAULT_INITIAL_CAPACITY为16， DEFAULT_LOAD_FACTOR 为0.75.
第二种是如果oldCap大于0，也就是扩容过的话，每次table的容量和threshold都会扩围原来的两倍
第三种是如果指定了threshold的初始容量的话，newCap就会等于这个threshold，新的threshold会重新计算

这段源码可以进行拆分，
当这种情况时
扩容后的位置=原位置
而这样
则扩容后的位置 = 原位置 + 旧容量

一步步来看，源码的意思很明显只有e.hash & oldCap == 0和不等于0的情况
hash值的计算

是高16位与低16位的异或运算，作用大家也知道，都是为了使hash的分布更为离散。
再来看一下这一段

这很明显，要开始分情况了，第一种是e.next == null也就是无链表的情况下，第二种是树化的情况下（这里我也不太明白，就不乱说了），第三种是在有链表的情况下。
第一种比较简单，通过hash值和新的容量进行了一个与运算来确定下标，不再赘述。
这里着重说一下第三种，也就是有链的情况下

在有链的情况下， 会新建低位收尾节点和高位首尾节点，低位指的是低16位也就是0到oldCap - 1，高位16位指的的oldCap到newCap - 1,用于后面newTab的大小的计算
这里我们举个例子
原HashMap的key1索引：
0000000 00000000 00000000 00001111 //n-1=16-1=15
& 11111111 11111111 00001111 00000101 //hash1（key1）
-------------------------------------------
00000000 00000000 00000000 00000101 //索引为5

原HashMap的key2索引：
00000000 00000000 00000000 00001111 //n-1=16-1=15
& 11111111 11111111 00001111 00010101 //hash2（key2）
-------------------------------------------------
00000000 00000000 00000000 00000101 //索引为5

结果：key1和可以key2的索引都为5；
-------------------------------------------------------------------------------------

扩容后的HashMap的key1索引：
00000000 00000000 00000000 00011111 //n-1=32-1=31
& 11111111 11111111 00001111 00000101 //hash1（key1）
----------------------------------------------
00000000 00000000 00000000 00000101 //索引为5

原HashMap的key2索引：
00000000 00000000 00000000 00011111 //n-1=32-1=31
& 11111111 11111111 00001111 00010101 //hash2（key2）
-----------------------------------------------
00000000 00000000 00000000 00010101 //索引为5+16
结果：key1的索引为5；key2的索引为 16+5，即为原索引+旧容量

这样一来的话，很明显，当高位为0或者1的时候，索引的位置会发生相应的改变，如果高位是0，那么新的索引就是原来的索引，反之，则为原索引+旧容量，也就是hash值不一样的话，扩容前和扩容后的高位是可能不一样的

这里将链上的元素根据是否进行了分链的操作，保证了在扩容之后不会有更严重的hash冲突，均匀地把之前冲突的节点分布到新的桶中。与jdk1.7相比省去了重新计算hash的时间，也可以看成一个高效的改动了。