目錄
前言
對於HashMap，可謂是面試必問的點。無論你是剛畢業的大學生，還是工作三年的高級開發工程師。HashMap可謂是JDK源碼中比較經典的源碼設計。
在上學的時候就知道它的重要性，但是有一些比較複雜的地方當時很難理解，只是模糊記憶，面試官問的時候也是將記住的答案背下來，其實在面試官眼中早就露餡了。
簡單回顧
一些基礎的問題我們就簡單回顧一下就好。其中要講解的難點先標註，後文進行詳細剖析。
HashMap的內部數據結構
數組 + 鏈表/紅黑樹
HashMap允許空鍵空值麼
HashMap最多隻允許一個鍵爲Null(多條會覆蓋)，但允許多個值爲Null
影響HashMap性能的重要參數
初始容量：創建哈希表(數組)時桶的數量，默認爲 16
負載因子：哈希表在其容量自動增加之前可以達到多滿的一種尺度，默認爲 0.75
HashMap的工作原理
HashMap是基於hashing的原理，我們使用put(key, value)存儲對象到HashMap中，使用get(key)從HashMap中獲取對象
HashMap中put()的工作原理
HashMap 的底層數組長度爲何總是2的n次方
HashMap根據用戶傳入的初始化容量，利用無符號右移和按位或運算等方式計算出第一個大於該數的2的冪。
- `使數據分佈均勻，減少碰撞
- 當length爲2的n次方時，h&(length - 1) 就相當於對length取模，而且在速度、效率上比直接取模要快得多
1.8中做了哪些優化優化？
數組+鏈表改成了數組+鏈表或紅黑樹鏈表的插入方式從頭插法改成了尾插法擴容的時候1.7需要對原數組中的元素進行重新hash定位在新數組的位置，1.8採用更簡單的判斷邏輯，位置不變或索引+舊容量大小；- 在插入時，1.7先判斷是否需要擴容，再插入，1.8先進行插入，插入完成再判斷是否需要擴容；
HashMap線程安全方面會出現什麼問題
- 在jdk1.7中，在多線程環境下，擴容時會造成環形鏈或數據丟失。
- 在jdk1.8中，在多線程環境下，會發生數據覆蓋的情況
難點剖析
爲什麼HashMap的底層數組長度爲何總是2的n次方
這裏我覺得可以用逆向思維來解釋這個問題，我們計算桶的位置完全可以使用h % length，如果這個length是隨便設定值的話當然也可以，但是如果你對它進行研究，設計一個合理的值得話，那麼將對HashMap的性能發生翻天覆地的變化。
沒錯，JDK源碼作者就發現了，那就是當length爲2的N次方的時候，那麼，爲什麼這麼說呢？
第一：當length爲2的N次方的時候，h & (length-1) = h % length
爲什麼&效率更高呢？因爲位運算直接對內存數據進行操作，不需要轉成十進制，所以位運算要比取模運算的效率更高
第二：當length爲2的N次方的時候，數據分佈均勻，減少衝突
此時我們基於第一個原因進行分析，此時hash策略爲h & (length-1)。
我們來舉例當length爲奇數、偶數時的情況：
從上面的圖表中我們可以看到，當 length 爲15時總共發生了8次碰撞，同時發現空間浪費非常大，因爲在 1、3、5、7、9、11、13、15 這八處沒有存放數據。
這是因爲hash值在與14（即 1110）進行&運算時，得到的結果最後一位永遠都是0，那麼最後一位爲1的位置即 0001、0011、0101、0111、1001、1011、1101、1111位置處是不可能存儲數據的。這樣，空間的減少會導致碰撞機率的進一步增加，從而就會導致查詢速度慢。
而當length爲16時，length – 1 = 15， 即 1111，那麼，在進行低位&運算時，值總是與原來hash值相同，而進行高位運算時，其值等於其低位值。所以，當 length=2^n 時，不同的hash值發生碰撞的概率比較小，這樣就會使得數據在table數組中分佈較均勻，查詢速度也較快。
如果上面這句話大家還看不明白的話，可以多試一些數，就可以發現規律。當length爲奇數時，length-1爲偶數，而偶數二進制的最後一位永遠爲0，那麼與其進行 & 運算，得到的二進制數最後一位永遠爲0，那麼結果一定是偶數，那麼就會導致下標爲奇數的桶永遠不會放置數據，這就不符合我們均勻放置，減少衝突的要求了。
那麼可能鑽牛角尖的同學還會問，那length是偶數不就行了麼，爲什麼一定要是2的N次方，這不就又回到第一點原因了麼？JDK 的工程師把各種位運算運用到了極致，想盡各種辦法優化效率。
那麼爲什麼默認是16呢？怎麼不是4？不是8？
關於這個默認容量的選擇，JDK並沒有給出官方解釋，那麼這應該就是個經驗值，既然一定要設置一個默認的2^n 作爲初始值，那麼就需要在效率和內存使用上做一個權衡。這個值既不能太小，也不能太大。
太小了就有可能頻繁發生擴容，影響效率。太大了又浪費空間，不划算。
所以，16就作爲一個經驗值被採用了。
HashMap線程安全方面會出現什麼問題
1.put的時候導致的多線程數據不一致
比如有兩個線程A和B,首先A希望插入一個key-valu對到HashMap中,首先計算記錄所要落到的 hash桶的索引座標,然後獲取到該桶裏面的鏈表頭結點,此時線程A的時間片用完了,而此時線程B被調度得以執行,和線程A一樣執行,只不過線程B成功將記錄插到了桶裏面,假設線程A插入的記錄計算出來的 hash桶索引和線程B要插入的記錄計算出來的 hash桶索引是一樣的,那麼當線程B成功插入之後,線程A再次被調度運行時,它依然持有過期的鏈表頭但是它對此一無所知,以至於它認爲它應該這樣做,如此一來就覆蓋了線程B插入的記錄,這樣線程B插入的記錄就憑空消失了,造成了數據不一致的行爲。
2.resize而引起死循環
這種情況發生在HashMap自動擴容時,當2個線程同時檢測到元素個數超過 數組大小 ×負載因子。此時2個線程會在put()方法中調用了resize(),兩個線程同時修改一個鏈表結構會產生一個循環鏈表(JDK1.7中,會出現resize前後元素順序倒置的情況)。接下來再想通過get()獲取某一個元素,就會出現死循環。
如果還不明白的話看這兩篇文章就可以：
HashMap死循環
HashMap線程不安全的體現
爲什麼1.8改用紅黑樹
比如某些人通過找到你的hash碰撞值，來讓你的HashMap不斷地產生碰撞，那麼相同key位置的鏈表就會不斷增長，當你需要對這個HashMap的相應位置進行查詢的時候，就會去循環遍歷這個超級大的鏈表，性能及其地下。java8使用紅黑樹來替代超過8個節點數的鏈表後，查詢方式性能得到了很好的提升，從原來的是O(n)到O(logn)。
1.8中的擴容爲什麼邏輯判斷更簡單
元素在重新計算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不會倒置。
以上有部分內容爲個人理解，有誤請指正，謝謝