HashMap的擴容機制---resize()

時間 2019-12-09

標籤 hashmap 擴容機制 resize 简体版

原文原文鏈接

面試的時候聞到了Hashmap的擴容機制，以前只看到了Hasmap的實現機制，補一下基礎知識，講的很是好html

原文連接：java

http://www.iteye.com/topic/539465面試

Hashmap是一種很是經常使用的、應用普遍的數據類型，最近研究到相關的內容，就正好複習一下。網上關於hashmap的文章不少，但究竟是本身學習的總結，就發出來跟你們一塊兒分享，一塊兒討論。

一、hashmap的數據結構
要知道hashmap是什麼，首先要搞清楚它的數據結構，在java編程語言中，最基本的結構就是兩種，一個是數組，另一個是模擬指針（引用），全部的數據結構均可以用這兩個基本結構來構造的，hashmap也不例外。Hashmap其實是一個數組和鏈表的結合體（在數據結構中，通常稱之爲「鏈表散列「），請看下圖（橫排表示數組，縱排表示數組元素【其實是一個鏈表】）。

從圖中咱們能夠看到一個hashmap就是一個數組結構，當新建一個hashmap的時候，就會初始化一個數組。咱們來看看java代碼：算法

Java代碼

/**
* The table, resized as necessary. Length MUST Always be a power of two.
* FIXME 這裏須要注意這句話，至於緣由後面會講到
*/
transient Entry[] table;

Java代碼

static class Entry<K,V> implements Map.Entry<K,V> {
final K key;
V value;
final int hash;
Entry<K,V> next;
..........
}

上面的Entry就是數組中的元素，它持有一個指向下一個元素的引用，這就構成了鏈表。
當咱們往hashmap中put元素的時候，先根據key的hash值獲得這個元素在數組中的位置（即下標），而後就能夠把這個元素放到對應的位置中了。若是這個元素所在的位子上已經存放有其餘元素了，那麼在同一個位子上的元素將以鏈表的形式存放，新加入的放在鏈頭，最早加入的放在鏈尾。從hashmap中get元素時，首先計算key的hashcode，找到數組中對應位置的某一元素，而後經過key的equals方法在對應位置的鏈表中找到須要的元素。從這裏咱們能夠想象獲得，若是每一個位置上的鏈表只有一個元素，那麼hashmap的get效率將是最高的，可是理想老是美好的，現實老是有困難須要咱們去克服，哈哈~

二、hash算法
咱們能夠看到在hashmap中要找到某個元素，須要根據key的hash值來求得對應數組中的位置。如何計算這個位置就是hash算法。前面說過hashmap的數據結構是數組和鏈表的結合，因此咱們固然但願這個hashmap裏面的元素位置儘可能的分佈均勻些，儘可能使得每一個位置上的元素數量只有一個，那麼當咱們用hash算法求得這個位置的時候，立刻就能夠知道對應位置的元素就是咱們要的，而不用再去遍歷鏈表。

因此咱們首先想到的就是把hashcode對數組長度取模運算，這樣一來，元素的分佈相對來講是比較均勻的。可是，「模」運算的消耗仍是比較大的，能不能找一種更快速，消耗更小的方式那？java中時這樣作的，

Java代碼

static int indexFor(int h, int length) {
return h & (length-1);
}

首先算得key得hashcode值，而後跟數組的長度-1作一次「與」運算（&）。看上去很簡單，其實比較有玄機。好比數組的長度是2的4次方，那麼hashcode就會和2的4次方-1作「與」運算。不少人都有這個疑問，爲何hashmap的數組初始化大小都是2的次方大小時，hashmap的效率最高，我以2的4次方舉例，來解釋一下爲何數組大小爲2的冪時hashmap訪問的性能最高。

         看下圖，左邊兩組是數組長度爲16（2的4次方），右邊兩組是數組長度爲15。兩組的hashcode均爲8和9，可是很明顯，當它們和1110「與」的時候，產生了相同的結果，也就是說它們會定位到數組中的同一個位置上去，這就產生了碰撞，8和9會被放到同一個鏈表上，那麼查詢的時候就須要遍歷這個鏈表，獲得8或者9，這樣就下降了查詢的效率。同時，咱們也能夠發現，當數組長度爲15的時候，hashcode的值會與14（1110）進行「與」，那麼最後一位永遠是0，而0001，0011，0101，1001，1011，0111，1101這幾個位置永遠都不能存放元素了，空間浪費至關大，更糟的是這種狀況中，數組可使用的位置比數組長度小了不少，這意味着進一步增長了碰撞的概率，減慢了查詢的效率！

          因此說，當數組長度爲2的n次冪的時候，不一樣的key算得得index相同的概率較小，那麼數據在數組上分佈就比較均勻，也就是說碰撞的概率小，相對的，查詢的時候就不用遍歷某個位置上的鏈表，這樣查詢效率也就較高了。
          說到這裏，咱們再回頭看一下hashmap中默認的數組大小是多少，查看源代碼能夠得知是16，爲何是16，而不是15，也不是20呢，看到上面annegu的解釋以後咱們就清楚了吧，顯然是由於16是2的整數次冪的緣由，在小數據量的狀況下16比15和20更能減小key之間的碰撞，而加快查詢的效率。

