HashMap和HashTable到底哪不一樣？

HashMap和HashTable有什麼不一樣？在面試和被面試的過程當中，我問過也被問過這個問題，也見過了很多回答，今天決定寫一寫本身心目中的理想答案。

代碼版本

JDK每一版本都在改進。本文討論的HashMap和HashTable基於JDK 1.7.0_67。源碼見這裏

1. 時間

HashTable產生於JDK 1.1，而HashMap產生於JDK 1.2。從時間的維度上來看，HashMap要比HashTable出現得晚一些。

2. 做者

如下是HashTable的做者：

如下代碼及註釋來自java.util.HashTable

* @author  Arthur van Hoff
* @author  Josh Bloch
* @author  Neal Gafter

如下是HashMap的做者：

如下代碼及註釋來自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都是基於哈希表來實現鍵值映射的工具類。討論他們的不一樣，咱們首先來看一下他們暴露在外的API有什麼不一樣。

3.1 Public Method

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

從圖中能夠看出，兩個類的繼承體系有些不一樣。雖然都實現了Map、Cloneable、Serializable三個接口。可是HashMap繼承自抽象類AbstractMap，而HashTable繼承自抽象類Dictionary。其中Dictionary類是一個已經被廢棄的類，這一點咱們能夠從它代碼的註釋中看到：

如下代碼及註釋來自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，鑑於該類已經廢棄，因此這個方法也就沒什麼用處了。另外一個多出來的方法是contains，這個多出來的方法也沒什麼用，由於它跟containsValue方法功能是同樣的。代碼爲證：

如下代碼及註釋來自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);
 }

因此從公開的方法上來看，這兩個類提供的，是同樣的功能。都提供鍵值映射的服務，能夠增、刪、查、改鍵值對，能夠對建、值、鍵值對提供遍歷視圖。支持淺拷貝，支持序列化。

3.2 Null Key & Null Value

HashMap是支持null鍵和null值的，而HashTable在遇到null時，會拋出NullPointerException異常。這並非由於HashTable有什麼特殊的實現層面的緣由致使不能支持null鍵和null值，這僅僅是由於HashMap在實現時對null作了特殊處理，將null的hashCode值定爲了0，從而將其存放在哈希表的第0個bucket中。咱們一put方法爲例，看一看代碼的細節：

如下代碼及註釋來自java.util.HashTable

public synchronized V put(K key, V value) {

    // 若是value爲null，拋出NullPointerException
    if (value == null) {
        throw new NullPointerException();
    }

    // 若是key爲null，在調用key.hashCode()時拋出NullPointerException

    // ...
}


如下代碼及註釋來自java.util.HasMap

