面試官:爲什麼 HashMap 的加載因子是 0-75?

有很多東西之前在學的時候沒怎麼注意,筆者也是在重溫 HashMap 的時候發現有很多可以去細究的問題,最終是會迴歸於數學的,如 HashMap 的加載因子爲什麼是 0.75?

本文主要對以下內容進行介紹:

爲什麼 HashMap 需要加載因子?

HashMap 的底層是哈希表,是存儲鍵值對的結構類型,它需要通過一定的計算纔可以確定數據在哈希表中的存儲位置:

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
// AbstractMap
public int hashCode() {
     int h = 0;
     Iterator<Entry<K,V>> i = entrySet().iterator();
     while (i.hasNext())
         h += i.next().hashCode();

     return h;
}

一般的數據結構,不是查詢快就是插入快,HashMap 就是一個插入慢、查詢快的數據結構。

但這種數據結構容易產生兩種問題:① 如果空間利用率高,那麼經過的哈希算法計算存儲位置的時候,會發現很多存儲位置已經有數據了(哈希衝突);② 如果爲了避免發生哈希衝突,增大數組容量,就會導致空間利用率不高。

而加載因子就是表示 Hash 表中元素的填滿程度。

加載因子 = 填入表中的元素個數 / 散列表的長度

加載因子越大,填滿的元素越多,空間利用率越高,但發生衝突的機會變大了;

加載因子越小,填滿的元素越少,衝突發生的機會減小,但空間浪費了更多了,而且還會提高擴容 rehash 操作的次數。

衝突的機會越大,說明需要查找的數據還需要通過另一個途徑查找,這樣查找的成本就越高。因此,必須在 “衝突的機會” 與“空間利用率”之間,尋找一種平衡與折衷。

所以我們也能知道,影響查找效率的因素主要有這幾種:

本文主要對後兩個問題進行介紹。

解決衝突有什麼方法?

1. 開放定址法

Hi = (H(key) + di) MOD m,其中i=1,2,…,k(k<=m-1)

H(key) 爲哈希函數,m 爲哈希表表長,di 爲增量序列,i 爲已發生衝突的次數。其中,開放定址法根據步長不同可以分爲 3 種:

1.1 線性探查法(Linear Probing):di = 1,2,3,…,m-1

簡單地說,就是以當前衝突位置爲起點,步長爲 1 循環查找,直到找到一個空的位置,如果循環完了都佔不到位置,就說明容器已經滿了。舉個栗子,就像你在飯點去街上喫飯,挨家去看是否有位置一樣。

1.2 平方探測法(Quadratic Probing):di = ±12, ±22,±32,…,±k2(k≤m/2)

相對於線性探查法,這就相當於的步長爲 di = i2 來循環查找,直到找到空的位置。以上面那個例子來看,現在你不是挨家去看有沒有位置了,而是拿手機算去第 i2 家店,然後去問這家店有沒有位置。

1.3 僞隨機探測法:di = 僞隨機數序列

這個就是取隨機數來作爲步長。還是用上面的例子,這次就是完全按心情去選一家店問有沒有位置了。

但開放定址法有這些缺點:

2. 再哈希法

Hi = RHi(key)其中i=1,2,…,k

RHi() 函數是不同於 H() 的哈希函數,用於同義詞發生地址衝突時,計算出另一個哈希函數地址,直到不發生衝突位置。這種方法不容易產生堆集,但是會增加計算時間。

所以再哈希法的缺點是:增加了計算時間。

3. 建立一個公共溢出區

假設哈希函數的值域爲 [0, m-1],設向量 HashTable[0,…,m-1] 爲基本表,每個分量存放一個記錄,另外還設置了向量 OverTable[0,…,v]爲溢出表。基本表中存儲的是關鍵字的記錄,一旦發生衝突,不管他們哈希函數得到的哈希地址是什麼,都填入溢出表。

但這個方法的缺點在於:查找衝突數據的時候,需要遍歷溢出表才能得到數據。

4. 鏈地址法(拉鍊法)

將衝突位置的元素構造成鏈表。在添加數據的時候,如果哈希地址與哈希表上的元素衝突,就放在這個位置的鏈表上。

拉鍊法的優點:

拉鍊法的缺點:需要額外的存儲空間。

從 HashMap 的底層結構中我們可以看到,HashMap 採用是數組 + 鏈表 / 紅黑樹的組合來作爲底層結構,也就是開放地址法 + 鏈地址法的方式來實現 HashMap。

