HashMap<K, V>是每個(gè)Java程序中快速，通用且無處不在的數(shù)據(jù)結(jié)構(gòu)。 首先是一些基礎(chǔ)知識(shí)。 您可能知道，它使用鍵的hashCode()和equals()方法在存儲(chǔ)桶之間拆分值。 存儲(chǔ)桶（箱）的數(shù)量應(yīng)略高于映射中的條目數(shù)，以便每個(gè)存儲(chǔ)桶僅保留很少（最好是一個(gè)）值。 當(dāng)按鍵查找時(shí)，我們很快確定了存儲(chǔ)桶（使用hashCode()模數(shù)number_of_buckets模），并且我們的商品在固定時(shí)間可用。

這應(yīng)該已經(jīng)為您所了解。 您可能還知道，哈希沖突對(duì)HashMap性能具有災(zāi)難性的影響。 當(dāng)多個(gè)hashCode()值最終出現(xiàn)在同一存儲(chǔ)桶中時(shí)，這些值將放置在臨時(shí)鏈接列表中。 在最壞的情況下，當(dāng)所有鍵都映射到同一存儲(chǔ)桶時(shí)，會(huì)將哈希映射退化為鏈表–從O（1）到O（n）查找時(shí)間。 讓我們首先對(duì)HashMap在Java 7（1.7.0_40）和Java 8（1.8.0-b132）中的正常情況下的行為進(jìn)行基準(zhǔn)測(cè)試。 為了完全控制hashCode()行為，我們定義了自定義Key類：

class Key implements Comparable<Key> {private final int value;Key(int value) {this.value = value;}@Overridepublic int compareTo(Key o) {return Integer.compare(this.value, o.value);}@Overridepublic boolean equals(Object o) {if (this == o) return true;if (o == null || getClass() != o.getClass())return false;Key key = (Key) o;return value == key.value;}@Overridepublic int hashCode() {return value;} }

Key類行為良好：它覆蓋equals()并提供了體面的hashCode() 。 為了避免過多的GC，我緩存了不可變的Key實(shí)例，而不是一遍又一遍地創(chuàng)建它們：

public class Keys {public static final int MAX_KEY = 10_000_000;private static final Key[] KEYS_CACHE = new Key[MAX_KEY];static {for (int i = 0; i < MAX_KEY; ++i) {KEYS_CACHE[i] = new Key(i);}}public static Key of(int value) {return KEYS_CACHE[value];}}

現(xiàn)在我們準(zhǔn)備進(jìn)行一些實(shí)驗(yàn)。 我們的基準(zhǔn)測(cè)試將使用連續(xù)鍵空間簡(jiǎn)單地創(chuàng)建不同大小（10的冪，從1到1百萬）的HashMap 。 在基準(zhǔn)測(cè)試本身中，我們將根據(jù)鍵查找值并測(cè)量所需的時(shí)間，具體取決于HashMap大小：

import com.google.caliper.Param; import com.google.caliper.Runner; import com.google.caliper.SimpleBenchmark;public class MapBenchmark extends SimpleBenchmark {private HashMap<Key, Integer> map;@Paramprivate int mapSize;@Overrideprotected void setUp() throws Exception {map = new HashMap<>(mapSize);for (int i = 0; i < mapSize; ++i) {map.put(Keys.of(i), i);}}public void timeMapGet(int reps) {for (int i = 0; i < reps; i++) {map.get(Keys.of(i % mapSize));}}}

結(jié)果確認(rèn)HashMap.get()確實(shí)是O（1）：

有趣的是，在簡(jiǎn)單的HashMap.get() Java 8平均比Java 7快20％。 整體性能同樣令人感興趣：即使在HashMap有100萬個(gè)條目，一次查找所用的時(shí)間也不到10納秒，這意味著我的機(jī)器上大約有20個(gè)CPU周期^* 。 令人印象深刻！ 但這不是我們要進(jìn)行基準(zhǔn)測(cè)試的結(jié)果。

假設(shè)我們有一個(gè)非常差的映射鍵，它總是返回相同的值。 這是最糟糕的情況，完全HashMap使用HashMap ：

class Key implements Comparable<Key> {//...@Overridepublic int hashCode() {return 0;} }

我使用了完全相同的基準(zhǔn)來查看它在各種地圖尺寸下的行為（注意這是對(duì)數(shù)對(duì)數(shù)比例）：

預(yù)計(jì)Java 7的結(jié)果。 HashMap.get()的成本與HashMap本身的大小成比例地增長(zhǎng)。 由于所有條目都在一個(gè)巨大的鏈接列表中的同一存儲(chǔ)桶中，因此查找一個(gè)條目平均需要遍歷該列表的一半（大小為n）。 因此，O（n）復(fù)雜度如圖所示。

但是Java 8的性能要好得多！ 這是一個(gè)對(duì)數(shù)標(biāo)度，因此我們實(shí)際上在談?wù)搸讉€(gè)數(shù)量級(jí)的更好。 在災(zāi)難性哈希沖突的情況下，在JDK 8上執(zhí)行的相同基準(zhǔn)會(huì)產(chǎn)生O（logn）最壞情況的性能，如將JDK 8單獨(dú)以對(duì)數(shù)線性比例可視化，則可以更好地看到：

即使使用big-O表示法，如此巨大的性能改進(jìn)背后的原因是什么？ 好，在JEP-180中描述了此優(yōu)化。 基本上，當(dāng)存儲(chǔ)桶過大時(shí)（當(dāng)前： TREEIFY_THRESHOLD = 8 ）， HashMap用樹形圖的臨時(shí)實(shí)現(xiàn)動(dòng)態(tài)替換它。 這樣一來，我們不必感到悲觀的O（n），而獲得更好的O（logn）。 它是如何工作的？ 好吧，以前具有沖突鍵的條目只是簡(jiǎn)單地附加到鏈表中，而后又需要遍歷。 現(xiàn)在， HashMap使用哈希碼作為分支變量，將列表提升為二叉樹。 如果兩個(gè)散列不同，但最終在同一個(gè)存儲(chǔ)桶中，則認(rèn)為一個(gè)散列較大并向右移動(dòng)。 如果哈希值相等（如本例所示），則HashMap希望鍵是Comparable ，以便它可以建立一些順序。 這不是HashMap密鑰的要求，但顯然是一種好習(xí)慣。 如果密鑰不具有可比性，那么在發(fā)生大量哈希沖突的情況下，不要指望任何性能提高。

為什么所有這些都那么重要？ 知道我們使用的哈希算法的惡意軟件可能會(huì)處理數(shù)千個(gè)請(qǐng)求，這些請(qǐng)求將導(dǎo)致大量的哈希沖突。 重復(fù)訪問此類密鑰將嚴(yán)重影響服務(wù)器性能，從而有效地導(dǎo)致拒絕服務(wù)攻擊。 在JDK 8中，從O（n）到O（logn）的驚人跳躍將阻止這種攻擊媒介，也使性能更具預(yù)測(cè)性。 我希望這將最終說服您的老板升級(jí)。

---

^*在Intel Core i7-3635QM @ 2.4 GHz，8 GiB RAM和SSD驅(qū)動(dòng)器上執(zhí)行的基準(zhǔn)，在64位Windows 8.1和默認(rèn)JVM設(shè)置上運(yùn)行。

翻譯自: https://www.javacodegeeks.com/2014/04/hashmap-performance-improvements-in-java-8.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的Java 8中的HashMap性能改进的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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