HashMap實現原理

HashMap是常考點，而通常不問List的幾個實現類(偏簡單)。如下基於JDK1.8.0_102分析。

內部存儲

HashMap的內部存儲是一個數組（bucket），數組的元素Node實現了是Map.Entry接口(hash, key, value, next)，next非空時指向定位相同的另外一個Entry，如圖：

image.png

容量(capacity)和負載因子(loadFactor)

簡單的說，capacity就是bucket的大小，loadFactor就是bucket填滿程度的最大比例。當bucket中的entries的數目(而不是已佔用的位置數)大於capacity*loadFactor時就須要擴容，調整bucket的大小爲當前的2倍。同時，初始化容量的大小也是2的次冪（大於等於設定容量的最小次冪），則bucket的大小在擴容先後都將是2的次冪（很是重要，resize時能帶來極大便利）。

Tips:
默認的capacity爲16，loadFactor爲0.75，但若是須要優化的話，要考量具體的使用場景。

• 若是對迭代性能要求高，不要把capacity設置過大，也不要把loadFactor設置太小，不然會致使bucket中的空位置過多，浪費性能
• 若是對隨機訪問的性能要求很高的話，不要把loadFactor設置的過大，不然會致使訪問時頻繁碰撞，時間複雜度向O(n)退化
• 若是數據增加很快的話，或數據規模可預知，能夠在建立HashMap時主動設置capacity

hash與定位

做爲API的設計者，不能假定用戶實現了良好的hashCode方法，因此一般會對hashCode再計算一次hash：

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

hashCode方法

注意key.hashCode()的多態用法。重點是hash方法。

hash方法的實現和定位

前面已經說過，在get和put計算下標時，先對hashCode進行hash操做，而後再經過hash值進一步計算下標，以下圖所示：

image.png

回顧hash方法的源碼可知，hash方法大概的做用就是：高16bit不變，低16bit和高16bit作了一個異或。

javadoc這樣說：

Computes key.hashCode() and spreads (XORs) higher bits of hash to lower. Because the table uses power-of-two masking, sets of hashes that vary only in bits above the current mask will always collide. (Among known examples are sets of Float keys holding consecutive whole numbers in small tables.) So we apply a transform that spreads the impact of higher bits downward. There is a tradeoff between speed, utility, and quality of bit-spreading. Because many common sets of hashes are already reasonably distributed (so don’t benefit from spreading), and because we use trees to handle large sets of collisions in bins, we just XOR some shifted bits in the cheapest possible way to reduce systematic lossage, as well as to incorporate impact of the highest bits that would otherwise never be used in index calculations because of table bounds.

在設計hash函數時，由於目前的table長度n爲2的次冪，因此計算下標的時候，可以使用按位與&代替取模%：

(n - 1) & hash複製代碼

設計者認爲這方法很容易發生碰撞。爲何這麼說呢？不妨思考一下，在n - 1爲15(0x1111)時，散列真正生效的只是低4bit的有效位，固然容易碰撞了。

所以，設計者想了一個顧全大局的方法(綜合考慮了速度、做用、質量)，就是把高16bit和低16bit異或了一下。設計者還解釋到由於如今大多數的hashCode的分佈已經很不錯了，就算是發生了碰撞也用O(logn)的tree去作了。僅僅異或一下，既減小了系統的開銷，也不會形成由於高位沒有參與下標的計算(table長度比較小)時，引發的碰撞。

但我沒有理解爲何「很」容易發生碰撞。如此設計的話，hash的分佈是均勻的，且極其簡單；將高16bit與低16bit異或以後，hash的分佈變的複雜一些，更「接近」隨機，但仍然是均勻的。估計做者是從實際使用的角度出發，由於通常狀況下，key的分佈也符合「局部性原理」，低比特位相同的機率大於異或後仍然相同的機率，從而下降了碰撞的機率。

碰撞

調用put方法時，儘管咱們設法避免碰撞以提升HashMap的性能，仍是可能發生碰撞。聽說碰撞率還挺高，平均加載率到10%時就會開始碰撞。咱們使用開放散列法來處理碰撞節點。

將舊entry的引用賦值給新entry的next屬性，改將新entry放在該位置——即在該位置上存儲一個鏈表，衝突節點從鏈表頭部插入，這樣插入新entry時不須要遍歷鏈表，時間複雜度爲O(1)。但若是鏈表過長，查詢性能仍將退化到O(n)。Java8中對鏈表長度增長了一個閾值，超過閾值鏈表將轉化爲紅黑樹，查詢時間複雜度降爲O(logn)，提升了鏈表過長時的性能。