圖片

爲什麼 HashMap 加載因子一定是 0.75?而不是 0.8,0.6?

從上文我們知道,HashMap 的底層其實也是哈希表(散列表),而解決衝突的方式是鏈地址法。HashMap 的初始容量大小默認是 16,爲了減少衝突發生的概率,當 HashMap 的數組長度到達一個臨界值的時候,就會觸發擴容,把所有元素 rehash 之後再放在擴容後的容器中,這是一個相當耗時的操作。

而這個臨界值就是由加載因子和當前容器的容量大小來確定的:

臨界值 = DEFAULT_INITIAL_CAPACITY * DEFAULT_LOAD_FACTOR

即默認情況下是 16x0.75=12 時,就會觸發擴容操作。

那麼爲什麼選擇了 0.75 作爲 HashMap 的加載因子呢?這個跟一個統計學裏很重要的原理——泊松分佈有關。

泊松分佈是統計學和概率學常見的離散概率分佈,適用於描述單位時間內隨機事件發生的次數的概率分佈。有興趣的讀者可以看看維基百科或者阮一峯老師的這篇文章:泊松分佈和指數分佈:10 分鐘教程 [1]

圖片

等號的左邊,P 表示概率,N 表示某種函數關係,t 表示時間,n 表示數量。等號的右邊,λ 表示事件的頻率。

在 HashMap 的源碼中有這麼一段註釋:

* Ideally, under random hashCodes, the frequency of
* nodes in bins follows a Poisson distribution
* (http://en.wikipedia.org/wiki/Poisson_distribution) with a
* parameter of about 0.5 on average for the default resizing
* threshold of 0.75, although with a large variance because of
* resizing granularity. Ignoring variance, the expected
* occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
* factorial(k)). The first values are:
* 0:    0.60653066
* 1:    0.30326533
* 2:    0.07581633
* 3:    0.01263606
* 4:    0.00157952
* 5:    0.00015795
* 6:    0.00001316
* 7:    0.00000094
* 8:    0.00000006
* more: less than 1 in ten million

在理想情況下,使用隨機哈希碼,在擴容閾值(加載因子)爲 0.75 的情況下,節點出現在頻率在 Hash 桶(表)中遵循參數平均爲 0.5 的泊松分佈。忽略方差,即 X = λt,P(λt = k),其中λt = 0.5 的情況,按公式:

圖片

計算結果如上述的列表所示,當一個 bin 中的鏈表長度達到 8 個元素的時候,概率爲 0.00000006,幾乎是一個不可能事件。

所以我們可以知道,其實常數 0.5 是作爲參數代入泊松分佈來計算的,而加載因子 0.75 是作爲一個條件,當 HashMap 長度爲 length/size ≥ 0.75 時就擴容,在這個條件下,衝突後的拉鍊長度和概率結果爲:

0:    0.60653066
1:    0.30326533
2:    0.07581633
3:    0.01263606
4:    0.00157952
5:    0.00015795
6:    0.00001316
7:    0.00000094
8:    0.00000006

那麼爲什麼不可以是 0.8 或者 0.6 呢?

HashMap 中除了哈希算法之外,有兩個參數影響了性能:初始容量和加載因子。初始容量是哈希表在創建時的容量,加載因子是哈希表在其容量自動擴容之前可以達到多滿的一種度量。

在維基百科來描述加載因子:

對於開放定址法,加載因子是特別重要因素,應嚴格限制在 0.7-0.8 以下。超過 0.8,查表時的 CPU 緩存不命中(cache missing)按照指數曲線上升。因此,一些採用開放定址法的 hash 庫,如 Java 的系統庫限制了加載因子爲 0.75,超過此值將 resize 散列表。

在設置初始容量時應該考慮到映射中所需的條目數及其加載因子,以便最大限度地減少擴容 rehash 操作次數,所以,一般在使用 HashMap 時建議根據預估值設置初始容量,以便減少擴容操作。

選擇 0.75 作爲默認的加載因子,完全是時間和空間成本上尋求的一種折衷選擇。

參考資料

[1] 泊松分佈和指數分佈:10 分鐘教程: http://www.ruanyifeng.com/blog/2015/06/poisson-distribution.html

作者:NYfor2020

來源:https://blog.csdn.net/NYfor2017

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/217xV3ou_XP28h9Vh2wRkA