摘要
HashMap是程序員使用頻率較高的一種用於映射（鍵值對）處理的數據類型，隨着JDK（Java Development Kit）版本的更新，HashMap也在不斷被優化。其中JDK1.8在HashMap底層引入了紅黑樹的數據結構並對其擴容進行了優化等。本文將結合JDK1.7與JDK1.8對HashMap進行分析，淺析HashMap在JDK1.8中的改進。
一、HashMap的繼承體系和特點
1、HashMap的繼承體系
java.util.Map是java爲數據結構中的映射定義的接口，實現此接口的有四個常用類，分別是HashMap、HashTable、LinkedHashMap和TreeMap，他們的繼承關係如下：
2、HashMap及相關類的特點：
① HashMap：它根據鍵（key）的HashCode值存儲數據，大多數情況下可以直接定位到它的值，因此具有很快的訪問速度，但遍歷順序卻是不確定的。HashMap最多允許一個元素的鍵爲null，允許多個元素的值爲null。HashMap是非線程安全的，即可以有多個線程同時訪問HashMap，可能導致數據的前後訪問不一致。可以用Collections的synchronizedMap方法使HashMap具有線程安全的能力，或者直接使用引入了分段鎖的ConcurrentHashMap。
② HashTable：HashTable是遺留類，很多映射的常用功能與HashMap類似，不同的是HashTable繼承自Dictionary類，並且是線程安全的，任一時刻只允許一個線程訪問HashTable，併發性不如ConcurrentHashMap。新代碼中不建議使用HashTable，因爲在不需要線程安全的場合可以用HashMap代替，需要線程安全的場合可以用ConcurrentHashMap替代。
③ LinkedHashMap：LinkedHashMap是HashMap的一個子類，它保存了元素的插入順序，在用Iterator遍歷LinkedHashMap時，先得到的元素肯定是先插入的，也可以在構造時帶參數，按照訪問次序排序。
④ TreeMap：TreeMap實現了SortedMap接口，能夠將它的元素根據鍵排序，默認根據鍵的升序排序，也可以指定排序的比較器。當用Iterator遍歷TreeMap時，得到的結果是排過序的，如果需要排序的映射，建議使用TreeMap。在使用TreeMap時，key必須實現Comparable接口或者在構造TreeMap時傳入自定義的Comparator，否則會在運行時拋出java.lang.ClassCastException類型的異常。
通過以上比較，我們瞭解到HashMap是java中Map家族的普通一員，因爲它是滿足大多數場景的使用條件，所以HashMap是使用最頻繁的一個。下面我們將結合HashMap源碼，從存儲結構、常用方法、擴容以及安全性等方面深入理解HashMap的工作原理。
二、HashMap的內部實現
1、HashMap是什麼——存儲結構
從結構來講，HashMap是數組+鏈表+紅黑樹（JDK1.8新增紅黑樹部分）實現的，數組table存放類型爲Node<K,V>的結點，該結點向外引申出單向鏈表，當鏈表長度大於8時，轉換爲紅黑樹。如下圖所示：
Node [] table數組被稱爲哈希桶數組。那麼Node到底是什麼？JDK1.8中對Node<K,V>的定義如下：
static class Node<K,V> implements Map.Entry<K,V> {
final int hash;//用來定爲數組索引位置
final K key;
V value;
Node<K,V> next;//鏈表的下一個Node
Node(int hash, K key, V value, Node<K,V> next) { ··· }
public final K getKey() { ··· }
public final V getValue() { ··· }
public final String toString() { ··· }
public final int hashCode() { ··· }
public final V setValue(V newValue) { ··· }
public final boolean equals(Object o) { ··· }
}Node是HashMap的一個內部類，實現了Map.Entry接口，本質上就是一個映射（鍵值對），上圖中的每個藍色橢圓就表示一個Node的對象。
HashMap使用哈希表存儲的。爲解決哈希衝突，哈希表可以採用開放地址法和鏈地址法等方法，java中的HashMap採用的是鏈地址法。所謂鏈地址法，簡單來說就是數組加鏈表的組合，每個數組元素上都有一個鏈表結構，將數據被hash後得到的數字作爲數組下標，將該元素添加到對應下標下的鏈表中。舉例說明，假如程序在執行以下代碼：
map.put("通信","張三");系統會“通信”這個key的hashCode方法（該方法適用於任何java對象）得到其HashCode值，再通過Hash算法的後兩步運算（高位運算和取模運算）來定位該鍵值對的存儲位置。有時兩個key會定位到相同的位置，表示發生了哈希碰撞。hash算法計算結果越分散均勻，發生哈希碰撞的概率就越小，HashMap的存儲效率就越高。這就會出現以下問題，如果哈希桶數組足夠大，即使差的hash算法分佈也比較均勻，相反如果哈希桶數組很小，即使好的hash算法也很難避免出現較多碰撞。因此就需要在時間成本和空間成本之間有所權衡，即根據實際情況設定合適大小的哈希桶數組，並設計好的hash算法來減少哈希碰撞。那麼通過什麼方式來控制HashMap使哈希桶數組佔用空間又少有能降低hash碰撞的機率呢？答案就是好的hash算法加擴容機制。
在理解Hash和擴容流程之前，我們得先了解下HashMap的幾個字段。從HashMap的默認構造函數源碼可知，構造函數就是對以下幾個字段進行初始化，源碼如下：
int threshold; //所能容納的key-value對極限
final float loadFactor；//負載因子
int modCount；
int size；
首先，Node[] table的初始長度length（默認值是16），loadFactor爲負載因子（默認是0.75），threshold是HashMap所能容納的最大數據量的Node個數。threshold=length*loadFactor。也就是說，在數組定義好長度後，負載因子越大，所能容納的鍵值對的個數越多。
結合負載因子的定義公式可知，threshold就是在此loadFactor和length對應下允許的最大元素數目，超過這個數目就重新resize，擴容後的HashMap容量是之前的兩倍。默認的負載因子是0.75，是對空間和時間效率的一個平衡選擇，建議大家不要修改，除非在時間和空間比較特殊的情況下，如果內存空間很多而又對時間效率要求很高，可以降低負載因子loadFactor的值，相反，如果內存空間緊張而對時間效率要求不高，可以增加負載因子loadFactor的值，這個值可以大於1。
size這個字段很好理解，就是HashMap中實際存在的鍵值對數量。注意和table的長度length、容納最大鍵值對數量threshold的區別。而modCount字段主要用來記錄HashMap內部結構發生變化的次數，主要用於迭代的快速失敗。強調，內部結構發生變化指的是結構發生變化，例如put新鍵值對，但是某個key對應的value值被覆蓋不屬於結構變化。
在HashMap中，哈希桶數組table的長度length大小必須爲2的n次方，這是一種非常規的設計，常規的設計是把桶的大小設計爲素數。相對來說素數導師衝突的概率要小與合數，Hashtable初始化桶大小爲11，就是桶大小設計爲素數的應用。HashMap採用這種非常規設計，主要是爲了在取模和擴容時做優化，同時爲了減少衝突，HashMap定位哈希桶索引位置時，也加入了高位參與運算的過程。
這裏存在一個問題，即使負載因子和hash算法設計的再合理，也免不了會出現拉鍊過長的情況，一旦出現拉鍊過長，則會嚴重影響HashMap的性能。於是，在JDK1.8版本中，對數據結構做了進一步的優化，引入了紅黑樹。而當鏈表長度大於8時，鏈表就轉換爲紅黑樹，利用紅黑樹快速增刪改查的特點提高HashMap的性能，其中會用到紅黑樹的插入、刪除、查找等算法。本文不再對紅黑樹展開討論，想了解很多紅黑樹數據結構的工作原理可以參考另一篇博文深入理解紅黑樹。
2、HashMap能幹什麼——功能實現
HashMap的內部功能實現很多，本文主要從根據key獲取哈希桶數組索引位置、put方法的詳細執行過程、擴容過程這三個具有代表性的點深入展開。
根據key確定哈希桶數組索引位置
不管是增加、刪除還是查找鍵值對，定位到哈希桶數組的位置都是很關鍵的第一步。前面說到HashMap的結構是數組加鏈表的組合，所以我們當然希望HashMap裏的元素分佈儘量均勻些。HashMap定位數組索引位置，直接決定了HashMap的離散性能。我們先看一下源碼對hash算法的實現：
h=key.hashCode() 爲算法第一步，取hashCode值；
h^(h>>>16) 爲算法第二步，高位參與運算；
我們注意到在JDK1.7的源碼中有這樣一個方法：
static int indexFor(int h,int length){
return h&(length-1);
}其中的h&(length-1)爲hash算法的第三步，取模運算，這個方法在JDK1.8中沒有出現，但是實現原理是相同的。
h&(table.length-1)這個方法非常巧妙，因爲一本我們能想到的計算索引方法就是將hash值對table數組長度進行取模運算，但模運算的消耗還是比較大的，而HashMap底層的數組長度總是2的n次方，這是HashMap在速度上的優化。當length總是2的n次方的時候，h&(length-1)等價於取模運算，但&比%具有更高的效率。
JDK1.8中，優化了高位運算的算法，通過將hash的高16位與低16位進行異或運算，主要是從速度、功效、質量上考慮的，這麼做可以在table的length很小的時候也能考慮到高低位都參與到運算中，同時不會有太大的開銷。
具體計算過程如下：
HashMap的put過程
可以通過下圖來輔助理解HashMap的put過程：
JDK1.8中HashMap的put方法源碼如下：
此方法將對key進行hash運算，得到hash值。
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
//第一步，判斷table是否爲空，如果爲空，創建
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
//第二步，計算index，並對null做處理
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
else {
Node<K,V> e; K k;
//第三步，如果key結點已經存在，直接覆蓋value
if (p.hash == hash &&((k = p.key) == key || (key != null && key.equals(k))))
e = p;
//第四步，判斷該鏈是否爲紅黑樹
else if (p instanceof TreeNode)
e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
//該鏈爲鏈表
else {
for (int binCount = 0; ; ++binCount) {
//如果鏈表爲空，直接插入
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null);
//如果鏈表長度大於8，轉換爲紅黑樹進行操作
if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
treeifyBin(tab, hash);
break;
}
//key已經存在，直接覆蓋value
if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
}
if (e != null) { // existing mapping for key
V oldValue = e.value;
if (!onlyIfAbsent || oldValue == null)
e.value = value;
afterNodeAccess(e);
return oldValue;
}
}
++modCount;
//第五步，超過最大容量，擴容
if (++size > threshold)
resize();
afterNodeInsertion(evict);
return null;
} HashMap的擴容機制
擴容（resize）就是重新計算容量，向HashMap裏不停的添加元素，而當HashMap對象內部的數組無法裝載更多的元素時，對象就需要擴大數組長度，以便能裝入更多的元素。當然java裏的數組是無法自動擴容的，方法是使用一個新的數組代替已有的容量小的數組，就像我們用一個小桶裝水，如果想裝更多的水，就得換更大的水桶。
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數組
thteshold=(int)(newCapacity*loadFactor);//修改閾值
}
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);
}
}
}
newTable[i]的引用賦給了e.next，也就是使用了單鏈表的頭插方式，同一位置上的新元素總會被放到鏈表的頭部位置；這樣先放在一個索引上的元素終會被放到Entry鏈的尾部（如果發生了Hash衝突的話）。這一點和JDK1.8有區別，下文詳解。在舊數組中同一條Entry鏈上的元素，通過重新計算索引位置後，有可能被放到了新數組的不同位置上。
下面舉個例子說明一下擴容過程。假設我們的hash算法就是簡單的用key mod一下數組的長度。其中的哈希桶數組table的size=2，所以key=3、7、5，put順序依次爲5、7、3.在mod 2以後都衝突在table[1]這裏了。假設負載因子loadFactor=1，即當鍵值對的實際大小size大於table的實際大小時擴容。接下來的三個步驟是哈希桶數組resize成4，然後所有的Node重新rehash的過程。
下面我們講解下JDK1.8做了哪些優化。經過觀察可以發現，我們使用的是2次冪的擴展（長多擴爲原來的2倍），所以，元素的位置要麼是在原位置，要麼是在原位置再移動2次冪的位置上，因此我們在擴充HashMap的時候，不需要像JDK1.7那樣重新計算hash，只需要看看原來的hash值新增的那個bit是1還是0就好了，是0的話索引不變，是1的話索引變成“原索引+oldCapacity”。可以藉助下圖來理解：
這個設計非常巧妙，既省去了重新計算hash值的時間，同時，由於新增的1位是0還是1可以認爲是隨機的，因此resize的過程均勻的吧之前的衝突的結點分散到新的bucket了，這一塊就是JDK1.8新增的優化點。有一點注意區別，JDK1.7中rehash的時候，舊鏈表遷移新鏈表的時候，如果在新表的數組索引位置相同，則鏈表元素會倒置，但是從上圖可以看出，JDK1.8不會倒置。有興趣的讀者可以研究下JDK1.8的resize源碼，如下：
final Node<K,V>[] resize() {
Node<K,V>[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
if (oldCap > 0) {
//超過最大值就不再擴容了
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}
//沒超過最大值，就擴爲原來的2倍
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
else if (oldThr > 0) // initial capacity was placed in threshold
newCap = oldThr;
else { // zero initial threshold signifies using defaults
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
//設置新的resize上限
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
threshold = newThr;
@SuppressWarnings({"rawtypes","unchecked"})
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
table = newTab;
if (oldTab != null) {
//把每個bucket都移到新的buckets中
for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null;
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
else { // preserve order
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
}
}
}
return newTab;
}
1、擴容是一個特別耗性能的操作，所以當程序員在使用HashMap的時候，估算map的大小，初始化的時候給一個大致的數值，避免map進行頻繁的擴容。
2、負載因子是可以修改的，也可以大於1，但是建議不要輕易修改，除非情況非常特殊。
3、HashMap是線程不安全的，不要在併發的環境中同時操作HashMap，建議使用ConcurrentHashMap。
4、JDK1.8引入紅黑樹大程度優化了HashMap的性能
5、還沒升級JDK1.8的，現在升級吧。HashMap的性能提升僅僅是JDK1.8的冰沙一角。