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

HashMap 是基于 HashTable 的一種數據結構，在普通哈希表的基礎上，它支持多線程操作以及空的 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: 初始容量，也就是默認會創建 16 個箱子，箱子的個數不能太多或太少。如果太少，很容易觸發擴容，如果太多，遍歷哈希表會比較慢。

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

DEFAULT_LOAD_FACTOR: 默認的負載因子。因此初始情況下，當鍵值對的數量大于?16 * 0.75 = 12?時，就會觸發擴容。

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

UNTREEIFY_THRESHOLD: 在哈希表擴容時，如果發現鏈表長度小于 6，則會由樹重新退化為鏈表。

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

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

?當負載因子為 0.75 時，上述公式中 λ 約等于 0.5，因此箱子中元素個數和概率的關系如下:

數量概率

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 以后要變成紅黑樹，因為在正常情況下出現這種現象的幾率小到忽略不計。一旦出現，幾乎可以認為是哈希函數設計有問題導致的。

Java 對哈希表的設計一定程度上避免了不恰當的哈希函數導致的性能問題，每一個箱子中的鏈表可以與紅黑樹切換。

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。