HashMap 底層實作原理是什麼？JDK8 做了哪些優化？

HashMap是使用頻率最高的類型之一，同時也是面試經常被問到的問題之一，這是因為 HashMap 的知識點有很多，同時它又屬于 Java 基礎知識的一部分，是以在面試中經常被問到。

本課時講的是，HashMap 底層是如何實作的？在 JDK 1.8 中它都做了哪些優化？

典型回答

在JDK1.7中HashMap是以數組加連結清單的形式組成的，JDK1.8之後新增了紅黑樹的組成結構，當連結清單大于8時，連結清單結構會轉換成紅黑樹結構，它的組成結構如下圖所示：

數組中的元素我們稱之為哈希桶，它的定義如下：

static class Node<K,V> implements Map.Entry<K,V> {
        final int hash;
        final K key;
        V value;
        Node<K,V> next;

        Node(int hash, K key, V value, Node<K,V> next) {
            this.hash = hash;
            this.key = key;
            this.value = value;
            this.next = next;
        }

        public final K getKey()        { return key; }
        public final V getValue()      { return value; }
        public final String toString() { return key + "=" + value; }

        public final int hashCode() {
            return Objects.hashCode(key) ^ Objects.hashCode(value);
        }

        public final V setValue(V newValue) {
            V oldValue = value;
            value = newValue;
            return oldValue;
        }

        public final boolean equals(Object o) {
            if (o == this)
                return true;
            if (o instanceof Map.Entry) {
                Map.Entry<?,?> e = (Map.Entry<?,?>)o;
                if (Objects.equals(key, e.getKey()) &&
                    Objects.equals(value, e.getValue()))
                    return true;
            }
            return false;
        }
    }           

可以看出每個哈希桶中包含了四個字段：hash、key、value、next，其中next 表示連結清單的下一個節點。

JDK 1.8之是以添加紅黑樹是因為一旦連結清單過長，會嚴重影響HashMap的性能，而紅黑樹具有快速增删改查的特點，這樣就可以有效的解決連結清單過長時操作比較慢的問題。

考點分析

上面大體介紹了 HashMap 的組成結構，但面試官想要知道的遠遠不止這些，和 HashMap 相關的面試題還有以下幾個：

• JDK 1.8 HashMap 擴容時做了哪些優化？
• 加載因子為什麼是 0.75？
• 當有哈希沖突時，HashMap 是如何查找并确認元素的？
• HashMap 源碼中有哪些重要的方法？
• HashMap 是如何導緻死循環的？

知識擴充

1.HashMap源碼分析

HashMap源碼中包含一下幾個屬性：

// HashMap初始化長度
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
// HashMap最大長度
static final int MAXIMUM_CAPACITY = 1 << 30; //1073741824
// 預設加載因子（擴容因子）
static final float DEFAULT_LOAD_FACTOR = 0.75f;
//轉換紅黑樹的臨界值，當連結清單長度大于此值時，會把連結清單結構轉換為紅黑樹結構
static final int TREEIFY_THRESHOLD = 8;
//轉換連結清單的臨界值，當元素小于此值時，會将紅黑樹結構轉換成連結清單結構
static final int UNTREEIFY_THRESHOLD = 6;
//最小樹容量
static final int MIN TREEIFY CAPACITY = 64;           

1.1.什麼時加載因子？為什麼加載因子時0.75？

加載因子也叫擴容因子或負載因子，用來判斷什麼時候進行擴容的，假如加載因子是0.5，HashMap的初始化容量是16，那麼當HashMap中有16*0.5=8個元素時，HashMap就會進行擴容。

那加載因子為什麼是0.75而不是0.5或者1.0呢？

這其實是出于容量和性能之間平衡的結果：

• 當加載因子設定比較大的時候，擴容的門檻就被提高了，擴容發生的頻率比較低，占用的空間會比較小，但此時發生Hash沖突的幾率就會提升，是以需要更複雜的資料結構來存儲元素，這樣對元素的操作時間就會增加，運作效率也會是以降低；
• 而當加載因子值比較小的時候，擴容的門檻會比較低，是以會占用更多的空間，此時元素的存儲就比較稀疏，發生哈希沖突的可能性就比較小，是以操作性能會比較高。