因此，在存儲大容量數據的時候，最好預先指定hashmap的size爲2的整數次冪次方。就算不指定的話，也會以大於且最接近指定值大小的2次冪來初始化的，代碼以下(HashMap的構造方法中)：編程

Java代碼

// Find a power of 2 >= initialCapacity
int capacity = 1;
while (capacity < initialCapacity)
capacity <<= 1;

總結：
本文主要描述了HashMap的結構，和hashmap中hash函數的實現，以及該實現的特性，同時描述了hashmap中resize帶來性能消耗的根本緣由，以及將普通的域模型對象做爲key的基本要求。尤爲是hash函數的實現，能夠說是整個HashMap的精髓所在，只有真正理解了這個hash函數，才能夠說對HashMap有了必定的理解。數組

三、hashmap的resize

當hashmap中的元素愈來愈多的時候，碰撞的概率也就愈來愈高（由於數組的長度是固定的），因此爲了提升查詢的效率，就要對hashmap的數組進行擴容，數組擴容這個操做也會出如今ArrayList中，因此這是一個通用的操做，不少人對它的性能表示過懷疑，不過想一想咱們的「均攤」原理，就釋然了，而在hashmap數組擴容以後，最消耗性能的點就出現了：原數組中的數據必須從新計算其在新數組中的位置，並放進去，這就是resize。

那麼hashmap何時進行擴容呢？當hashmap中的元素個數超過數組大小*loadFactor時，就會進行數組擴容，loadFactor的默認值爲0.75，也就是說，默認狀況下，數組大小爲16，那麼當hashmap中元素個數超過16*0.75=12的時候，就把數組的大小擴展爲2*16=32，即擴大一倍，而後從新計算每一個元素在數組中的位置，而這是一個很是消耗性能的操做，因此若是咱們已經預知hashmap中元素的個數，那麼預設元素的個數可以有效的提升hashmap的性能。好比說，咱們有1000個元素new HashMap(1000), 可是理論上來說new HashMap(1024)更合適，不過上面annegu已經說過，即便是1000，hashmap也自動會將其設置爲1024。可是new HashMap(1024)還不是更合適的，由於0.75*1000 < 1000, 也就是說爲了讓0.75 * size > 1000, 咱們必須這樣new HashMap(2048)才最合適，既考慮了&的問題，也避免了resize的問題。

四、key的hashcode與equals方法改寫
在第一部分hashmap的數據結構中，annegu就寫了get方法的過程：首先計算key的hashcode，找到數組中對應位置的某一元素，而後經過key的equals方法在對應位置的鏈表中找到須要的元素。因此，hashcode與equals方法對於找到對應元素是兩個關鍵方法。

Hashmap的key能夠是任何類型的對象，例如User這種對象，爲了保證兩個具備相同屬性的user的hashcode相同，咱們就須要改寫hashcode方法，比方把hashcode值的計算與User對象的id關聯起來，那麼只要user對象擁有相同id，那麼他們的hashcode也能保持一致了，這樣就能夠找到在hashmap數組中的位置了。若是這個位置上有多個元素，還須要用key的equals方法在對應位置的鏈表中找到須要的元素，因此只改寫了hashcode方法是不夠的，equals方法也是須要改寫滴~固然啦，按正常思惟邏輯，equals方法通常都會根據實際的業務內容來定義，例如根據user對象的id來判斷兩個user是否相等。
在改寫equals方法的時候，須要知足如下三點：
(1) 自反性：就是說a.equals(a)必須爲true。
(2) 對稱性：就是說a.equals(b)=true的話，b.equals(a)也必須爲true。
(3) 傳遞性：就是說a.equals(b)=true，而且b.equals(c)=true的話，a.equals(c)也必須爲true。
經過改寫key對象的equals和hashcode方法，咱們能夠將任意的業務對象做爲map的key(前提是你確實有這樣的須要)。數據結構

