為什么 Map 桶中超過 8 個才轉為紅黑樹？
JDK 1.8 的 HashMap 和 ConcurrentHashMap 都有這樣一個特點：最開始的 Map 是空的，因為里面沒有任何元素，往里放元素時會計算 hash 值，計算之后，第 1 個 value 會首先占用一個桶（也稱為槽點）位置，后續如果經過計算發現需要落到同一個桶中，那么便會使用鏈表的形式往后延長，俗稱“拉鏈法”，如圖所示：
當鏈表長度大於或等於閾值（默認為 8）的時候，如果同時還滿足容量大於或等於 MIN_TREEIFY_CAPACITY（默認為 64）的要求，就會把鏈表轉換為紅黑樹。同樣，后續如果由於刪除或者其他原因調整了大小，當紅黑樹的節點小於或等於 6 個以后，又會恢復為鏈表形態。
在圖中我們可以看到，有一些槽點是空的，有一些是拉鏈，有一些是紅黑樹。
更多的時候我們會關注，為何轉為紅黑樹以及紅黑樹的一些特點，可是，為什么轉化的這個閾值要默認設置為 8 呢？要想知道為什么設置為 8，那首先我們就要知道為什么要轉換，因為轉換是第一步。
每次遍歷一個鏈表，平均查找的時間復雜度是 O(n)，n 是鏈表的長度。紅黑樹有和鏈表不一樣的查找性能，由於紅黑樹有自平衡的特點，可以防止不平衡情況的發生，所以可以始終將查找的時間復雜度控制在 O(log(n))。最初鏈表還不是很長，所以可能 O(n) 和 O(log(n)) 的區別不大，但是如果鏈表越來越長，那么這種區別便會有所體現。所以為了提升查找性能，需要把鏈表轉化為紅黑樹的形式。
那為什么不一開始就用紅黑樹，反而要經歷一個轉換的過程呢？其實在 JDK 的源碼注釋中已經對這個問題作了解釋：
- Because TreeNodes are about twice the size of regular nodes,use them only when bins contain enough nodes to warrant use(see TREEIFY_THRESHOLD). And when they become too small (due removal or resizing) they are converted back to plain bins.
這段話的意思是：單個 TreeNode 需要占用的空間大約是普通 Node 的兩倍，所以只有當包含足夠多的 Nodes 時才會轉成 TreeNodes，而是否足夠多就是由 TREEIFY_THRESHOLD 的值決定的。而當桶中節點數由於移除或者 resize 變少后，又會變回普通的鏈表的形式，以便節省空間。
通過查看源碼可以發現，默認是鏈表長度達到 8 就轉成紅黑樹，而當長度降到 6 就轉換回去，這體現了時間和空間平衡的思想，最開始使用鏈表的時候，空間占用是比較少的，而且由於鏈表短，所以查詢時間也沒有太大的問題。可是當鏈表越來越長，需要用紅黑樹的形式來保證查詢的效率。對於何時應該從鏈表轉化為紅黑樹，需要確定一個閾值，這個閾值默認為 8，並且在源碼中也對選擇 8 這個數字做了說明，原文如下：
上面這段話的意思是，如果 hashCode 分布良好，也就是 hash 計算的結果離散好的話，那么紅黑樹這種形式是很少會被用到的，因為各個值都均勻分布，很少出現鏈表很長的情況。在理想情況下，鏈表長度符合泊松分布，各個長度的命中概率依次遞減，當長度為 8 的時候，概率僅為 0.00000006。這是一個小於千萬分之一的概率，通常我們的 Map 里面是不會存儲這么多的數據的，所以通常情況下，並不會發生從鏈表向紅黑樹的轉換。
但是，HashMap 決定某一個元素落到哪一個桶里，是和這個對象的 hashCode 有關的，JDK 並不能阻止我們用戶實現自己的哈希算法，如果我們故意把哈希算法變得不均勻，例如：
@Override
public int hashCode() {
return 1;
}
這里 hashCode 計算出來的值始終為 1，那么就很容易導致 HashMap 里的鏈表變得很長。讓我們來看下面這段代碼：
public class HashMapDemo {
public static void main(String[] args) {
HashMap map = new HashMap<HashMapDemo,Integer>(1);
for (int i = 0; i < 1000; i++) {
HashMapDemo hashMapDemo1 = new HashMapDemo();
map.put(hashMapDemo1, null);
}
System.out.println("運行結束");
}
@Override
public int hashCode() {
return 1;
}
}
在這個例子中，我們建了一個 HashMap，並且不停地往里放入值，所放入的 key 的對象，它的 hashCode 是被重寫過得，並且始終返回 1。這段代碼運行時，如果通過 debug 讓程序暫停在 System.out.println("運行結束") 這行語句，我們觀察 map 內的節點，可以發現已經變成了 TreeNode，而不是通常的 Node，這說明內部已經轉為了紅黑樹。
事實上，鏈表長度超過 8 就轉為紅黑樹的設計，更多的是為了防止用戶自己實現了不好的哈希算法時導致鏈表過長，從而導致查詢效率低，而此時轉為紅黑樹更多的是一種保底策略，用來保證極端情況下查詢的效率。
通常如果 hash 算法正常的話，那么鏈表的長度也不會很長，那么紅黑樹也不會帶來明顯的查詢時間上的優勢，反而會增加空間負擔。所以通常情況下，並沒有必要轉為紅黑樹，所以就選擇了概率非常小，小於千萬分之一概率，也就是長度為 8 的概率，把長度 8 作為轉化的默認閾值。
所以如果平時開發中發現 HashMap 或是 ConcurrentHashMap 內部出現了紅黑樹的結構，這個時候往往就說明我們的哈希算法出了問題，需要留意是不是我們實現了效果不好的 hashCode 方法，並對此進行改進，以便減少沖突。