1.背景：

HashMap是Java程式設計師使用頻率最高的用於對映(鍵值對)處理的資料型別。隨著JDK（Java Developmet Kit）版本的更新，JDK1.8對HashMap底層的實現進行了優化，例如引入紅黑樹的資料結構和擴容的優化等。

Java為資料結構中的對映定義了一個介面java.util.Map，此介面主要有四個常用的實現類，分別是HashMap、Hashtable、LinkedHashMap和TreeMap，類繼承關係如下圖所示：

(1) HashMap：它根據鍵的hashCode值儲存資料，大多數情況下可以直接定位到它的值，因而具有很快的訪問速度，但遍歷順序卻是不確定的。 HashMap最多隻允許一條記錄的鍵為null，允許多條記錄的值為null。HashMap非執行緒安全，即任一時刻可以有多個執行緒同時寫HashMap，可能會導致資料的不一致。如果需要滿足執行緒安全，可以用 Collections的synchronizedMap方法使HashMap具有執行緒安全的能力，或者使用ConcurrentHashMap。

(2) Hashtable：Hashtable是遺留類，很多對映的常用功能與HashMap類似，不同的是它承自Dictionary類，並且是執行緒安全的，任一時間只有一個執行緒能寫Hashtable，併發性不如ConcurrentHashMap，因為ConcurrentHashMap引入了分段鎖。Hashtable不建議在新程式碼中使用，不需要執行緒安全的場合可以用HashMap替換，需要執行緒安全的場合可以用ConcurrentHashMap替換。

(3) LinkedHashMap：LinkedHashMap是HashMap的一個子類，儲存了記錄的插入順序，在用Iterator遍歷LinkedHashMap時，先得到的記錄肯定是先插入的，也可以在構造時帶引數，按照訪問次序排序。

(4) TreeMap：TreeMap實現SortedMap介面，能夠把它儲存的記錄根據鍵排序，預設是按鍵值的升序排序，也可以指定排序的比較器，當用Iterator遍歷TreeMap時，得到的記錄是排過序的。如果使用排序的對映，建議使用TreeMap。在使用TreeMap時，key必須實現Comparable介面或者在構造TreeMap傳入自定義的Comparator，否則會在執行時丟擲java.lang.ClassCastException型別的異常。

對於上述四種Map型別的類，要求對映中的key是不可變物件。不可變物件是該物件在建立後它的雜湊值不會被改變。如果物件的雜湊值發生變化，Map物件很可能就定位不到對映的位置了。

2.儲存結構：

從結構實現來講，HashMap是陣列+連結串列+紅黑樹（JDK1.8增加了紅黑樹部分）實現的，如下圖所示。

HashMap就是使用雜湊表來儲存的。雜湊表為解決衝突，可以採用開放地址法和鏈地址法等來解決問題，Java中HashMap採用了鏈地址法。鏈地址法，簡單來說，就是陣列加連結串列的結合。在每個陣列元素上都一個連結串列結構，當資料被Hash後，得到陣列下標，把資料放在對應下標元素的連結串列上。

3.分析HashMap的put方法

①.判斷鍵值對陣列table[i]是否為空或為null，否則執行resize()進行擴容；

②.根據鍵值key計算hash值得到插入的陣列索引i，如果table[i]==null，直接新建節點新增，轉向⑥，如果table[i]不為空，轉向③；

③.判斷table[i]的首個元素是否和key一樣，如果相同直接覆蓋value，否則轉向④，這裡的相同指的是hashCode以及equals；

④.判斷table[i] 是否為treeNode，即table[i] 是否是紅黑樹，如果是紅黑樹，則直接在樹中插入鍵值對，否則轉向⑤；

⑤.遍歷table[i]，判斷連結串列長度是否大於8，大於8的話把連結串列轉換為紅黑樹，在紅黑樹中執行插入操作，否則進行連結串列的插入操作；遍歷過程中若發現key已經存在直接覆蓋value即可；

⑥.插入成功後，判斷實際存在的鍵值對數量size是否超多了最大容量threshold，如果超過，進行擴容。

4.JDK1.8的優化：

經過觀測可以發現，我們使用的是2次冪的擴充套件(指長度擴為原來2倍)，所以，元素的位置要麼是在原位置，要麼是在原位置再移動2次冪的位置。看下圖可以明白這句話的意思，n為table的長度，圖（a）表示擴容前的key1和key2兩種key確定索引位置的示例，圖（b）表示擴容後key1和key2兩種key確定索引位置的示例，其中hash1是key1對應的雜湊與高位運算結果。

元素在重新計算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不會倒置。

3.執行緒安全性：

在多執行緒使用場景中，應該儘量避免使用執行緒不安全的HashMap，而使用執行緒安全的ConcurrentHashMap。

4.JDK1.8與JDK1.8之前的效能對比：

當一個連結串列太長的時候（連結串列長度大於8時），HashMap會動態的將它替換成一個紅黑樹，這話的話會將時間複雜度從O(n)降為O(logn)。

(1) 擴容是一個特別耗效能的操作，所以當程式設計師在使用HashMap的時候，估算map的大小，初始化的時候給一個大致的數值，避免map進行頻繁的擴容。

(2) 負載因子是可以修改的，也可以大於1，但是建議不要輕易修改，除非情況非常特殊。

(3) HashMap是執行緒不安全的，不要在併發的環境中同時操作HashMap，建議使用ConcurrentHashMap。

(4) JDK1.8引入紅黑樹大程度優化了HashMap的效能。