HashMap容量和負載因子使用說明
HashMap底層資料結構是陣列+連結串列，JDK1.8中還引入了紅黑樹，當連結串列長度超過8個時，會將連結串列轉成紅黑樹，以提升其查詢效能。
那麼，給出一個<key,value>節點，HashMap是如何確定這個節點應該放在具體哪個位置呢？（以JDK1.8為例）
final V putVal(int hash,K key,V value,boolean onlyIfAbsent,boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n,i;
// HashMap沒有被初始化，則先進行初始化
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
// 節點所在index = (n - 1) & hash，該位置沒有資料，則直接將新節點放在陣列的index位置上
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash,key,value,null);
else { // index上已經有節點了
Node<K,V> e; K k;
// 如果新key與原來的key一樣，則e指向原節點p（後面會用新value替換e所指向的value）
if (p.hash == hash &&
((k = p.key) == key || (key != null && key.equals(k))))
e = p;
// 如果該節點是樹節點，則採用樹的插入演算法，插入新節點
else if (p instanceof HashMap.TreeNode)
e = ((TreeNode<K,V>)p).putTreeVal(this,tab,hash,value);
else { // 該節點是連結串列節點
for (int binCount = 0; ; ++binCount) {
// 將新節點插入到index所在連結串列的末端
if ((e = p.next) == null) {
p.next = newNode(hash,null);
// 連結串列節點超過8個，則進行連結串列轉樹處理
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab,hash);
break;
}
// 同樣的，如果key已經存在的話，則不進行插入操作，而是後面進行value替換
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
}
// e != null的情況，就是key已經存在了，這裡統一進行了新值value，替換舊值e.value的操作
if (e != null) { // existing mapping for key
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)
e.value = value;
afterNodeAccess(e);
return oldValue;
}
}
++modCount;
// 插入後陣列size 大於閾值的話，需要進行擴容
if (++size > threshold)
resize();
afterNodeInsertion(evict);
return null;
}看原始碼，節點落在陣列中的index = （陣列長度 - 1） & key的hashcode，如果該index上沒有資料，則直接插到該index上，如果節點已經有資料了，則把新節點插入該index對應的連結串列中（如果連結串列節點大於8個，會進行連結串列轉樹，之後的插入演算法就變成了樹的插入演算法）。
每次put之後，會檢測一下是否需要擴容，size超過了 總容量 * 負載因子，則會擴容。預設情況下，16 * 0.75 = 12個。
1、為什麼初始容量是16
當容量為2的冪時，上述n -1 對應的二進位制數全為1，這樣才能保證它和key的hashcode做&運算後，能夠均勻分佈，這樣才能減少hash碰撞的次數。至於預設值為什麼是16，而不是2 、4、8，或者32、64、1024等，我想應該就是個折中處理，過小會導致放不下幾個元素，就要進行擴容了，而擴容是一個很消耗效能的操作。取值過大的話，無疑會浪費更多的記憶體空間。因此在日常開發中，如果可以預估HashMap會存入節點的數量，則應該在初始化時，指定其容量。
2、為什麼負載因子是0.75
也是一個綜合考慮，如果設定過小，HashMap每put少量的資料，都要進行一次擴容，而擴容操作會消耗大量的效能。如果設定過大的話，如果設成1，容量還是16，假設現在陣列上已經佔用的15個，再要put資料進來，計算陣列index時，發生hash碰撞的概率將達到15/16，這違背的HashMap減少hash碰撞的原則。
補充知識：HashMap只有容量達到閥值才發生擴容嗎？大錯特錯！
看了網上很多文章，說HashMap在元素達到負載因子對應數的時候就發生擴容。如果你看過原始碼就會發現，其實還有一種情況也可能會發生擴容：樹形化的時候。
物件最終是如何放入HashMap中的?
HashMap底層是由陣列+連結串列組成的，為了方便不懂的人更容易理解，那我們就先假設HashMap底層就是陣列，先不管連結串列。
當一個物件add到HashMap中，此時HashMap的add方法是如何來確定這個物件是放在陣列中的哪個位置的呢？
拿JDK1.8來說（其他JDK版本稍有不同，但大同小異）,大家應該知道每一個物件天生都繼承了或程式設計師自己覆蓋了Object類的 hashCode（）方法，此方法返回物件的hashcode值。
HashMap會有一個方法，先拿到要add進HashMap中的物件的hashCode，再將這個hashCode異或上物件自身hashCode右移16位（是不是感覺說的不是人話？這個步驟叫擾亂，這樣做的目的是為了讓hashCode每一位都儘可能用到，如果不理解沒關係並不影響接下來的閱讀），hashCode經過上述步驟之後再&（陣列長度-1），計算的結果就是這個物件在陣列中的位置了。我自己都覺得說的不是人話，下面舉個例子，便於理解：
這裡有一個Student物件的hashCode是：a
先把這個a右移16位 ， b=a>>>16;
然後a=a&b;
陣列中的位置等於: a&(陣列長度-1)；
上述原始碼如下：
h=key.hashCode();
h = key.hashCode()) ^ (h >>> 16）
陣列位置=h&(陣列長度-1)；
好了， 我們已經知道元素是如何在hashMap中的陣列上如何定位了，現在假設一個極端情況（不可能發生，但是我用這個舉例子）:
假設陣列長度為1，根據原始碼：
陣列位置=h&（陣列長度-1）
那麼有：
陣列位置=h&（1-1）=0 ，無論什麼物件，都定位到陣列的第0個位置。
這個很好理解吧。無論元素是否一樣，由於陣列長度為1，所以元素通通定位到陣列中第0個位置。大家都知道一個數組只能放一個元素啊？那怎麼辦呢？我們用連結串列來解決這個問題，把定位到這個位置的元素通過連結串列連線。這就是我一開始說的：hashMap是陣列+連結串列。
那樹形化又是什麼東東呢？
想一下我們為什麼要用HashMap，是因為通過Hash演算法在理想情況下時間複雜度O(1)就能找到元素，特別快，但是我都說了是理想情況，如果遇到上述發生hash碰撞（誰jb取的名字，就是上面我才說的，兩個元素定位到陣列中同一個位置），且hash碰撞比較頻繁的話，那麼當我們get一個元素的時候，定位到了這個陣列，還需要在陣列中遍歷一次連結串列最終才能找到要get的元素，是不是已經失去一部分使用HashMap的初心了？（因為需要遍歷連結串列，所以時間複雜度就比之前高了）
所以JDK1.8使用紅黑樹這種資料結構來解決連結串列過長的問題（可以簡單理解為用紅黑樹遍歷比連結串列遍歷速度快，時間複雜度低，不懂紅黑樹的可以去搜搜看），預設連結串列長度達到8就將連結串列樹形化（變為紅黑樹）。
回到最最開始我提到的，那為什麼樹形化的時候可能會發生擴容呢？
想想剛剛的例子陣列長度為1，所有元素全部在陣列的第0個位置形成一條連結串列，這例子是一種極端情況，陣列長度過小，那自然就會經常發生hash碰撞，那形成長連結串列是肯定的，這個時候樹形化其實是治標不治本，因為引起連結串列過長的根本原因是陣列過短，所以在JDK1.8原始碼中，執行樹形化之前，會先檢查陣列長度，如果長度小於64，則對陣列進行擴容，而不是進行樹形化。
所以發生擴容的時候有兩種情況，一種是元素達到閥值了，一種是HashMap準備樹形化但又發現數組太短，這兩種情況均可能發生擴容。
以上這篇HashMap容量和負載因子使用說明就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支援我們。