HashMap原理的加載因子為什麼是0.75，歡迎大家一起讨論

關于加載因子為什麼是0.75，其實和初始容量16沒有多大關系，和hashmap的拉鍊，長度超過8變成紅黑樹的泊松分布也沒有關系。

0.75的數學依據

另外，我們可以通過一種數學思維來計算下這個值是多少合适。

我們假設一個bucket空和非空的機率為0.5，我們用s表示容量，n表示已添加元素個數。

用s表示添加的鍵的大小和n個鍵的數目。根據二項式定理，桶為空的機率為:

P(0) = C(n, 0) * (1/s)^0 * (1 - 1/s)^(n - 0)複制ErrorOK!
           

是以，如果桶中元素個數小于以下數值，則桶可能是空的：

log(2)/log(s/(s - 1))
           

當s趨于無窮大時，如果增加的鍵的數量使P(0) = 0.5，那麼n/s很快趨近于log(2):

log(2) ~ 0.693...
           

是以，合理值大概在0.7左右。

當然，這個數學計算方法，并不是在Java的官方文檔中展現的，我們也無從考察到底有沒有這層考慮，就像我們根本不知道魯迅寫文章時候怎麼想的一樣，隻能推測。這個推測來源于Stack Overflor（https://stackoverflow.com/questions/10901752/what-is-the-significance-of-load-factor-in-hashmap）

算法如下!

這個回答的釋義是： 一個bucket空和非空的機率為0.5，通過牛頓二項式等數學計算，得到這個loadfactor的值為ln2，約等于0.693. 同回答者所說，可能小于0.75 大于等于log（2）的factor都能提供更好的性能，0.75這個數說不定是 pulled out of a hat。

按照這樣算。p(0)為0.5，我覺得 這是一種 空間和妥協的政策。

作為一般規則，預設負載因子（0.75）在時間和空間成本上提供了很好的折衷。較高的值會降低空間開銷，但提高查找成本（展現在大多數的HashMap類的操作，包括get和put）