勘誤：網上有朋友聯繫我指出了此處的錯誤，Java8中，發生碰撞時會遍歷到鏈表的最後。

這篇文章寫的時候讀源碼能力比較渣，就基於本身早期對Java7源碼的分析改編，本覺得除了紅黑樹部分，大致相同，就直接copy了過來，致使了這個錯誤——固然，如今想來，關於Java7中HashMap的分析也是錯的，最後插入方式沒錯，可是插入前仍是要O(n)的時間遍歷一遍。不過其餘涉及源碼的文章就都是老老實實追源碼寫出來的，能夠放心閱讀。告誡本身，要堅持踏實，堅持懷疑。如下是改正的分析。

從該位置上的entry開始，遍歷到找到相同的key（就替換），或到結尾仍是沒有相同的key（就銜接在尾節點的next上）。查詢時過程相同。不考慮任何優化，插入、查詢的性能都是O(n)。Java8中對鏈表長度增長了一個閾值，超過閾值鏈表將轉化爲紅黑樹，插入、查詢的時間複雜度降爲O(logn)，提升了鏈表過長時的性能。

調用get方法時，定位到該位置，再遍歷紅黑樹，比較key值找到所需元素：

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) {
                if (first instanceof TreeNode)
                    return ((TreeNode<K,V>)first).getTreeNode(hash, key);
                do {
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        return e;
                } while ((e = e.next) != null);
            }
        }
        return null;
    }複製代碼

判斷元素相等的設計比較經典，利用了bool表達式的短路特性：先比較hash值；若是hash值相等，就經過==比較；若是==不等，再經過equals方法比較。hash是提早計算好的；若是沒有重載運算符（一般也不建議這樣作），==通常直接比較引用值；equals方法最有可能耗費性能，如String的equals方法須要O(n)的時間，n是字符串長度。必定要記住這裏的判斷順序，很能考察對碰撞處理源碼的理解。

針對HashMap的使用，此處要注意覆寫hashCode和equals方法時的兩個重點：

• 覆寫後，必定要保證equals判斷相等的時候，hashCode的返回值也相等。
• 對於選做key的類，要保證調用put與get時hashCode的返回值相等，equals的性質相同。

resize

resize是HashMap中最難理解的部分。

調用put方法時，若是發現目前的bucket佔用程度已經超過了loadFactor，就會發生resize。簡單的說就是把bucket擴充爲2倍，以後從新計算index，把節點再放到新的bucket中。

javadoc中這樣說：

Initializes or doubles table size. If null, allocates in accord with initial capacity target held in field threshold. Otherwise, because we are using power-of-two expansion, the elements from each bin must either stay at same index, or move with a power of two offset in the new table.

即，當超過限制的時候會resize，又由於咱們使用的是2次冪的擴展，因此，元素的位置要麼是在原位置，要麼是在原位置再移動2次冪的位置。

怎麼理解呢？例如咱們從16擴展爲32時，具體的變化以下：

image.png

假設bucket大小n=2^k，元素在從新計算hash以後，由於n變爲2倍,那麼新的位置就是(2^(k+1)-1)&hash。而2^(k+1)-1=2^k+2^k-1，至關於2^k-1的mask範圍在高位多1bit(紅色)(再次提醒，原來的長度n也是2的次冪)，這1bit非1即0。如圖：

image.png

因此，咱們在resize的時候，不須要從新定位，只須要看看原來的hash值新增的那個bit是1仍是0就行了，是0的話位置沒變，是1的話位置變成「原位置+oldCap」。代碼比較長就不貼了，下面爲16擴充爲32的resize示意圖：

image.png

這個設計很是的巧妙，新增的1bit是0仍是1能夠認爲是隨機的，所以resize的過程均勻的把以前的衝突的節點分散到新的bucket中了。

---

參考：

• Java HashMap工做原理及實現 | Yikun

---

本文連接：HashMap實現原理
做者：猴子007
出處：monkeysayhi.github.io
本文基於 知識共享署名-相同方式共享 4.0 國際許可協議發佈，歡迎轉載，演繹或用於商業目的，可是必須保留本文的署名及連接。