Java 8 中 HashMap 的性能提升

HashMap是一個高效通用的數據結構，它在每一個Java程序中都隨處可見。先來介紹些基礎知識。你可能也知 道，HashMap使用key的hashCode()和equals()方法來將值划分到不同的桶里。桶的數量通常要比map中的記錄的數量要稍大，這樣 每個桶包括的值會比較少（最好是一個）。當通過key進行查找時，我們可以在常數時間內迅速定位到某個桶（使用hashCode()對桶的數量進行取模） 以及要找的對象。

這些東西你應該都已經知道了。你可能還知道哈希碰撞會對hashMap的性能帶來災難性的影響。如果多個hashCode()的值落到同一個桶內的 時候，這些值是存儲到一個鏈表中的。最壞的情況下，所有的key都映射到同一個桶中，這樣hashmap就退化成了一個鏈表——查找時間從O(1)到 O(n)。我們先來測試下正常情況下hashmap在Java 7和Java 8中的表現。為了能完成控制hashCode()方法的行為，我們定義了如下的一個Key類：

01	class Key implements Comparable<Key> {

02	private final int value;

03	Key(int value) {

04	this.value = value;

05

}

06

@Override

07	public int compareTo(Key o) {

08	return Integer.compare(this.value, o.value);

09

}

10

@Override

11	public boolean equals(Object o) {

12	if (this == o) return true;

13	if (o == null || getClass() != o.getClass())

14	return false;

15	Key key = (Key) o;

16	return value == key.value;

17

}

18

@Override

19	public int hashCode() {

20	return value;

21

}

22

}

Key類的實現中規中矩：它重寫了equals()方法並且提供了一個還算過得去的hashCode()方法。為了避免過度的GC，我將不可變的Key對象緩存了起來，而不是每次都重新開始創建一遍：

01	class Key implements Comparable<Key> {

02	public class Keys {

03	public static final int MAX_KEY = 10_000_000;

04	private static final Key[] KEYS_CACHE = new Key[MAX_KEY];

05

static {

06	for (int i = 0; i < MAX_KEY; ++i) {

07	KEYS_CACHE[i] = new Key(i);

08

}

09

}

10	public static Key of(int value) {

11	return KEYS_CACHE[value];

12

}

13

}

現在我們可以開始進行測試了。我們的基准測試使用連續的Key值來創建了不同的大小的HashMap（10的乘方，從1到1百萬）。在測試中我們還會使用key來進行查找，並測量不同大小的HashMap所花費的時間：

01	import com.google.caliper.Param;

02	import com.google.caliper.Runner;

03	import com.google.caliper.SimpleBenchmark;

04	public class MapBenchmark extends SimpleBenchmark {

05	private HashMap<Key, Integer> map;

06

@Param

07	private int mapSize;

08

@Override

09	protected void setUp() throws Exception {

10	map = new HashMap<>(mapSize);

11	for (int i = 0; i < mapSize; ++i) {

12	map.put(Keys.of(i), i);

13

}

14

}

15	public void timeMapGet(int reps) {

16	for (int i = 0; i < reps; i++) {

17	map.get(Keys.of(i % mapSize));

18

}

19

}

20

}

有意思的是這個簡單的HashMap.get()里面，Java 8比Java 7要快20%。整體的性能也相當不錯：盡管HashMap里有一百萬條記錄，單個查詢也只花了不到10納秒，也就是大概我機器上的大概20個CPU周期。 相當令人震撼！不過這並不是我們想要測量的目標。

假設有一個很差勁的key，他總是返回同一個值。這是最糟糕的場景了，這種情況完全就不應該使用HashMap:

1	class Key implements Comparable<Key> {

2

//...

3

@Override

4	public int hashCode() {

5

return 0;

6

}

7

}

Java 7的結果是預料中的。隨着HashMap的大小的增長，get()方法的開銷也越來越大。由於所有的記錄都在同一個桶里的超長鏈表內，平均查詢一條記錄就需要遍歷一半的列表。因此從圖上可以看到，它的時間復雜度是O(n)。

不過Java 8的表現要好許多！它是一個log的曲線，因此它的性能要好上好幾個數量級。盡管有嚴重的哈希碰撞，已是最壞的情況了，但這個同樣的基准測試在JDK8中的時間復雜度是O(logn)。單獨來看JDK 8的曲線的話會更清楚，這是一個對數線性分布：

為什么會有這么大的性能提升，盡管這里用的是大O符號（大O描述的是漸近上界）？其實這個優化在JEP-180中已經提到了。如果某個桶中的記錄過 大的話（當前是TREEIFY_THRESHOLD = 8），HashMap會動態的使用一個專門的treemap實現來替換掉它。這樣做的結果會更好，是O(logn)，而不是糟糕的O(n)。它是如何工作 的？前面產生沖突的那些KEY對應的記錄只是簡單的追加到一個鏈表后面，這些記錄只能通過遍歷來進行查找。但是超過這個閾值后HashMap開始將列表升 級成一個二叉樹，使用哈希值作為樹的分支變量，如果兩個哈希值不等，但指向同一個桶的話，較大的那個會插入到右子樹里。如果哈希值相等，HashMap希 望key值最好是實現了Comparable接口的，這樣它可以按照順序來進行插入。這對HashMap的key來說並不是必須的，不過如果實現了當然最 好。如果沒有實現這個接口，在出現嚴重的哈希碰撞的時候，你就並別指望能獲得性能提升了。

這個性能提升有什么用處？比方說惡意的程序，如果它知道我們用的是哈希算法，它可能會發送大量的請求，導致產生嚴重的哈希碰撞。然后不停的訪問這些 key就能顯著的影響服務器的性能，這樣就形成了一次拒絕服務攻擊（DoS）。JDK 8中從O(n)到O(logn)的飛躍，可以有效地防止類似的攻擊，同時也讓HashMap性能的可預測性稍微增強了一些。我希望這個提升能最終說服你的 老大同意升級到JDK 8來。

測試使用的環境是：Intel Core i7-3635QM @ 2.4 GHz，8GB內存，SSD硬盤，使用默認的JVM參數，運行在64位的Windows 8.1系統 上。