是以綜合了以上情況就取了一個 0.5 到 1.0 的平均數 0.75 作為加載因子。

1.2.HashMap源碼中三個重要方法：查詢、新增和資料擴容。

1.2.1.查詢

public V get(Object key) {
        Node<K,V> e;
    	// 對key進行哈希操作
        return (e = getNode(hash(key), key)) == null ? null : e.value;
    }
final Node<K,V> getNode(int hash, Object key) {
        Node<K,V>[] tab; Node<K,V> first, e; int n; K k;
    	// 非空判斷
        if ((tab = table) != null && (n = tab.length) > 0 &&
            (first = tab[(n - 1) & hash]) != null) {
            // 判斷第一個是否是要查詢的元素
            if (first.hash == hash && // always check first node
                ((k = first.key) == key || (key != null && key.equals(k))))
                return first;
            // 判斷下一個節點是否非空
            if ((e = first.next) != null) {
                // 如果第一節點時樹結構，則使用getTreeNode擷取相應的資料
                if (first instanceof TreeNode)
                    return ((TreeNode<K,V>)first).getTreeNode(hash, key);
                do {
                    // 非樹結構，循環判斷
                    // hash相等并且key相等，傳回此節點
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        return e;
                } while ((e = e.next) != null);
            }
        }
        return null;
    }           

從以上源碼可以看出，當哈希沖突時我們需要通過判斷 key 值是否相等，才能确認此元素是不是我們想要的元素。

1.2.2.新增

public V put(K key, V value) {
    	// 對key進行哈希操作
        return putVal(hash(key), key, value, false, true);
    }
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        Node<K,V>[] tab; Node<K,V> p; int n, i;
    	// 哈希表為空則建立表
        if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length;
    	// 根據 key 的哈希值計算出要插入的數組索引 i
        if ((p = tab[i = (n - 1) & hash]) == null)
            // 如果table[i]等于nul1，則直接插入
            tab[i] = newNode(hash, key, value, null);
        else {
            Node<K,V> e; K k;
            // 如果key已經存在了，直接覆寫 value
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            // 如果key不存在，判斷是否為紅黑樹
            else if (p instanceof TreeNode)
                // 紅黑樹直接插入鍵值對
                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
            else {
                // 為連結清單結構，循環準備插入
                for (int binCount = 0; ; ++binCount) {
                    // 下一個元素為空時
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        //連結清單長度大于8轉換為紅黑樹進行處理
                        if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                            treeifyBin(tab, hash);
                        break;
                    }
                    // key已經存在直接覆寫 value
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    p = e;
                }
            }
            if (e != null) { // existing mapping for key
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        ++modCount;
    	// 超過最大容量，擴容
        if (++size > threshold)
            resize();
        afterNodeInsertion(evict);
        return null;
    }           

新增方法的執行流程，如下圖所示：

1.2.3.擴容

