JDK 的代碼是開源的，我們打開idea開發(fā)工具，引入jdk1.8? 找到hashmap

HashMap 是基于 HashTable 的一種數(shù)據(jù)結(jié)構(gòu)，在普通哈希表的基礎(chǔ)上，它支持多線程操作以及空的 key 和 value。

在 HashMap 中定義了幾個常量:

static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16 static final int MAXIMUM_CAPACITY = 1 << 30; static final float DEFAULT_LOAD_FACTOR = 0.75f; static final int TREEIFY_THRESHOLD = 8; static final int UNTREEIFY_THRESHOLD = 6; static final int MIN_TREEIFY_CAPACITY = 64;

依次解釋以上常量:

DEFAULT_INITIAL_CAPACITY: 初始容量，也就是默認(rèn)會創(chuàng)建 16 個箱子，箱子的個數(shù)不能太多或太少。如果太少，很容易觸發(fā)擴(kuò)容，如果太多，遍歷哈希表會比較慢。

MAXIMUM_CAPACITY: 哈希表最大容量，一般情況下只要內(nèi)存夠用，哈希表不會出現(xiàn)問題。

DEFAULT_LOAD_FACTOR: 默認(rèn)的負(fù)載因子。因此初始情況下，當(dāng)鍵值對的數(shù)量大于?16 * 0.75 = 12?時，就會觸發(fā)擴(kuò)容。

TREEIFY_THRESHOLD: 上文說過，如果哈希函數(shù)不合理，即使擴(kuò)容也無法減少箱子中鏈表的長度，因此 Java 的處理方案是當(dāng)鏈表太長時，轉(zhuǎn)換成紅黑樹。這個值表示當(dāng)某個箱子中，鏈表長度大于 8 時，有可能會轉(zhuǎn)化成樹。

UNTREEIFY_THRESHOLD: 在哈希表擴(kuò)容時，如果發(fā)現(xiàn)鏈表長度小于 6，則會由樹重新退化為鏈表。

MIN_TREEIFY_CAPACITY: 在轉(zhuǎn)變成樹之前，還會有一次判斷，只有鍵值對數(shù)量大于 64 才會發(fā)生轉(zhuǎn)換。這是為了避免在哈希表建立初期，多個鍵值對恰好被放入了同一個鏈表中而導(dǎo)致不必要的轉(zhuǎn)化。

學(xué)過概率論的讀者也許知道，理想狀態(tài)下哈希表的每個箱子中，元素的數(shù)量遵守泊松分布:

?當(dāng)負(fù)載因子為 0.75 時，上述公式中 λ 約等于 0.5，因此箱子中元素個數(shù)和概率的關(guān)系如下:

數(shù)量概率

0	0.60653066
1	0.30326533
2	0.07581633
3	0.01263606
4	0.00157952
5	0.00015795
6	0.00001316
7	0.00000094
8	0.00000006

這就是為什么箱子中鏈表長度超過 8 以后要變成紅黑樹，因為在正常情況下出現(xiàn)這種現(xiàn)象的幾率小到忽略不計。一旦出現(xiàn)，幾乎可以認(rèn)為是哈希函數(shù)設(shè)計有問題導(dǎo)致的。

Java 對哈希表的設(shè)計一定程度上避免了不恰當(dāng)?shù)墓：瘮?shù)導(dǎo)致的性能問題，每一個箱子中的鏈表可以與紅黑樹切換。

?

總結(jié)

以上是生活随笔為你收集整理的Java 8 中的哈希表的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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