HashMap

一、HashMap的數據結構
在java編程語言中，最基本的結構就是兩種，一個是數組，另一個是模擬指針（引用），全部的數據結構均可以用這兩個基本結構來構造的。HashMap其實是一個數組和鏈表的結合體。

當新建一個hashmap的時候，就會初始化一個數組。

 transient Entry[] table;  

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值來求得對應數組中的位置。hashmap的數據結構是數組和鏈表的結合，但願這個hashmap裏面的元素位置儘可能的分佈均勻些，儘可能使得每一個位置上的元素數量只有一個，那麼當用hash算法求得這個位置的時候，立刻就能夠知道對應位置的元素就是想要的，而不用再去遍歷鏈表。
首先想到的就是把hashcode對數組長度取模運算，這樣一來，元素的分佈相對來講是比較均勻的。可是，「模」運算的消耗仍是比較大的。因此Java中是這樣作的：首先算得key得hashcode值，而後跟數組的長度-1作一次「與」運算（&）。

static int indexFor(int h, int length) {  
       return h & (length-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的size爲2的整數次冪次方。就算不指定的話，也會以大於且最接近指定值大小的2次冪來初始化的。

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

三、HashMap的resize 

當hashmap中的元素愈來愈多時，碰撞的概率也就愈來愈高（由於數組的長度是固定的），因此爲了提升查詢的效率，就要對hashmap的數組進行擴容，在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)更合適，即便是1000，hashmap也自動會將其設置爲1024。 可是new HashMap(1024)還不是更合適的，由於0.75*1000 < 1000, 也就是說爲了讓0.75 * size > 1000, 必須這樣new HashMap(2048)才最合適，既考慮了&的問題，也避免了resize的問題。

四、key的hashcode與equals方法改寫
hashmap的get方法的過程：首先計算key的hashcode，找到數組中對應位置的某一元素，而後經過key的equals方法在對應位置的鏈表中找到須要的元素。因此，hashcode與equals方法對於找到對應元素是兩個關鍵方法。
Hashmap的key能夠是任何類型的對象，但必定要是不可變對象。
在改寫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(前提是你確實有這樣的須要)。

五、JDK1.8中對HashMap的優化 

五、JDK1.8中對HashMap的優化
(1)、HashMap是數組+鏈表+紅黑樹（JDK1.8增長了紅黑樹部分）實現的

當鏈表長度太長（TREEIFY_THRESHOLD默認超過8）時，鏈表就轉換爲紅黑樹，利用紅黑樹快速增刪改查的特色提升HashMap的性能（O(logn)）。當長度小於（UNTREEIFY_THRESHOLD默認爲6），就會退化成鏈表。
HashMap 中關於紅黑樹的三個關鍵參數

TREEIFY_THRESHOLD   桶的樹化閾值	UNTREEIFY_THRESHOLD   樹的鏈表還原閾值	MIN_TREEIFY_CAPACITY   哈希表的最小樹形化容量
static final int TREEIFY_THRESHOLD= 8	static final int UNTREEIFY_THRESHOLD = 6	static final int MIN_TREEIFY_CAPACITY = 64
當桶中元素個數超過這個值時須要使用紅黑樹節點替換鏈表節點	當擴容時，桶中元素個數小於這個值就會把樹形的桶元素還原（切分）爲鏈表結構	當哈希表中的容量大於這個值時，表中的桶才能進行樹形化，不然桶內元素太多時會擴容，而不是樹形化 爲了不進行擴容、樹形化選擇的衝突，這個值不能小於4 * TREEIFY_THRESHOLD

(2)、擴容機制

使用的是2次冪的擴展(指長度擴爲原來2倍)，因此元素的位置要麼是在原位置，要麼是在原位置再移動2次冪的位置。
圖（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不會倒置。