雖然在hashmap的原理裏面有這段，可是這個單獨拿出來說rehash或者resize()也是極好的。編程語言

何時擴容：當向容器添加元素的時候，會判斷當前容器的元素個數，若是大於等於閾值---即當前數組的長度乘以加載因子的值的時候，就要自動擴容啦。函數

擴容(resize)就是從新計算容量，向HashMap對象裏不停的添加元素，而HashMap對象內部的數組沒法裝載更多的元素時，對象就須要擴大數組的長度，以便能裝入更多的元素。固然Java裏的數組是沒法自動擴容的，方法是使用一個新的數組代替已有的容量小的數組，就像咱們用一個小桶裝水，若是想裝更多的水，就得換大水桶。

咱們分析下resize的源碼，鑑於JDK1.8融入了紅黑樹，較複雜，爲了便於理解咱們仍然使用JDK1.7的代碼，好理解一些，本質上區別不大，具體區別後文再說。

void resize(int newCapacity) { //傳入新的容量
Entry[] oldTable = table; //引用擴容前的Entry數組
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) { //擴容前的數組大小若是已經達到最大(2^30)了
threshold = Integer.MAX_VALUE; //修改閾值爲int的最大值(2^31-1)，這樣之後就不會擴容了
return;
}
Entry[] newTable = new Entry[newCapacity]; //初始化一個新的Entry數組
transfer(newTable); //！！將數據轉移到新的Entry數組裏
table = newTable; //HashMap的table屬性引用新的Entry數組
threshold = (int) (newCapacity * loadFactor);//修改閾值
}

這裏就是使用一個容量更大的數組來代替已有的容量小的數組，transfer()方法將原有Entry數組的元素拷貝到新的Entry數組裏。

void transfer(Entry[] newTable) {
Entry[] src = table; //src引用了舊的Entry數組
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) { //遍歷舊的Entry數組
Entry<K, V> e = src[j]; //取得舊Entry數組的每一個元素
if (e != null) {
src[j] = null;//釋放舊Entry數組的對象引用（for循環後，舊的Entry數組再也不引用任何對象）
do {
Entry<K, V> next = e.next;
int i = indexFor(e.hash, newCapacity); //！！從新計算每一個元素在數組中的位置
e.next = newTable[i]; //標記[1]
newTable[i] = e; //將元素放在數組上
e = next; //訪問下一個Entry鏈上的元素
} while (e != null);
}
}
}

static int indexFor(int h, int length) {
return h & (length - 1);
}

文章中間部分:4、存儲實現；詳細解釋了爲何indexFor方法中要h & (length-1)

