HashMap的負載因子=0.75的時候，既能提升空間利用率，又能避免很多Hash衝突你居然不知道？

前言

以前寫過一篇專門介紹HashMap的文章，反響很不錯，不過在留言區問的最多的問題就是HashMap的負載因子初始值爲何是0.75，私下又好好地研究了一番，總結了這篇文章。

本篇文章基於JDK1.8，特在此說明。

OK。下面咱們就開始進行分析。

學習以前，童鞋們也能夠了解一些併發編程相關的知識。

1、負載因子的做用

對於HashMap的研究，我以前一直停留在考慮源碼是如何實現的，如今當我從新再來看的時候，才發現，系統默認的各類參數值，纔是HashMap的精華所在。

負載因子是和擴容機制有關的，意思是若是當前容器的容量，達到了咱們設定的最大值，就要開始執行擴容操做。舉個例子來解釋，避免小白聽不懂：

好比說當前的容器容量是16，負載因子是0.75,16*0.75=12，也就是說，當容量達到了12的時候就會進行擴容操做。

他的做用很簡單，至關因而一個擴容機制的閾值。當超過了這個閾值，就會觸發擴容機制。HashMap源碼已經爲咱們默認指定了負載因子是0.75。

我截取了部分源碼，從這裏能夠看出，系統默認的負載因子值就是0.75，並且咱們還能夠在構造方法中去指定。下面咱們就正式來分析一下爲何是默認的0.75。

2、緣由解釋（重點）

咱們在考慮HashMap的時候，首先要想到的是HashMap只是一個數據結構，既然是數據結構最主要的就是節省時間和空間。負載因子的做用確定也是節省時間和空間。爲何節省呢？咱們考慮兩種極端狀況。

一、負載因子是1.0

咱們先看HashMap的底層數據結構

咱們的數據一開始是保存在數組裏面的，當發生了Hash碰撞的時候，就是在這個數據節點上，生出一個鏈表，當鏈表長度達到必定長度的時候，就會把鏈表轉化爲紅黑樹。

當負載因子是1.0的時候，也就意味着，只有當數組的8個值（這個圖表示了8個）所有填充了，纔會發生擴容。這就帶來了很大的問題，由於Hash衝突時避免不了的。當負載因子是1.0的時候，意味着會出現大量的Hash的衝突，底層的紅黑樹變得異常複雜。對於查詢效率極其不利。這種狀況就是犧牲了時間來保證空間的利用率。

所以一句話總結就是負載因子過大，雖然空間利用率上去了，可是時間效率下降了。

二、負載因子是0.5

負載因子是0.5的時候，這也就意味着，當數組中的元素達到了一半就開始擴容，既然填充的元素少了，Hash衝突也會減小，那麼底層的鏈表長度或者是紅黑樹的高度就會下降。查詢效率就會增長。

可是，兄弟們，這時候空間利用率就會大大的下降，本來存儲1M的數據，如今就意味着須要2M的空間。

一句話總結就是負載因子過小，雖然時間效率提高了，可是空間利用率下降了。

三、負載因子0.75

通過前面的分析，基本上爲何是0.75的答案也就出來了，這是時間和空間的權衡。固然這個答案不是我本身想出來的。答案就在源碼上，咱們能夠看看：

大體意思就是說負載因子是0.75的時候，空間利用率比較高，並且避免了至關多的Hash衝突，使得底層的鏈表或者是紅黑樹的高度比較低，提高了空間效率。