HashMap相關類：Hashtable、LinkHashMap、TreeMap
前言
很高興遇見你~
在 深入剖析HashMap 文章中我從散列表的角度解析了HashMap，在 深入解析ConcurrentHashMap：感受併發程式設計智慧 解析了ConcurrentHashMap的底層實現原理。本文是HashMap系列文章的第三篇，主要內容是講解與HashMap相關的集合類。
HashMap本身功能已經相對完善，但在某些特殊的情景下，他就顯得無能為力，如高併發、需要記住key插入順序、給key排序等。實現這些功能往往需要付出一定的代價，在沒有必然的需求情景下，增添這些功能是沒必要的。因而，為了提高效能，Java並沒有把這些特性直接整合到HashMap中，拓展了擁有這些特性的其他集合類作為補充：
- 執行緒安全的ConcurrentHashMap、Hashtable、SynchronizeMap
- 記住插入順序的LinkedHashMap
- 記錄key順序的TreeMap
這樣，我們就可以在特定的需求情景下，選擇最適合我們的集合框架，從而來提高效能。那麼今天這篇文章，主要就是分析這些其他的集合類的特性、付出的效能代價、與HashMap的區別。
那麼，我們開始吧~
Hashtable
Hashtable是屬於JDK1.1的第一批集合框架其中之一，其他的還有Vector、Stack等。這些集合框架由於設計上的缺陷，導致了效能的瓶頸，在jdk1.2之後就被新的一套集合框架取代，也就是HashMap、ArrayList這些。HashMap在jdk1.8之後進行了全面的優化，而Hashtable依舊保持著舊版本的設計，在很多方面都落後於HashMap。下面主要分析Hashtable在：介面繼承、雜湊函式、雜湊衝突、擴容方案、執行緒安全等方面解析他們的不同。
介面繼承
Hashtable繼承自Dictionary類而不是AbstractMap，類圖如下（jdk1.8）
Hashtable誕生的時間是比Map早，但為了相容新的集合在jdk1.2之後也繼承了Map介面。Dictionary在目前已經完全被Map取代了，所以更加建議使用繼承自AbstractMap的HashMap。為了相容新版本介面還有Hashtable的迭代器：Enumerator。他的介面繼承結構如下：
他不僅實現了舊版的Enumeration介面，同時也實現了Iteractor介面，相容了新的api與使用習慣。這裡關於Hashtable還有一個問題：Hashtable是fast-fail的嗎
fast-fail指的是在使用迭代器遍歷集合過程中，如果集合發生了結構性改變，如新增資料、擴容、刪除資料等，迭代器會丟擲異常。Enumerator本身的實現是沒有fast-fail設計的，但他繼承了Iteractor介面之後，就有了fast-fail。看一下原始碼：
public T next() {
// 這裡在Enumerator的基礎上，增加了fast-fail
if (Hashtable.this.modCount != expectedModCount)
throw new ConcurrentModificationException();
// nextElement()是Enumeration的介面方法
return nextElement();
}
private void addEntry(int hash, K key, V value, int index) {
...
// 在新增資料之後，會改變modCount的值
modCount++;
}
所以，Hashtable本身的設計是有fastfail的，但如果使用的Enumerator，則享受不到這個設計了。
雜湊演算法
Hashtable的雜湊演算法非常簡單粗暴，如下程式碼
hash = key.hashCode();
index = (hash & 0x7FFFFFFF) % tab.length;
獲取key的hashcode，通過直接對陣列長度求餘來獲取下標。這裡還有一步是hash & 0x7FFFFFFF，目的是把最高位變成0，把hashcode變成一個非負數。為了使得hash可以分佈更加均勻，Hashtable預設控制陣列的長度為一個素數：初始值為11，每次擴容為原來的兩倍+1 。
衝突解決
Hashtable使用的是連結串列法，也稱為拉鍊法。發生衝突之後會轉換為連結串列。HashMap在jdk1.8之後增加了紅黑樹，所以在劇烈衝突的情況下，Hashtable的效能下降會比HashMap明顯非常多。
Hashtable的裝載因子與HashMap一致，預設都是0.75，且建議非特殊情況不要進行修改。
擴容方案
Hashtable的擴容方案也非常簡單粗暴，新建一個長度為原來的兩倍+1長度的陣列，遍歷所有的舊陣列的資料，重新hash插入新的陣列。他的原始碼非常簡單，有興趣可以看一下：
protected void rehash() {
int oldCapacity = table.length;
Entry<?,?>[] oldMap = table;
// 設定陣列長度為原來的2倍+1
int newCapacity = (oldCapacity << 1) + 1;
if (newCapacity - MAX_ARRAY_SIZE > 0) {
if (oldCapacity == MAX_ARRAY_SIZE)
// 如果長度達到最大值，則直接返回
return;
// 超過最大值設定長度為最大
newCapacity = MAX_ARRAY_SIZE;
}
// 新建陣列
Entry<?,?>[] newMap = new Entry<?,?>[newCapacity];
// modcount++，表示發生結構性改變
modCount++;
// 初始化裝載因子，改變table引用
threshold = (int)Math.min(newCapacity * loadFactor, MAX_ARRAY_SIZE + 1);
table = newMap;
// 遍歷所有的資料，重新hash後插入新的陣列，這裡使用的是頭插法
for (int i = oldCapacity ; i-- > 0 ;) {
for (Entry<K,V> old = (Entry<K,V>)oldMap[i] ; old != null ; ) {
Entry<K,V> e = old;
old = old.next;
int index = (e.hash & 0x7FFFFFFF) % newCapacity;
e.next = (Entry<K,V>)newMap[index];
newMap[index] = e;
}
}
}
執行緒安全
Hashtable和HashMap最大的不同就是執行緒安全了。jdk1.1的第一批集合框架都被設計為執行緒安全，但手段都非常粗暴：直接給所有方法上鎖 。但我們知道，鎖是一個非常重量級的操作，會嚴重影響效能。Hashtable直接對整個物件上鎖的缺點有：
- 同一時間只能有一個執行緒在讀或者寫，併發效率極低
- 頻繁上鎖進行系統呼叫，嚴重影響效能
所以雖然Hashtable實現了一定程度上的執行緒安全，但是卻付出了非常大的效能代價。這也是為什麼在jdk1.2他們馬上就被淘汰了。
不允許空鍵值
允許空鍵值這個設計有利也有弊，在ConcurrentHashMap中也禁止插入空鍵值，但HashMap是允許的。允許value空值會導致get方法返回null時有兩種情況：
- 找不到對應的key
- 找到了但是value為null；
當get方法返回null時無法判斷是哪種情況，在併發環境下containsKey方法已不再可靠，需要返回null來表示查詢不到資料。允許key空值需要額外的邏輯處理，佔用了陣列空間，且並沒有多大的實用價值。HashMap支援鍵和值為null，但基於以上原因，ConcurrentHashMap是不支援空鍵值。
小結
總體來說，Hashtable屬於舊版本的集合框架，他的設計已經落後了，官方更加推薦使用HashMap；而Hashtable執行緒安全的特性的同時，也帶來了極大的效能代價，更加推薦使用ConcurrentHashMap來代替Hashtable。
SynchronizeMap
SynchronizeMap這個集合類可能並不太熟悉，他是Collections.synchronizeMap()方法返回的物件，如下：
public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {
return new SynchronizedMap<>(m);
}
SynchronizeMap的作用是保證了執行緒安全，但是他的方法和Hashtable一致，也是簡單粗暴，直接加鎖，如下圖：
這裡的mutex是什麼呢？直接看到構造器：
final Object mutex; // Object on which to synchronize
SynchronizedMap(Map<K,V> m) {
this.m = Objects.requireNonNull(m);
// 預設為本物件
mutex = this;
}
SynchronizedMap(Map<K,V> m, Object mutex) {
this.m = m;
this.mutex = mutex;
}
可以看到預設鎖的就是物件本身，效果和Hashtable其實是一樣的。所以，一般情況下也是不推薦使用這個方法來保證執行緒安全。
ConcurrentHashMap
前面講到的兩個執行緒安全的Map集合框架，由於效能低下而不被推薦使用。ConcurrentHashMap就是來解決這個問題的。關於ConcurrentHashMap的詳細內容，在深入解析ConcurrentHashMap：感受併發程式設計智慧 一文中已經有了具體的介紹，這裡簡單介紹一下ConcurrentHashMap的思路。
ConcurrentHashMap並不是和Hashtable一樣採用直接對整個陣列進行上鎖，而是對陣列上的一個節點上鎖，這樣如果併發訪問的不是同個節點，那麼就無需等待釋放鎖。如下圖：
不同執行緒之間的訪問不同的節點不互相干擾，提高了併發訪問的效能。ConcurrentHashMap讀取內容是不需要加鎖的，所以實現了可以邊寫邊讀，多執行緒共讀，提高了效能。
這是jdk1.8優化之後的設計結構，jdk1.7之前是分為多個小陣列，鎖的粒度比Hashtable稍小了一些。如下：
鎖的是Segment，每個Segment對應一個數組。而jdk1.8之後鎖的粒度進一步降低，效能也進一步提高了。
LinkedHashMap
HashMap是無法記住插入順序的，在一些需要記住插入順序的場景下，HashMap就顯得無能為力，所以LinkHashMap就應運而生。LinkedHashMap內部新建一個內部節點類LinkedHashMapEntry繼承自HashMap的Node，增加了前後指標。每個插入的節點，都會使用前後指標聯絡起來，形成一個連結串列，這樣就可以記住插入的順序，如下圖：
圖中的紅色線表示雙向連結串列的引用。遍歷時從head出發可以按照插入順序遍歷所有節點。
LinkedHashMap繼承於HashMap，完全是基於HashMap進行改造的，在HashMap中就能看到LinkedMap的身影，如下：
HashMap.java
// Callbacks to allow LinkedHashMap post-actions
void afterNodeAccess(Node<K,V> p) { }
void afterNodeInsertion(boolean evict) { }
void afterNodeRemoval(Node<K,V> p) { }
HashMap本身已經預留了介面給LinkedHashMap重寫。LinkedHashMap本身的put、remove、get等等方法都是直接使用HashMap的方法。
LinkedHashMap的好處就是記住Node的插入順序，當使用Iteractor遍歷LinkedHashMap時，會按照Node的插入順序遍歷，HashMap則是按照陣列的前後順序進行遍歷。
TreeMap
有沒有發現前面兩個集合框架的命名都是 xxHashMap，而TreeMap並不是，原因就在於TreeMap並不是散列表，只是實現了散列表的功能。
HashMap的key排列是無序的，hash函式把每個key都隨機雜湊到陣列中，而如果想要保持key有序，則可以使用TreeMap。TreeMap的繼承結構如下：
他繼承自Map體系，實現了Map的介面，同時還實現了NavigationMap介面，該介面拓展了非常多的方便查詢key的介面，如最大的key、最小的key等。
TreeMap雖然擁有對映表的功能，但是他底層並不是一個對映表，而是一個紅黑樹。他可以將key進行排序，但同時也失去了HashMap在常數時間複雜度下找到資料的優點，平均時間複雜度是O(logN）。所以若不是有排序的需求，常規情況下還是使用HashMap。
需要注意的是，TreeMap中的元素必須實現Comparable介面或者在TreeMap的建構函式中傳入一個Comparator物件，他們之間才可以進行比較大小。
TreeMap本身的使用和特性是比較簡單的，核心的重點在於他的底層資料結構：紅黑樹。這是一個比較複雜的資料結構，限於篇幅，筆者會在另外的文章中詳解紅黑樹。
最後
文章詳解了Hashtable這個舊版的集合框架，同時簡單介紹了SynchronizeMap、ConcurrentHashMap、LinkedHashMap、TreeMap。這個類都在HashMap的基礎功能上，拓展了一些新的特性，同時也帶來一些效能上的代價。HashMap並沒有稱為功能的集大成者，而是把具體的特性分發到其他的Map實現類中，這樣做得好處是，我們不需要在單執行緒的環境下卻要付出執行緒安全的代價。所以瞭解這些相關Map實現類的特性以及付出的效能代價，則是我們學習的重點。
希望文章對你有幫助~
全文到此，原創不易，覺得有幫助可以點贊收藏評論關注轉發。
筆者才疏學淺，有任何想法歡迎評論區交流指正。
如需轉載請評論區或私信交流。另外歡迎光臨筆者的個人部落格：傳送門