newTable[i]的引用賦給了e.next，也就是使用了單鏈表的頭插入方式，同一位置上新元素總會被放在鏈表的頭部位置；這樣先放在一個索引上的元素終會被放到Entry鏈的尾部(若是發生了hash衝突的話），這一點和Jdk1.8有區別，下文詳解。在舊數組中同一條Entry鏈上的元素，經過從新計算索引位置後，有可能被放到了新數組的不一樣位置上。

下面舉個例子說明下擴容過程。

這句話是重點----hash(){return key % table.length;}方法,就是翻譯下面的一行解釋：

假設了咱們的hash算法就是簡單的用key mod 一下表的大小（也就是數組的長度）。

其中的哈希桶數組table的size=2，因此key = 三、七、5，put順序依次爲五、七、3。在mod 2之後都衝突在table[1]這裏了。這裏假設負載因子 loadFactor=1，即當鍵值對的實際大小size 大於 table的實際大小時進行擴容。接下來的三個步驟是哈希桶數組 resize成4，而後全部的Node從新rehash的過程。

下面咱們講解下JDK1.8作了哪些優化。通過觀測能夠發現，咱們使用的是2次冪的擴展(指長度擴爲原來2倍)，因此，

通過rehash以後，元素的位置要麼是在原位置，要麼是在原位置再移動2次冪的位置。對應的就是下方的resize的註釋。

[java] view plain copy

/**
* Initializes or doubles table size. If null, allocates in
* accord with initial capacity target held in field threshold.
* Otherwise, because we are using power-of-two expansion, the
* elements from each bin must either stay at same index, or move
* with a power of two offset in the new table.
*
* @return the table
*/
final Node<K,V>[] resize() {

看下圖能夠明白這句話的意思，n爲table的長度，圖（a）表示擴容前的key1和key2兩種key肯定索引位置的示例，圖（b）表示擴容後key1和key2兩種key肯定索引位置的示例，其中hash1是key1對應的哈希與高位運算結果。

元素在從新計算hash以後，由於n變爲2倍，那麼n-1的mask範圍在高位多1bit(紅色)，所以新的index就會發生這樣的變化：

所以，咱們在擴充HashMap的時候，不須要像JDK1.7的實現那樣從新計算hash，只須要看看原來的hash值新增的那個bit是1仍是0就行了，是0的話索引沒變，是1的話索引變成「原索引+oldCap」，能夠看看下圖爲16擴充爲32的resize示意圖：

這個設計確實很是的巧妙，既省去了從新計算hash值的時間，並且同時，因爲新增的1bit是0仍是1能夠認爲是隨機的，所以resize的過程，均勻的把以前的衝突的節點分散到新的bucket了。這一塊就是JDK1.8新增的優化點。有一點注意區別，JDK1.7中rehash的時候，舊鏈表遷移新鏈表的時候，若是在新表的數組索引位置相同，則鏈表元素會倒置，可是從上圖能夠看出，JDK1.8不會倒置。有興趣的同窗能夠研究下JDK1.8的resize源碼，寫的很贊，以下:

1 final Node<K,V>[] resize() {
2 Node<K,V>[] oldTab = table;
3 int oldCap = (oldTab == null) ? 0 : oldTab.length;
4 int oldThr = threshold;
5 int newCap, newThr = 0;
6 if (oldCap > 0) {
7 // 超過最大值就再也不擴充了，就只好隨你碰撞去吧
8 if (oldCap >= MAXIMUM_CAPACITY) {
9 threshold = Integer.MAX_VALUE;
10 return oldTab;
11 }
12 // 沒超過最大值，就擴充爲原來的2倍
13 else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
14 oldCap >= DEFAULT_INITIAL_CAPACITY)
15 newThr = oldThr << 1; // double threshold
16 }
17 else if (oldThr > 0) // initial capacity was placed in threshold
18 newCap = oldThr;
19 else { // zero initial threshold signifies using defaults
20 newCap = DEFAULT_INITIAL_CAPACITY;
21 newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
22 }
23 // 計算新的resize上限
24 if (newThr == 0) {
25
26 float ft = (float)newCap * loadFactor;
27 newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
28 (int)ft : Integer.MAX_VALUE);
29 }
30 threshold = newThr;
31 @SuppressWarnings({"rawtypes"，"unchecked"})
32 Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
33 table = newTab;
34 if (oldTab != null) {
35 // 把每一個bucket都移動到新的buckets中
36 for (int j = 0; j < oldCap; ++j) {
37 Node<K,V> e;
38 if ((e = oldTab[j]) != null) {
39 oldTab[j] = null;
40 if (e.next == null)
41 newTab[e.hash & (newCap - 1)] = e;
42 else if (e instanceof TreeNode)
43 ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
44 else { // 鏈表優化重hash的代碼塊
45 Node<K,V> loHead = null, loTail = null;
46 Node<K,V> hiHead = null, hiTail = null;
47 Node<K,V> next;
48 do {
49 next = e.next;
50 // 原索引
51 if ((e.hash & oldCap) == 0) {
52 if (loTail == null)
53 loHead = e;
54 else
55 loTail.next = e;
56 loTail = e;
57 }
58 // 原索引+oldCap
59 else {
60 if (hiTail == null)
61 hiHead = e;
62 else
63 hiTail.next = e;
64 hiTail = e;
65 }
66 } while ((e = next) != null);
67 // 原索引放到bucket裏
68 if (loTail != null) {
69 loTail.next = null;
70 newTab[j] = loHead;
71 }
72 // 原索引+oldCap放到bucket裏
73 if (hiTail != null) {
74 hiTail.next = null;
75 newTab[j + oldCap] = hiHead;
76 }
77 }
78 }
79 }
80 }
81 return newTab;
82 }

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。