final Node<K,V>[] resize() {
    	// 擴容前的數組
        Node<K,V>[] oldTab = table;
    	// 擴容前的數組的大小和門檻值
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;
    	//預定義新數組的大小和門檻值
        int newCap, newThr = 0;
        if (oldCap > 0) {
            //超過最大值就不再擴容了
            if (oldCap >= MAXIMUM_CAPACITY) {
                threshold = Integer.MAX_VALUE;
                return oldTab;
            }
            //擴大容量為目前容量的兩倍，但不能超過MAXIMUM_CAPACITY
            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                     oldCap >= DEFAULT_INITIAL_CAPACITY)
                newThr = oldThr << 1; // double threshold
        }
    	//目前數組沒有資料，使用初始化的值
        else if (oldThr > 0) // initial capacity was placed in threshold
            newCap = oldThr;
        else {               // zero initial threshold signifies using defaults
            //如果初始化的值為0，則使用預設的初始化容量
            newCap = DEFAULT_INITIAL_CAPACITY;
            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
        }
    	//如果新的容量等于0
        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
        table = newTab;
    	//原資料不為空，将原資料複制到新 table中
        if (oldTab != null) {
            //根據容量循環數組，複制非空元素到新 table
            for (int j = 0; j < oldCap; ++j) {
                Node<K,V> e;
                if ((e = oldTab[j]) != null) {
                    oldTab[j] = null;
                    //如果連結清單隻有一個，則進行直接指派
                    if (e.next == null)
                        newTab[e.hash & (newCap - 1)] = e;
                    else if (e instanceof TreeNode)
                        // 紅黑樹相關操作
                        ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                    else { // preserve order
                        //連結清單複制，JDK1.8擴容優化部分
                        Node<K,V> loHead = null, loTail = null;
                        Node<K,V> hiHead = null, hiTail = null;
                        Node<K,V> next;
                        do {
                            next = e.next;
                            // 原索引
                            if ((e.hash & oldCap) == 0) {
                                if (loTail == null)
                                    loHead = e;
                                else
                                    loTail.next = e;
                                loTail = e;
                            }
                            // 原索引 + oldCap
                            else {
                                if (hiTail == null)
                                    hiHead = e;
                                else
                                    hiTail.next = e;
                                hiTail = e;
                            }
                        } while ((e = next) != null);
                        // 将原索引放到哈希桶中
                        if (loTail != null) {
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        // 将 原索引+oldCap 放到哈希桶中
                        if (hiTail != null) {
                            hiTail.next = null;
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }           

從以上源碼可以看出，JDK1.8在擴容時并沒有像JDK1.7那樣，重新計算每個元素的哈希值，而是通過高位運算(e.hash&oldCap)來确定元素是否需要移動，比如key1的資訊如下：

• key1.hash = 10 0000 1010
• oldCap = 16 0001 0000

使用e.hash&oldCap得到的結果高一位為0，當結果為0時表示元素在擴容時位置不會發生任何變化，而key 2資訊如下：

• key2.hash = 10 0001 0001
• oldCap = 16 0001 0000

這時候得到的結果高一位為 1，當結果為 1 時，表示元素在擴容時位置發生了變化，新的下标位置等于原下标位置 + 原數組長度，如下圖所示：

其中紅色的虛線圖代表了擴容時元素移動的位置。

2.HashMap死循環分析

以JDK1.7為例，假設HashMap預設大小為2，原本HashMap中有一個元素key(5)，我們再使用兩個線程：t1添加元素key(3)，t2添加元素key(7)，當元素key(3)和key(7)都添加到HashMap中之後，線程t1在執行到Entry<K，V>next=e.next；時，交出了CPU的使用權，源碼如下：

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);
            }
            int i = indexFor(e.hash,newCapacity);
            e.next = newTable[i];
            newTable[i] = e;
            e = next;
        }
    }
}           

那麼此時線程t1中的e指向了key(3)，而next指向了key(7)；之後線程t2重新rehash之後連結清單的順序被反轉，連結清單的位置變成了key(5)→key(7)→ key(3)，其中 “→” 用來表示下一個元素。

當 t1 重新獲得執行權之後，先執行newTalbe[i] = e 把 key(3) 的 next 設定為 key(7)，而下次循環時查詢到 key(7) 的 next 元素為 key(3)，于是就形成了 key(3) 和 key(7) 的循環引用，是以就導緻了死循環的發生，如下圖所示：

當然發生死循環的原因是JDK1.7連結清單插入方式為首部倒序插入，這個問題在JDK1.8得到了改善，變成了尾部正序插入。

有人曾經把這個問題回報給了Sun公司，但Sun公司認為這不是一個問題，因為HashMap本身就是非線程安全的，如果要在多線程下，建議使用ConcurrentHashMap替代，但這個問題在面試中被問到的幾率依然很大，是以在這裡需要特别說明一下。

小結

本課時介紹了 HashMap 的底層資料結構，在 JDK 1.7 時 HashMap 是由數組和連結清單組成的，而 JDK 1.8 則新增了紅黑樹結構，當連結清單的長度大于 8 并且容量大于 64 時會轉換為紅黑樹存儲，以提升元素的操作性能。同時還介紹了 HashMap 的三個重要方法，查詢、添加和擴容，以及 JDK 1.7 resize() 在并發環境下導緻死循環的原因。