轉(zhuǎn)載自?HashMap 和 HashTable 到底哪不同 ？

代碼版本

JDK每一版本都在改進(jìn)。本文討論的HashMap和HashTable基于JDK 1.7.0_67。源碼見這里

1. 時間

HashTable產(chǎn)生于JDK 1.1，而HashMap產(chǎn)生于JDK 1.2。從時間的維度上來看，HashMap要比HashTable出現(xiàn)得晚一些。

2. 作者

以下是HashTable的作者：

12345

以下代碼及注釋來自java.util.HashTable* @author Arthur van Hoff* @author Josh Bloch* @author Neal Gafter

以下是HashMap的作者：

123456

以下代碼及注釋來自java.util.HashMap* @author Doug Lea* @author Josh Bloch* @author Arthur van Hoff* @author Neal Gafter

可以看到HashMap的作者多了大神Doug Lea。不了解Doug Lea的，可以看這里。

3. 對外的接口（API）

HashMap和HashTable都是基于哈希表來實現(xiàn)鍵值映射的工具類。討論他們的不同，我們首先來看一下他們暴露在外的API有什么不同。

3.1 Public Method

下面兩張圖，我畫出了HashMap和HashTable的類繼承體系，并列出了這兩個類的可供外部調(diào)用的公開方法。

從圖中可以看出，兩個類的繼承體系有些不同。雖然都實現(xiàn)了Map、Cloneable、Serializable三個接口。但是HashMap繼承自抽象類AbstractMap，而HashTable繼承自抽象類Dictionary。其中Dictionary類是一個已經(jīng)被廢棄的類，這一點我們可以從它代碼的注釋中看到：

1234	以下代碼及注釋來自java.util.Dictionary* <strong>NOTE: This class is obsolete. New implementations should* implement the Map interface, rather than extending this class.</strong>

同時我們看到HashTable比HashMap多了兩個公開方法。一個是elements，這來自于抽象類Dictionary，鑒于該類已經(jīng)廢棄，所以這個方法也就沒什么用處了。另一個多出來的方法是contains，這個多出來的方法也沒什么用，因為它跟containsValue方法功能是一樣的。代碼為證：

123456789101112131415161718192021

以下代碼及注釋來自java.util.HashTable?public synchronized boolean contains(Object value) {?????if (value == null) {?????????throw new NullPointerException();?????}?????Entry tab[] = table;?????for (int i = tab.length ; i-- > 0 ;) {?????????for (Entry<K,V> e = tab[i] ; e != null ; e = e.next) {?????????????if (e.value.equals(value)) {?????????????????return true;?????????????}?????????}?????}?????return false;?}?public boolean containsValue(Object value) {?????return contains(value);?}

所以從公開的方法上來看，這兩個類提供的，是一樣的功能。都提供鍵值映射的服務(wù)，可以增、刪、查、改鍵值對，可以對建、值、鍵值對提供遍歷視圖。支持淺拷貝，支持序列化。

3.2 Null Key & Null Value

HashMap是支持null鍵和null值的，而HashTable在遇到null時，會拋出NullPointerException異常。這并不是因為HashTable有什么特殊的實現(xiàn)層面的原因?qū)е虏荒苤С謓ull鍵和null值，這僅僅是因為HashMap在實現(xiàn)時對null做了特殊處理，將null的hashCode值定為了0，從而將其存放在哈希表的第0個bucket中。我們一put方法為例，看一看代碼的細(xì)節(jié)：

1234567891011121314151617181920212223242526272829303132333435363738394041

