摘要：分析Map介面的詳細使用以及HashMap的底層是如何實現的？
本文分享自華為雲社群《【圖文並茂】深度解析HashMap高頻面試及底層實現結構！【奔跑吧！JAVA】》，原文作者：灰小猿 。
Map介面大家應該都聽說過吧？它是在Java中對鍵值對進行儲存的一種常用方式，同樣其中的HashMap我相信大家應該也不會陌生，一說到HashMap，我想稍微知道點的小夥伴應該都說是：這是儲存鍵值對的，儲存方式是陣列加連結串列的形式。但是其中真正是如何進行儲存以及它的底層架構是如何實現的，這些你有了解嗎？
可能很多小夥伴該說了，我只需要知道它怎麼使用就可以了，不需要知道它的底層實現，但其實恰恰相反，只知道它怎麼使用是完全不夠的，而且在Java開發的面試之中，HashMap底層實現的提問和考察已經是司空見慣的了。所以今天我就來和大家分析一下Map介面的詳細使用以及HashMap的底層是如何實現的？
小夥伴們慢慢往下看，看完絕對會讓你收穫滿滿的！
1，Map介面和List介面是什麼關係？
對於這個問題，如果非要說這兩個介面之間存在怎樣的關係的話，那無非就只有一個，就都是集合。存放資料的。在其他上面，Map介面和List介面的聯絡其實並不大，為什麼這麼說？
先來看List介面，關於List介面我在之前也和大家提到過，它是繼承於Collection介面的，是Collection介面的子介面，只是用於對資料的單列儲存。繼承關係如下圖：
而Map介面是一個頂層介面，下面包含了很多不同的實現類，它是用於對鍵值對（key:value）進行儲存的，繼承關係如下圖：
所以Map介面和List介面的關係和使用不要混淆了！
2、Map有哪些常用的實現類？
上面關於Map的繼承結構我們已經瞭解了，我們也看了其中很多不同的實現類，這些類很多也是我們比較熟悉的，比如HashMap、TreeMap以及HashTable。在面試的時候，面試官往往就還會問，Map介面下有哪些常用的實現類以及它們的作用，那麼接下來我們就來對這幾個介面進行簡單的介紹和分析一下，
HashMap:上面也說了，HashMap的底層實現是陣列+連結串列+紅黑樹的形式的，同時它的陣列的預設初始容量是16、擴容因子為0.75，每次採用2倍的擴容。也就是說，每當我們陣列中的儲存容量達到75%的時候，就需要對陣列容量進行2倍的擴容。
HashTable:HashTable介面是執行緒安全，但是很早之前有使用，現在幾乎屬於一個遺留類了，在開發中不建議使用。
ConcurrentHashMap:這是現階段使用使用比較多的一種執行緒安全的Map實現類。在1.7以前使用的是分段鎖機制實現的執行緒安全的。但是在1.8以後使用synchronized關鍵字實現的執行緒安全。
其中關於HashMap的考察和提問在面試中是最頻繁的，這也是在日常開發中最應該深入理解和掌握的。所以接下來就主要和大家詳細分析一下HashMap的實現原理以及面試中的常考問題。
3、請闡述HashMap的put過程？
我們知道HaahMap使用put的方式進行資料的儲存，其中有兩個引數，分別是key和value，那麼關於這個鍵值對是如何進行儲存的呢？我們接下來進行分析一下。
在HashMap中使用的是陣列+連結串列的實現方式，在HashMap的上層使用陣列的形式對“相同”的key進行儲存，下層對相應的key和value使用連結串列的形式進行連結和儲存。
注意：這裡所說的相同並不一定是key的數值相同，而是存在某種相同的特徵，具體是哪種特徵罵我們繼續往下看！
HashMap將將要儲存的值按照key計算其對應的陣列下標，如果對應的陣列下標的位置上是沒有元素的，那麼就將儲存的元素存放上去，但是如果該位置上已經存在元素了，那麼這就需要用到我們上面所說的連結串列儲存了，將資料按照連結串列的儲存順序依次向下儲存就可以了。這就是put的簡單過程，儲存結果如下：
但是我們有時候儲存的資料會很多，那麼如果一直使用連結串列的形式進行資料的儲存的話就或造成我們的連結串列的長度非常大，這樣無論在進行刪除還是在進行插入操作都是十分麻煩的，因此對於這種情況應該怎麼辦呢？
這裡就涉及到了一個連結串列中資料儲存時，進行“樹化”和“鏈化”的一個過程，那麼什麼是“樹化”和“鏈化”呢？
當我們在對鍵值對進行儲存的時候，如果我們在同一個陣列下標下儲存的資料過多的話，就會造成我們的連結串列長度過長，導致進行刪除和插入操作比較麻煩，所以在java中規定，當連結串列長度大於8時，我們會對連結串列進行“樹化”操作，將其轉換成一顆紅黑樹（一種二叉樹，左邊節點的值小於根節點，右邊節點的值大於根節點），這樣我們在對元素進行查詢時，就類似於進行二分查詢了，這樣的查詢效率就會大大增加。
但是當我們進行刪除操作，將其中的某些節點刪除了之後，連結串列的長度不再大於8了，這個時候怎麼辦？難道就要趕緊將紅黑樹轉化為連結串列的形式嗎？其實並不是，只有當連結串列的長度小於6的時候，我們才會將紅黑樹重新轉化為連結串列，這個過程就叫做“鏈化”。
過程圖示如下：
那麼為什麼要在長度8的時候進行“樹化”，而在長度小於6的時候才進行“鏈化”呢？為什麼不直接在長度小於8的時候就進行“鏈化”？
主要原因是因為：當刪除一個元素，連結串列長度小於8的時候直接進行“鏈化”，而再增加一個元素，長度又等於8的時候，又要進行“樹化”，這樣反覆的進行“鏈化”和“樹化”操作特別的消耗時間，而且也比較麻煩。所以程式就規定，只有噹噹連結串列長度大於等於8的時候才進行“樹化”，而長度小於6的時候才進行“鏈化”，其中關於8樹化、6鏈化這兩個閾值希望大家牢記！
4、連結串列中是按照怎樣的順序存放資料的？
我們現在已經知道了HashMap中的元素是如何存放的，但是有時候面試官可能還會問我們，在HashMap中，向連結串列中儲存元素是在頭結點儲存的還是在尾節點儲存的？
這個我們需要知道，對於HashMap中連結串列元素的儲存。
在JDK1.7以及前是在頭結點插入的，在JDK1.8之後是在尾節點插入的。
5、Hash(key)方法是如何實現的？
我們現在已經知道了HashMap中的元素是如何儲存的了，那麼現在就是如何應該根據key值進行相應的陣列下標的計算呢？
我們知道HashMap的初始容量是16位，那麼對於初始的16個資料位，如果將資料按照key的值進行計算儲存，一般最簡單的方法就是根據key值獲取到一個int值，方法是：
int hashCode = key.hashCode() 然後對獲取到的hashCode與16進行取餘運算， hashCode % 16 = 0~15
這樣得到的永遠都是0—15的下標。這也是最最原始的計算hash(key)的方法。
但是在實際情況下，這種方法計算的hash(key)並不是最優，存放到陣列中的元素並不是最分散的，而且在計算機中進行餘運算其實是非常不方便的、
所以為了計算結果儘可能的離散，現在計算陣列下標最常用的方法是：先根據key的值計算到一個hashCode，將hashCode的高18位二進位制和低18位二進位制進行異或運算，得到的結果再與當前陣列長度減一進行與運算。最終得到一個陣列下標，過程如下：
int hashCode = key.hashCode() int hash = hash(key) = key.hashCode()的高16位^低16位&(n-1) 其中n是當前陣列長度
同時在這裡要提醒一點：
在JDK1.7和JDK1.8的時候對hash(key)的計算是略有不同的
JDK1.8時，計算hash(key)進行了兩次擾動
JDK1.7時，計算hash(key)進行了九次擾動，分別是四次位運算和五次異或運算
其中擾動可能理解為運算次數
以上就是Hash(key)方法的實現過程。
6、為什麼HashMap的容量一直是2的倍數？
HashMap的容量之所以一直是2的倍數，其實是與上面所說的hash(key)演算法有關的。
原因是隻有參與hash(key)的演算法的（n-1）的值儘可能都是1的時候，得到的值才是離散的。假如我們當前的陣列長度是16，二進位制表示是10000，n-1之後是01111，使得n-1的值儘可能都是1，對於其他是2的倍數的值減1之後得到值也是這樣的。
所以只有當陣列的容量長度是2的倍數的時候，計算得到的hash(key)的值才有可能是相對離散的，
7、Hash衝突如何解決？
什麼是Hash衝突？就是當我計算到某一個陣列下標的時候，該下標上已經存放元素了，這就叫Hash衝突，很顯然，如果我們計算陣列下標的演算法不夠優秀的時候，很容易將儲存的資料積累到同一個下標上面，造成過多的Hash衝突。
那麼如何解決hash衝突？
最應該解決的其實就是讓儲存的key計算得到的陣列下標儘可能的離散，也就是要求hash(key)儘可能的優化，陣列長度是2的倍數。這也就是Hash衝突的主要解決方法。
具體可以檢視下面HashMap關鍵部分的底層原始碼：
Hash(key)的底層實現
/** * Applies a supplemental hash function to a given hashCode, which * defends against poor quality hash functions. This is critical * because HashMap uses power-of-two length hash tables, that * otherwise encounter collisions for hashCodes that do not differ * in lower bits. Note: Null keys always map to hash 0, thus index 0. */ static int hash(int h) { // 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); }
put(key,value)方法的底層實現
/** * Associates the specified value with the specified key in this map. * If the map previously contained a mapping for the key, the old * value is replaced. * * @param key key with which the specified value is to be associated * @param value value to be associated with the specified key * @return the previous value associated with <tt>key</tt>, or * <tt>null</tt> if there was no mapping for <tt>key</tt>. * (A <tt>null</tt> return can also indicate that the map * previously associated <tt>null</tt> with <tt>key</tt>.) */ public V put(K key, V value) { if (key == null) return putForNullKey(value); int hash = hash(key.hashCode()); int i = indexFor(hash, table.length); for (Entry<K,V> e = table[i]; e != null; e = e.next) { Object k; if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { V oldValue = e.value; e.value = value; e.recordAccess(this); return oldValue; } } modCount++; addEntry(hash, key, value, i); return null; }
8、HashMap是如何擴容的？
我們在上面說到了HashMap的陣列的初始容量是16，但是很顯然16個儲存位是顯然不夠的，那麼HashMap應該如何擴容呢？
在這裡需要用到一個引數叫“擴容因子”，在HashMap中“擴容因子”的大小是0.75，
我們上面也提到過，對於初始長度為16的陣列，當其中儲存的資料長度等於16*0.75=12時。就會對陣列元素進行擴容，擴容量是原來陣列容量的2倍，也就是當前是15話，再擴容就是擴容32個資料位。
9、擴容後元素怎麼存放的？
我們知道HashMap的陣列在進行擴容之後，陣列長度是增加的，那麼這個時候，後面新擴容的部分就是空的。但是這個時候我們就應該讓後面的資料位空著嗎？顯然是不可能的，這樣會造成記憶體的很大浪費。
因此在HashMap的陣列擴容之後，原先HashMap陣列中存放的資料元素會進行重新的位置分配，重新將元素在新陣列中進行儲存。以充分利用陣列空間。
10、JDK1.7和JDK1.8對HashMap的實現比較
在JDK1.7和JDK1.8中對HashMap的實現是略有不同的，最後我們根據上面的講解對JDK1.7和JDK1.8在HashMap的實現中的不同進行分析比較。
（1）、底層資料結構不同
在HashMap的put過程中，JDK1.7時是沒有紅黑樹這一概念的，直接是進行的連結串列儲存，在JDK1.8之後才引入了紅黑樹的概念，來優化儲存和查詢。
（2）、連結串列的插入方式不同
在HashMap向連結串列中插入元素的過程中，JDK1.7時是在表頭節點插入的，JDK1.8之後是在尾節點插入的。
（3）、Hash(key)的計算方式不同
在Hash(key)的計算中，JDK1.7進行了九次擾亂，分別是四次位運算和五次異或運算，JDK1.8之後只進行了兩次擾動。
（4）、擴容後數儲存位置的計算方式不同
在擴容後對儲存資料的重新排列上，JDK1.7是將所有資料的位置打亂，然後根據hash(key)進行重新的計算，而在JDK1.8之後是對原來的資料下標進行了兩次for迴圈。計算出新下標位置只能是在原下標位置或者在原下標位置加上原容量位置。
好了，關於Map介面和HashMap的底層實現的過程，以及在面試中參考的核心問題就和大家分析到這裡！