public V put(K key, V value) {
    if (table == EMPTY_TABLE) {
        inflateTable(threshold);
    }
    // 當key爲null時，調用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. 實現原理

本節討論HashMap和HashTable在數據結構和算法層面，有什麼不一樣。

4.1 數據結構

HashMap和HashTable都使用哈希表來存儲鍵值對。在數據結構上是基本相同的，都建立了一個繼承自Map.Entry的私有的內部類Entry，每個Entry對象表示存儲在哈希表中的一個鍵值對。

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

-K key 鍵對象
-V value 值對象
-int hash 鍵對象的hash值
-Entry<K, V> entry 指向鏈表中下一個Entry對象，可爲null，表示當前Entry對象在鏈表尾部

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

上圖畫出的是一個桶數量爲8，存有5個鍵值對的HashMap/HashTable的內存佈局狀況。能夠看到HashMap/HashTable內部建立有一個Entry類型的引用數組，用來表示哈希表，數組的長度，便是哈希桶的數量。而數組的每個元素都是一個Entry引用，從Entry對象的屬性裏，也能夠看出其是鏈表的節點，每個Entry對象內部又含有另外一個Entry對象的引用。

這樣就能夠得出結論，HashMap/HashTable內部用Entry數組實現哈希表，而對於映射到同一個哈希桶（數組的同一個位置）的鍵值對，使用Entry鏈表來存儲(解決hash衝突)。

如下代碼及註釋來自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;

從代碼能夠看到，對於哈希桶的內部表示，兩個類的實現是一致的。

4.2 算法

上一小節已經說了用來表示哈希表的內部數據結構。HashMap/HashTable還須要有算法來將給定的鍵key，映射到肯定的hash桶（數組位置）。須要有算法在哈希桶內的鍵值對多到必定程度時，擴充哈希表的大小（數組的大小）。本小節比較這兩個類在算法層面有哪些不一樣。

初始容量大小和每次擴充容量大小的不一樣。先看代碼：

如下代碼及註釋來自java.util.HashTable

// 哈希表默認初始大小爲11
public Hashtable() {
    this(11, 0.75f);
}

protected void rehash() {
    int oldCapacity = table.length;
    Entry<K,V>[] oldMap = table;

    // 每次擴容爲原來的2n+1
    int newCapacity = (oldCapacity << 1) + 1;
    // ...
}


如下代碼及註釋來自java.util.HashMap

// 哈希表默認初始大小爲2^4=16
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16

void addEntry(int hash, K key, V value, int bucketIndex) {
    // 每次擴充爲原來的2n 
    if ((size >= threshold) && (null != table[bucketIndex])) {
       resize(2 * table.length);
}

能夠看到HashTable默認的初始大小爲11，以後每次擴充爲原來的2n+1。HashMap默認的初始化大小爲16，以後每次擴充爲原來的2倍。還有我沒列出代碼的一點，就是若是在建立時給定了初始化大小，那麼HashTable會直接使用你給定的大小，而HashMap會將其擴充爲2的冪次方大小。

也就是說HashTable會盡可能使用素數、奇數。而HashMap則老是使用2的冪做爲哈希表的大小。咱們知道當哈希表的大小爲素數時，簡單的取模哈希的結果會更加均勻（具體證實，見這篇文章），因此單從這一點上看，HashTable的哈希表大小選擇，彷佛更高明些。但另外一方面咱們又知道，在取模計算時，若是模數是2的冪，那麼咱們能夠直接使用位運算來獲得結果，效率要大大高於作除法。因此從hash計算的效率上，又是HashMap更勝一籌。

因此，事實就是HashMap爲了加快hash的速度，將哈希表的大小固定爲了2的冪。固然這引入了哈希分佈不均勻的問題，因此HashMap爲解決這問題，又對hash算法作了一些改動。具體咱們來看看，在獲取了key對象的hashCode以後，HashTable和HashMap分別是怎樣將他們hash到肯定的哈希桶（Entry數組位置）中的。

如下代碼及註釋來自java.util.HashTable

// hash 不能超過Integer.MAX_VALUE 因此要取其最小的31個bit
int 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.HashMap
int hash = hash(key);
int i = indexFor(hash, table.length);

// 在計算了key.hashCode()以後，作了一些位運算來減小哈希衝突
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的冪次方，因此在取模運算時不須要作除法，只須要位的與運算就能夠了。可是因爲引入的hash衝突加重問題，HashMap在調用了對象的hashCode方法以後，又作了一些位運算在打散數據。關於這些位計算爲何能夠打散數據的問題，本文再也不展開了。感興趣的能夠看這裏。

若是你有細心讀代碼，還能夠發現一點，就是HashMap和HashTable在計算hash時都用到了一個叫hashSeed的變量。這是由於映射到同一個hash桶內的Entry對象，是以鏈表的形式存在的，而鏈表的查詢效率比較低，因此HashMap/HashTable的效率對哈希衝突很是敏感，因此能夠額外開啓一個可選hash（hashSeed），從而減小哈希衝突。由於這是兩個類相同的一點，因此本文再也不展開了，感興趣的看這裏。事實上，這個優化在JDK 1.8中已經去掉了，由於JDK 1.8中，映射到同一個哈希桶（數組位置）的Entry對象，使用了紅黑樹來存儲，從而大大加速了其查找效率。

5. 線程安全

咱們說HashTable是同步的，HashMap不是，也就是說HashTable在多線程使用的狀況下，不須要作額外的同步，而HashMap則不行。那麼HashTable是怎麼作到的呢？

如下代碼及註釋來自java.util.HashTable

public 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進行了同步包裝。

6. 代碼風格

從個人品位來看，HashMap的代碼要比HashTable整潔不少。下面這段HashTable的代碼，我就覺着有點混亂，不太能接受這種代碼複用的方式。

如下代碼及註釋來自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已經被淘汰了，不要在代碼中再使用它。

如下描述來自於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已經被淘汰了，不要在新的代碼中再使用它。

8. 持續優化

雖然HashMap和HashTable的公開接口應該不會改變，或者說改變不頻繁。但每一版本的JDK，都會對HashMap和HashTable的內部實現作優化，好比上文曾提到的JDK 1.8的紅黑樹優化。因此，儘量的使用新版本的JDK吧，除了那些炫酷的新功能，普通的API也會有性能上有提高。

爲何HashTable已經淘汰了，還要優化它？由於有老的代碼還在使用它，因此優化了它以後，這些老的代碼也能得到性能提高。

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