以下代碼及注釋來自java.util.HashTablepublic synchronized V put(K key, V value) {????// 如果value為null，拋出NullPointerException????if (value == null) {????????throw new NullPointerException();????}????// 如果key為null，在調(diào)用key.hashCode()時拋出NullPointerException????// ...}以下代碼及注釋來自java.util.HasMappublic V put(K key, V value) {????if (table == EMPTY_TABLE) {????????inflateTable(threshold);????}????// 當(dāng)key為null時，調(diào)用putForNullKey特殊處理????if (key == null)????????return putForNullKey(value);????// ...}private V putForNullKey(V value) {????// key為null時，放到table[0]也就是第0個bucket中????for (Entry<K,V> e = table[0]; e != null; e = e.next) {????????if (e.key == null) {????????????V oldValue = e.value;????????????e.value = value;????????????e.recordAccess(this);????????????return oldValue;????????}????}????modCount++;????addEntry(0, null, value, 0);????return null;}

4. 實現(xiàn)原理

本節(jié)討論HashMap和HashTable在數(shù)據(jù)結(jié)構(gòu)和算法層面，有什么不同。

4.1 數(shù)據(jù)結(jié)構(gòu)

HashMap和HashTable都使用哈希表來存儲鍵值對。在數(shù)據(jù)結(jié)構(gòu)上是基本相同的，都創(chuàng)建了一個繼承自Map.Entry的私有的內(nèi)部類Entry，每一個Entry對象表示存儲在哈希表中的一個鍵值對。

Entry對象唯一表示一個鍵值對，有四個屬性：

-K key 鍵對象
-V value 值對象
-int hash 鍵對象的hash值
-Entry entry 指向鏈表中下一個Entry對象，可為null，表示當(dāng)前Entry對象在鏈表尾部

可以說，有多少個鍵值對，就有多少個Entry對象，那么在HashMap和HashTable中是怎么存儲這些Entry對象，以方便我們快速查找和修改的呢？請看下圖。

上圖畫出的是一個桶數(shù)量為8，存有5個鍵值對的HashMap/HashTable的內(nèi)存布局情況。可以看到HashMap/HashTable內(nèi)部創(chuàng)建有一個Entry類型的引用數(shù)組，用來表示哈希表，數(shù)組的長度，即是哈希桶的數(shù)量。而數(shù)組的每一個元素都是一個Entry引用，從Entry對象的屬性里，也可以看出其是鏈表的節(jié)點，每一個Entry對象內(nèi)部又含有另一個Entry對象的引用。

這樣就可以得出結(jié)論，HashMap/HashTable內(nèi)部用Entry數(shù)組實現(xiàn)哈希表，而對于映射到同一個哈希桶（數(shù)組的同一個位置）的鍵值對，使用Entry鏈表來存儲(解決hash沖突)。

1234567891011121314

以下代碼及注釋來自java.util.HashTable/**?* The hash table data.?*/private transient Entry<K,V>[] table;以下代碼及注釋來自java.util.HashMap/**?* The table, resized as necessary. Length MUST Always be a power of two.?*/transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;

從代碼可以看到，對于哈希桶的內(nèi)部表示，兩個類的實現(xiàn)是一致的。

4.2 算法

上一小節(jié)已經(jīng)說了用來表示哈希表的內(nèi)部數(shù)據(jù)結(jié)構(gòu)。HashMap/HashTable還需要有算法來將給定的鍵key，映射到確定的hash桶（數(shù)組位置）。需要有算法在哈希桶內(nèi)的鍵值對多到一定程度時，擴(kuò)充哈希表的大小（數(shù)組的大小）。本小節(jié)比較這兩個類在算法層面有哪些不同。

初始容量大小和每次擴(kuò)充容量大小的不同。先看代碼：

123456789101112131415161718192021222324252627

以下代碼及注釋來自java.util.HashTable// 哈希表默認(rèn)初始大小為11public Hashtable() {????this(11, 0.75f);}protected void rehash() {????int oldCapacity = table.length;????Entry<K,V>[] oldMap = table;????// 每次擴(kuò)容為原來的2n+1????int newCapacity = (oldCapacity << 1) + 1;????// ...}以下代碼及注釋來自java.util.HashMap// 哈希表默認(rèn)初始大小為2^4=16static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16void addEntry(int hash, K key, V value, int bucketIndex) {????// 每次擴(kuò)充為原來的2n ????if ((size >= threshold) && (null != table[bucketIndex])) {???????resize(2 * table.length);}

可以看到HashTable默認(rèn)的初始大小為11，之后每次擴(kuò)充為原來的2n+1。HashMap默認(rèn)的初始化大小為16，之后每次擴(kuò)充為原來的2倍。還有我沒列出代碼的一點，就是如果在創(chuàng)建時給定了初始化大小，那么HashTable會直接使用你給定的大小，而HashMap會將其擴(kuò)充為2的冪次方大小。

也就是說HashTable會盡量使用素數(shù)、奇數(shù)。而HashMap則總是使用2的冪作為哈希表的大小。我們知道當(dāng)哈希表的大小為素數(shù)時，簡單的取模哈希的結(jié)果會更加均勻（具體證明，見這篇文章），所以單從這一點上看，HashTable的哈希表大小選擇，似乎更高明些。但另一方面我們又知道，在取模計算時，如果模數(shù)是2的冪，那么我們可以直接使用位運(yùn)算來得到結(jié)果，效率要大大高于做除法。所以從hash計算的效率上，又是HashMap更勝一籌。

所以，事實就是HashMap為了加快hash的速度，將哈希表的大小固定為了2的冪。當(dāng)然這引入了哈希分布不均勻的問題，所以HashMap為解決這問題，又對hash算法做了一些改動。具體我們來看看，在獲取了key對象的hashCode之后，HashTable和HashMap分別是怎樣將他們hash到確定的哈希桶（Entry數(shù)組位置）中的。

1234567891011121314151617181920212223242526272829303132333435363738

以下代碼及注釋來自java.util.HashTable// hash 不能超過Integer.MAX_VALUE 所以要取其最小的31個bitint hash = hash(key);int index = (hash & 0x7FFFFFFF) % tab.length;// 直接計算key.hashCode()private int hash(Object k) {????// hashSeed will be zero if alternative hashing is disabled.????return hashSeed ^ k.hashCode();}以下代碼及注釋來自java.util.HashMapint hash = hash(key);int i = indexFor(hash, table.length);// 在計算了key.hashCode()之后，做了一些位運(yùn)算來減少哈希沖突final int hash(Object k) {????int h = hashSeed;????if (0 != h && k instanceof String) {????????return sun.misc.Hashing.stringHash32((String) k);????}????h ^= k.hashCode();????// This function ensures that hashCodes that differ only by????// constant multiples at each bit position have a bounded????// number of collisions (approximately 8 at default load factor).????h ^= (h >>> 20) ^ (h >>> 12);????return h ^ (h >>> 7) ^ (h >>> 4);}// 取模不再需要做除法static int indexFor(int h, int length) {????// assert Integer.bitCount(length) == 1 : "length must be a non-zero power of 2";????return h & (length-1);}

正如我們所言，HashMap由于使用了2的冪次方，所以在取模運(yùn)算時不需要做除法，只需要位的與運(yùn)算就可以了。但是由于引入的hash沖突加劇問題，HashMap在調(diào)用了對象的hashCode方法之后，又做了一些位運(yùn)算在打散數(shù)據(jù)。關(guān)于這些位計算為什么可以打散數(shù)據(jù)的問題，本文不再展開了。感興趣的可以看這里。

如果你有細(xì)心讀代碼，還可以發(fā)現(xiàn)一點，就是HashMap和HashTable在計算hash時都用到了一個叫hashSeed的變量。這是因為映射到同一個hash桶內(nèi)的Entry對象，是以鏈表的形式存在的，而鏈表的查詢效率比較低，所以HashMap/HashTable的效率對哈希沖突非常敏感，所以可以額外開啟一個可選hash（hashSeed），從而減少哈希沖突。因為這是兩個類相同的一點，所以本文不再展開了，感興趣的看這里。事實上，這個優(yōu)化在JDK 1.8中已經(jīng)去掉了，因為JDK 1.8中，映射到同一個哈希桶（數(shù)組位置）的Entry對象，使用了紅黑樹來存儲，從而大大加速了其查找效率。

5. 線程安全

我們說HashTable是同步的，HashMap不是，也就是說HashTable在多線程使用的情況下，不需要做額外的同步，而HashMap則不行。那么HashTable是怎么做到的呢？

12345678910111213141516171819

以下代碼及注釋來自java.util.HashTablepublic synchronized V get(Object key) {????Entry tab[] = table;????int hash = hash(key);????int index = (hash & 0x7FFFFFFF) % tab.length;????for (Entry<K,V> e = tab[index] ; e != null ; e = e.next) {????????if ((e.hash == hash) && e.key.equals(key)) {????????????return e.value;????????}????}????return null;}public Set<K> keySet() {????if (keySet == null)????????keySet = Collections.synchronizedSet(new KeySet(), this);????return keySet;}

可以看到，也比較簡單，就是公開的方法比如get都使用了synchronized描述符。而遍歷視圖比如keySet都使用了Collections.synchronizedXXX進(jìn)行了同步包裝。

6. 代碼風(fēng)格

從我的品位來看，HashMap的代碼要比HashTable整潔很多。下面這段HashTable的代碼，我就覺著有點混亂，不太能接受這種代碼復(fù)用的方式。

12345678910111213141516171819202122232425262728293031323334353637

以下代碼及注釋來自java.util.HashTable/**?* A hashtable enumerator class.? This class implements both the?* Enumeration and Iterator interfaces, but individual instances?* can be created with the Iterator methods disabled.? This is necessary?* to avoid unintentionally increasing the capabilities granted a user?* by passing an Enumeration.?*/private class Enumerator<T> implements Enumeration<T>, Iterator<T> {????Entry[] table = Hashtable.this.table;????int index = table.length;????Entry<K,V> entry = null;????Entry<K,V> lastReturned = null;????int type;????/**?????* Indicates whether this Enumerator is serving as an Iterator?????* or an Enumeration.? (true -> Iterator).?????*/????boolean iterator;????/**?????* The modCount value that the iterator believes that the backing?????* Hashtable should have.? If this expectation is violated, the iterator?????* has detected concurrent modification.?????*/????protected int expectedModCount = modCount;????Enumerator(int type, boolean iterator) {????????this.type = type;????????this.iterator = iterator;????}?????????//...}

7. HashTable已經(jīng)被淘汰了，不要在代碼中再使用它。

以下描述來自于HashTable的類注釋：

If a thread-safe implementation is not needed, it is recommended to use HashMap in place of Hashtable. If a thread-safe highly-concurrent implementation is desired, then it is recommended to use java.util.concurrent.ConcurrentHashMap in place of Hashtable.

簡單來說就是，如果你不需要線程安全，那么使用HashMap，如果需要線程安全，那么使用ConcurrentHashMap。HashTable已經(jīng)被淘汰了，不要在新的代碼中再使用它。

8. 持續(xù)優(yōu)化

雖然HashMap和HashTable的公開接口應(yīng)該不會改變，或者說改變不頻繁。但每一版本的JDK，都會對HashMap和HashTable的內(nèi)部實現(xiàn)做優(yōu)化，比如上文曾提到的JDK 1.8的紅黑樹優(yōu)化。所以，盡可能的使用新版本的JDK吧，除了那些炫酷的新功能，普通的API也會有性能上有提升。

為什么HashTable已經(jīng)淘汰了，還要優(yōu)化它？因為有老的代碼還在使用它，所以優(yōu)化了它之后，這些老的代碼也能獲得性能提升。

Reference

• https://github.com/ZhaoX/jdk-1.7-annotated/blob/master/src/java/util/HashMap.java
• https://github.com/ZhaoX/jdk-1.7-annotated/blob/master/src/java/util/Hashtable.java

總結(jié)

以上是生活随笔為你收集整理的HashMap 和 HashTable 到底哪不同 ？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。