之前寫過一篇專門介紹HashMap的文章街佑，反響很不錯厅篓，不過在留言區(qū)問的最多的問題就是HashMap的負載因子初始值為什么是0.75该贾，私下又好好地研究了一番琼梆，總結(jié)了這篇文章性誉。
本篇文章基于JDK1.8，特在此說明茎杂。
OK错览。下面我們就開始進行分析。
一煌往、負載因子的作用
對于HashMap的研究倾哺，我之前一直停留在考慮源碼是如何實現(xiàn)的，現(xiàn)在當我重新再來看的時候刽脖，才發(fā)現(xiàn)羞海，系統(tǒng)默認的各種參數(shù)值，才是HashMap的精華所在曲管。
負載因子是和擴容機制有關(guān)的却邓，意思是如果當前容器的容量，達到了我們設定的最大值院水，就要開始執(zhí)行擴容操作腊徙。舉個例子來解釋，避免小白聽不懂：
比如說當前的容器容量是16檬某，負載因子是0.75,16*0.75=12撬腾，也就是說，當容量達到了12的時候就會進行擴容操作恢恼。
他的作用很簡單民傻，相當于是一個擴容機制的閾值。當超過了這個閾值场斑，就會觸發(fā)擴容機制漓踢。HashMap源碼已經(jīng)為我們默認指定了負載因子是0.75。
public class HashMap<K,V> extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable {
//略
static final float DEFAULT_LOAD_FACTOR = 0.75f;
//略
public HashMap(int initialCapacity, float loadFactor) {
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);
this.loadFactor = loadFactor;
this.threshold = tableSizeFor(initialCapacity);
}
//略
}
我截取了部分源碼和簸，從這里可以看出彭雾，系統(tǒng)默認的負載因子值就是0.75，而且我們還可以在構(gòu)造方法中去指定锁保。下面我們就正式來分析一下為什么是默認的0.75。
二、原因解釋（重點）
我們在考慮HashMap的時候爽柒，首先要想到的是HashMap只是一個數(shù)據(jù)結(jié)構(gòu)吴菠，既然是數(shù)據(jù)結(jié)構(gòu)最主要的就是節(jié)省時間和空間。負載因子的作用肯定也是節(jié)省時間和空間浩村。為什么節(jié)省呢做葵？我們考慮兩種極端情況。
1心墅、負載因子是1.0
我們先看HashMap的底層數(shù)據(jù)結(jié)構(gòu)
我們的數(shù)據(jù)一開始是保存在數(shù)組里面的酿矢，當發(fā)生了Hash碰撞的時候，就是在這個數(shù)據(jù)節(jié)點上怎燥，生出一個鏈表瘫筐，當鏈表長度達到一定長度的時候，就會把鏈表轉(zhuǎn)化為紅黑樹铐姚。
當負載因子是1.0的時候策肝，也就意味著，只有當數(shù)組的8個值（這個圖表示了8個）全部填充了隐绵，才會發(fā)生擴容之众。這就帶來了很大的問題，因為Hash沖突時避免不了的依许。當負載因子是1.0的時候棺禾，意味著會出現(xiàn)大量的Hash的沖突，底層的紅黑樹變得異常復雜峭跳。對于查詢效率極其不利膘婶。這種情況就是犧牲了時間來保證空間的利用率。
因此一句話總結(jié)就是負載因子過大坦康，雖然空間利用率上去了竣付，但是時間效率降低了。
2滞欠、負載因子是0.5
負載因子是0.5的時候古胆，這也就意味著，當數(shù)組中的元素達到了一半就開始擴容筛璧，既然填充的元素少了逸绎，Hash沖突也會減少，那么底層的鏈表長度或者是紅黑樹的高度就會降低夭谤。查詢效率就會增加棺牧。
但是，兄弟們朗儒，這時候空間利用率就會大大的降低颊乘，原本存儲1M的數(shù)據(jù)参淹，現(xiàn)在就意味著需要2M的空間。
一句話總結(jié)就是負載因子太小乏悄，雖然時間效率提升了浙值，但是空間利用率降低了。
3檩小、負載因子0.75
經(jīng)過前面的分析开呐，基本上為什么是0.75的答案也就出來了，這是時間和空間的權(quán)衡规求。當然這個答案不是我自己想出來的筐付。答案就在源碼上，我們可以看看：
/* <p>As a general rule, the default load factor (.75) offers a good
- tradeoff between time and space costs. Higher values decrease the
- space overhead but increase the lookup cost (reflected in most of
- the operations of the <tt>HashMap</tt> class, including
- <tt>get</tt> and <tt>put</tt>). The expected number of entries in
- the map and its load factor should be taken into account when
- setting its initial capacity, so as to minimize the number of
- rehash operations. If the initial capacity is greater than the
- maximum number of entries divided by the load factor, no rehash
- operations will ever occur.*/
大致意思就是說負載因子是0.75的時候阻肿，空間利用率比較高瓦戚，而且避免了相當多的Hash沖突，使得底層的鏈表或者是紅黑樹的高度比較低冕茅，提升了空間效率伤极。
OK，寫到這答案基本上就出來了姨伤，一句話能總結(jié)的寫成了一篇文章哨坪。如有問題，還請批評指正乍楚。
————————————————
原文鏈接：https://blog.csdn.net/SDDDLLL/java/article/details/104040352
