一、個人學習后的見解：
首先表明學習源碼后的個人見解，后續一次依次進行分析：
1、線程安全：HashMap是非線程安全的，HashTable是線程安全的（HashTable中使用了synchronized關鍵字進行控制），HashMap對應的線程安全的有concurrentHashMap，但如果不用concurrentHashMap的話，也可以只用Collections.synchronizedMap（Map）進行轉換。
2、key值為null時的不同處理方式：HashMap允許key值為null，並會把key值為null放在Entry數組中的第一個bucket中；HashTable不允許存放key為null的存放，如果為null會拋出異常。
3、數據結構：HashMap和HashTable都使用哈希表來存儲鍵值對。后邊具體分析。
4、算法：其一、HashMap中對於key值的定位有內部封裝的hash算法，而HashTable中是直接使用.hashcode獲取hash值；其二、關於兩者容量大小的定義也決定了兩者在算法方面的不同效果。
5、效率問題：單線程情況下_耗時：HashMap.put > HashTable.put；HashMap.get < HashTable.get
6、根據HashTable注釋表名其相當於被棄用了。
二、對上面簡介的分析：
1、第一點不用解釋了，源碼中直接體現出來了，想了解者可觀看源碼。
2、如圖為HashMap的源碼部分
對於HashMap的key為null時會調用putForNullKey方法（想了解者可查看源碼）進行處理，將value值放入Entry數組的第一個bucket中。
下圖為HashTable的源碼部分
我們可以明確的看到，HashTable的put方法如果key值為null時，會拋出NullPointerException空指針異常。
從源碼出我們可以看出來對於兩者對null的不同待遇只是因為代碼處理不同，並沒有對效率或者其他有影響。
3、數據結構：
HashMap和HashTable都使用哈希表來存儲鍵值對。在數據結構上是基本相同的，都創建了一個繼承自Map.Entry的私有的內部類Entry，每一個Entry對象表示存儲在哈希表中的一個鍵值對。
Entry對象唯一表示一個鍵值對，有四個屬性：
-K key 鍵對象
-V value 值對象
-int hash 鍵對象的hash值
-Entry entry 指向鏈表中下一個Entry對象，可為null，表示當前Entry對象在鏈表尾部
可以說，有多少個鍵值對，就有多少個Entry對象，那么在HashMap和HashTable中是怎么存儲這些Entry對象，以方便我們快速查找和修改的呢？請看下圖。
上圖畫出的是一個桶數量為8，存有5個鍵值對的HashMap/HashTable的內存布局情況。可以看到HashMap/HashTable內部創建有一個Entry類型的引用數組，用來表示哈希表，數組的長度，即是哈希桶的數量。而數組的每一個元素都是一個Entry引用，從Entry對象的屬性里，也可以看出其是鏈表的節點，每一個Entry對象內部又含有另一個Entry對象的引用。
這樣就可以得出結論，HashMap/HashTable內部用Entry數組實現哈希表，而對於映射到同一個哈希桶（數組的同一個位置）的鍵值對，使用Entry鏈表來存儲(解決hash沖突)。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
以下代碼及注釋來自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、算法
第3點已經說了用來表示哈希表的內部數據結構。HashMap/HashTable還需要有算法來將給定的鍵key，映射到確定的hash桶（數組位置）。需要有算法在哈希桶內的鍵值對多到一定程度時，擴充哈希表的大小（數組的大小）。本小節比較這兩個類在算法層面有哪些不同。
初始容量大小和每次擴充容量大小的不同。先看代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
以下代碼及注釋來自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數組位置）中的。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
以下代碼及注釋來自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、關於效率問題：
結論已經在文章開始時表名了，此處博主水准較低，並不是很能確認是因為以下幾點導致：
HashMap.put > HashTable.put：
參照數據結構介紹，hasmMap的容量永遠為2^*,所以HashMap在計算key所在位置時是采用了以為進行處理的；但此處會導致相同的hashcode變多，每個bucket(entry)的深度增加，所以后續put耗時較長。
HashMap.get < HashTable.get:
由於HashTable.get也做了同步處理，在這里對於鎖的處理時間時HashTable的耗時過長（對於我自己不是很有說服力，因為在put時也有鎖機制處理）
6、HashTable已經配淘汰：
如圖為Hashtable（jdk1.7版本）的注釋，已經很明確的表名了如果是單線程情況下建議使用HashMap，如果是多線程的情況下建議使用ConcurrentHashMap，此處可表明HashTable自己都不建議使用自己。
關於第五點的具體原因希望有感興趣的或者大牛幫忙解答下~~