hashmap負載因子，與擴容機制有關；即若當前容器的容量，達到設定最大值，就需要要執行擴容操作。
舉個例子：當前的容器容量是16，負載因子是0.75；16*0.75=12，也就是說，當容量達到了12的時就會執行擴容操作。
作用很簡單，相當於是乙個擴容機制的閾值。當超過了這個閾值，就會觸發擴容機制。hashmap原始碼已經為我們預設指定了負載因子是0.75。
擷取部分原始碼，從這裡可以看出，系統預設的負載因子值就是0.75，而且我們還可以在構造方法中去指定。下面我們就正式來分析一下為什麼是預設的0.75。
在考慮hashmap時，首先要想到的是hashmap只是乙個資料結構，既然是資料結構最主要的就是節省時間和空間。負載因子的作用肯定也是節省時間和空間。為什麼節省呢？我們考慮兩種極端情況。
我們先看hashmap的底層資料結構
資料一開始是儲存在陣列裡，當發生了hash碰撞的時候，就是在這個資料節點上，生出乙個鍊錶，當鍊表長度達到一定長度的時候，就會把鍊錶轉化為紅黑樹。
當負載因子是1.0時，也就意味著，只有當陣列的8個值（這個圖表示了8個）全部填充了，才會發生擴容。這就帶來了很大的問題，因為hash衝突時避免不了的。
後果：當負載因子是1.0的時候，意味著會出現大量的hash的衝突，底層的紅黑樹變得異常複雜。對於查詢效率極其不利。這種情況就是犧牲了時間來保證空間的利用率。
因此一句話總結就是負載因子過大，雖然空間利用率上去了，但是時間效率降低了。
後果：負載因子是0.5的時候，這也就意味著，當陣列中的元素達到了一半就開始擴容，既然填充的元素少了，hash衝突也會減少，那麼底層的鍊錶長度或者是紅黑樹的高度就會降低。查詢效率就會增加。
但是，此時空間利用率就會大大的降低，原本儲存1m的資料，現在就意味著需要2m的空間。
總之，就是負載因子太小，雖然時間效率提公升了，但是空間利用率降低了。
經過前面的分析，基本上為什麼是0.75的答案也就出來了，這是時間和空間的權衡。當然這個答案不是我自己想出來的。答案就在原始碼上，我們可以看看：
意思就是說：負載因子是0.75的時，空間利用率比較高，而且避免了相當多的hash衝突，使得底層的鍊錶或者是紅黑樹的高度比較低，提公升了空間效率。
HashMap 負載因子
static final float default load factor 0.75f 大概意思就是說，在理想情況下,使用隨機雜湊碼,節點出現的頻率在hash桶中遵循泊松分布，同時給出了桶中元素個數和概率的對照表。從上面的表中可以看到當桶中元素到達8個的時候，概率已經變得非常小，也就是說用0.75...
HashMap的負載因子
下面是hashmap的乙個建構函式，兩個引數initialcapacity,loadfactor 這關係hashmap的迭代效能。constructs an empty hashmap with the specified initial capacity and load factor.param...
HashMap容量和負載因子
引自 hashmap底層資料結構是陣列 鍊錶，jdk1.8中還引入了紅黑樹，當鍊表長度超過8個時，會將鍊錶轉成紅黑樹，以提公升其查詢效能。那麼，給出乙個節點，hashmap是如何確定這個節點應該放在具體哪個位置呢？以jdk1.8為例 final v putval int hash,k key,v v...