1.hashMap和hashTable的區別，為什么hashMap是線程不安全的？https://blog.csdn.net/qq_51250453/article/details/122285969
2、hashTable的沖突解決方式
3、hashTable的容量為什么都是2的冪次方
4、hashTable的rehash過程（在擴縮容時會觸發rehash）
5、數組查詢快，鏈表增刪快，結合倆者優點，hashTable應用而生
6、hashTable的擴容過程
7、什么情況下會觸發擴容https://blog.csdn.net/gupaoedu_tom/article/details/126384294
8、為什么hashmap是不安全的
9、hashtable的缺點已經hashmap出現死循環 https://blog.csdn.net/qq_37141773/article/details/85112743
10、rehash過程非常耗時，有什么優化方案？
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次方
HashMap根據用戶傳入的初始化容量，利用無符號右移和按位或運算等方式計算出第一個大于該數的2的冪。
- `使數據分布均勻，減少碰撞
- 當length為2的n次方時，h&(length - 1) 就相當于對length取模，而且在速度、效率上比直接取模要快得多
1.8中做了哪些優化優化？
數組+鏈表改成了數組+鏈表或紅黑樹鏈表的插入方式從頭插法改成了尾插法擴容的時候1.7需要對原數組中的元素進行重新hash定位在新數組的位置，1.8采用更簡單的判斷邏輯，位置不變或索引+舊容量大小；- 在插入時，1.7先判斷是否需要擴容，再插入，1.8先進行插入，插入完成再判斷是否需要擴容；
7.HashMap線程安全方面會出現什么問題
- 在jdk1.7中，在多線程環境下，擴容時會造成環形鏈或數據丟失。
- 在jdk1.8中，在多線程環境下，會發生數據覆蓋的情況
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 的工程師把各種位運算運用到了極致，想盡各種辦法優化效率。
9. 那么為什么默認是16呢？怎么不是4？不是8？
關于這個默認容量的選擇，JDK并沒有給出官方解釋，那么這應該就是個經驗值，既然一定要設置一個默認的2^n 作為初始值，那么就需要在效率和內存使用上做一個權衡。這個值既不能太小，也不能太大。
太小了就有可能頻繁發生擴容，影響效率。太大了又浪費空間，不劃算。
所以，16就作為一個經驗值被采用了。
10. 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()獲取某一個元素,就會出現死循環。
如果還不明白的話看這兩篇文章就可以：
- <u>HashMap死循環</u>
- <u>HashMap線程不安全的體現</u>
11. 為什么1.8改用紅黑樹
比如某些人通過找到你的hash碰撞值，來讓你的HashMap不斷地產生碰撞，那么相同key位置的鏈表就會不斷增長，當你需要對這個HashMap的相應位置進行查詢的時候，就會去循環遍歷這個超級大的鏈表，性能及其地下。java8使用紅黑樹來替代超過8個節點數的鏈表后，查詢方式性能得到了很好的提升，從原來的是O(n)到O(logn)。
12. 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不會倒置。
rehash時候非常耗時，有什么優化方案
我舉一個極端的例子，如果散列表當前大小為 1GB，要想擴容為原來的兩倍大小，那就需要對 1GB 的數據重新計算哈希值，并且從原來的散列表搬移到新的散列表，聽起來就很耗時，是不是？
如果我們的業務代碼直接服務于用戶，盡管大部分情況下，插入一個數據的操作都很快，但是，極個別非常慢的插入操作，也會讓用戶崩潰。這個時候，“一次性”擴容的機制就不合適了。為了解決一次性擴容耗時過多的情況，我們可以將擴容操作穿插在插入操作的過程中，分批完成。當裝載因子觸達閾值之后，我們只申請新空間，但并不將老的數據搬移到新散列表中。當有新數據要插入時，我們將新數據插入新散列表中，并且從老的散列表中拿出一個數據放入到新散列表。每次插入一個數據到散列表，我們都重復上面的過程。經過多次插入操作之后，老的散列表中的數據就一點一點全部搬移到新散列表中了。這樣沒有了集中的一次性數據搬移，插入操作就都變得很快了。
