一.HashMap基本知識
1.哈希衝突的定義
如果兩個不同的元素，通過哈希函數得出的實際存儲地址相同怎麼辦？也就是說，當我們對某個元素進行哈希運算，得到一個存儲地址後，然後要進行插入的時候，發現該位置已經被其他元素佔用了，其實這就是所謂的哈希衝突，也叫哈希碰撞。由此可見哈希函數的設計至關重要，好的哈希函數會盡可能地保證 計算簡單和散列地址分佈均勻,但是我們需要清楚的是，數組是一塊連續的固定長度的內存空間，再好的哈希函數也不能保證得到的存儲地址絕對不發生衝突。那麼哈希衝突如何解決呢？哈希衝突的解決方案有多種:開放定址法（當發生衝突時，繼續尋找下一塊未被佔用的存儲地址，然後再放入元素即可），再散列函數法，鏈地址法，而 HashMap 即是採用了鏈地址法，也就是數組+鏈表的方式。
2.hashmap的實現原理
HashMap 的主幹是一個 Entry 數組。Entry 是 HashMap 的基本組成單元，每一個 Entry 包含一個 key-value 鍵值對。
HashMap的總體結構如下：
簡單來說，HashMap由數組+鏈表組成的，數組是HashMap的主體，鏈表則是主要爲了解決哈希衝突而存在的，如果定位到的數組位置不含鏈表（當前entry的next指向null）,那麼查找，添加等操作很快，僅需一次尋址即可；如果定位到的數組包含鏈表，對於添加操作，其時間複雜度爲O(n)，首先遍歷鏈表，存在即覆蓋，否則新增；對於查找操作來講，仍需遍歷鏈表，然後通過key對象的equals方法逐一比對查找。所以，性能考慮，HashMap中的鏈表出現越少，性能纔會越好。
3.HashMap有4個構造器，其他構造器如果用戶沒有傳入initialCapacity 和loadFactor這兩個參數，會使用默認值：initialCapacity默認爲16，loadFactory默認爲0.75
二.具體問題如下
1.HashMap的內部數據結構
數組 + 鏈表/紅黑樹
2.HashMap允許空鍵空值麼
HashMap最多隻允許一個鍵爲Null(多條會覆蓋)，但允許多個值爲Null
3.影響HashMap性能的重要參數
- 初始容量：創建哈希表時桶的數量（數組的大小），默認爲 16
- 負載因子：哈希表在其容量擴容之前可以達到一種尺度，默認爲 0.75
4.HashMap的工作原理
HashMap是基於hashing的原理，我們使用put(key, value)存儲對象到HashMap中，使用get(key)從HashMap中獲取對象
5.HashMap中put()的工作原理
6.HashMap 的底層數組長度爲何總是2的n次方
- 使數據分佈均勻，減少碰撞
- 當length爲2的n次方時，hash&(length - 1) 就相當於對length取模，而且在速度效率上比直接取模要快得多
具體解釋：
這裏我覺得可以用逆向思維來解釋這個問題，我們計算桶的位置完全可以使用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，那麼結果一定是偶數，那麼就會導致下標爲奇數的桶永遠不會放置數據，這就不符合我們均勻放置，減少衝突的要求了。
那麼爲什麼默認是16呢？怎麼不是4？不是8？
關於這個默認容量的選擇，JDK並沒有給出官方解釋，那麼這應該就是個經驗值，既然一定要設置一個默認的2^n 作爲初始值，那麼就需要在效率和內存使用上做一個權衡。這個值既不能太小，也不能太大。太小了就有可能頻繁發生擴容，影響效率。太大了又浪費空間，不划算。所以，16就作爲一個經驗值被採用了。
7. 1.8中做了哪些優化優化？
- 數組+鏈表 改成了 數組+鏈表或紅黑樹
- 鏈表的插入方式從頭插法改成了尾插法
- 擴容的時候1.7需要對原數組中的元素進行重新hash，定位在新數組中的位置，1.8採用更簡單的判斷邏輯，位置不變或索引+舊容量大小；
- 在插入時，1.7先判斷是否需要擴容，再插入，1.8先進行插入，插入完成再判斷是否需要擴容；
8.HashMap線程安全方面會出現什麼問題
- 在jdk1.7中，在多線程環境下，擴容時會造成環形鏈或數據丟失。
- 在jdk1.8中，在多線程環境下，會發生數據覆蓋的情況
9.HashMap線程安全方面會出現什麼問題
（1）put的時候導致的多線程數據不一致，產生錯誤情況
比如有兩個線程 A和 B,首先 A希望插入一個 key-valul 對到 HashMap 中,首先計算記錄所要落到的 hash 桶的索引座標,然後獲取到該桶裏面的鏈表頭結點,而此時剛好線程 A 的時間片用完了,此時線程 B 被調度得以執行,和線程 A一樣的執行過程 ,只不過線程 B 成功的將記錄插到了桶裏面（假設線程 A 插入的記錄計算出來的 hash 桶索引和線程 B 要插入的記錄計算出來的 hash 桶索引是一樣的）那麼當線程 B 成功插入之後, 線程 A 再次被調度運行時,它依然持有過期的鏈表頭但是它對此一無所知（頭插法）,以至於它認爲它應該繼續採用頭插法插入數據（它拿到的頭節點剛好是剛剛線程B插入的節點的下一個節點），如此一來就覆蓋了線程 B 插入的記錄,這樣線程 B 插入的記錄就憑空消失了,造成了數據不一致的行爲。
（2）resize引起死循環
這種情況發生在 HashMap 自動擴容時,當 2 個線程同時檢測到元素個數超過 數組大小 ×負載因子 的時候。此時 2 個線程會在 put() 方法中調用resize() ,那麼此時若兩個線程同時修改一個鏈表結構會產生一個循環鏈表，接下來再想通過get()獲取某一個元素,就會出現死循環。
10.爲什麼1.8改用紅黑樹
比如某些人惡意找到你的hash碰撞值，來讓你的HashMap不斷地產生碰撞，那麼相同 index 位置的鏈表就會不斷增長，當你需要對這個HashMap的相應位置進行查詢的時候，就會去循環遍歷這個超級大的鏈表，性能十分不好。java8 使用紅黑樹來替代超過 8個節點數 的鏈表後，查詢方式性能得到了很好的提升，從原來的是 O(n) 到 O(logn)。
原文來自：https://potato.blog.csdn.net/article/details/106835525 感覺總結的十分好，學到了不少東西。