直白一點：就是trade-off，空間和時間上的權衡！
源碼中有如下內容：

* Because TreeNodes are about twice the size of regular nodes, we* use them only when bins contain enough nodes to warrant use* (see TREEIFY_THRESHOLD). And when they become too small (due to* removal or resizing) they are converted back to plain bins. In* usages with well-distributed user hashCodes, tree bins are* rarely used. Ideally, under random hashCodes, the frequency of* nodes in bins follows a Poisson distribution* (http://en.wikipedia.org/wiki/Poisson_distribution) with a* parameter of about 0.5 on average for the default resizing* threshold of 0.75, although with a large variance because of* resizing granularity. Ignoring variance, the expected* occurrences of list size k are (exp(-0.5) * pow(0.5, k) /* factorial(k)). The first values are:** 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

當hashCode離散性很好的時候，樹型bin用到的概率非常小，因為數據均勻分布在每個bin中，幾乎不會有bin中鏈表長度會達到閾值。但是在隨機hashCode下，離散性可能會變差，然而JDK又不能阻止用戶實現這種不好的hash算法，因此就可能導致不均勻的數據分布。不過理想情況下隨機hashCode算法下所有bin中節點的分布頻率會遵循泊松分布，可以看到，一個bin中鏈表長度達到8個元素的概率為0.00000006，幾乎是不可能事件。所以，之所以選擇8，是根據概率統計決定的。

還有另一種說法是：
紅黑樹的平均查找長度是log(n)，如果長度為8，平均查找長度為log(8)=3，鏈表的平均查找長度為n/2，當長度為8時，平均查找長度為8/2=4，這才有轉換成樹的必要；鏈表長度如果是小于等于6，6/2=3，而log(6)=2.6，雖然速度也很快的，但是轉化為樹結構和生成樹的時間并不會太短。貌似有點道理，但其實，小于6這個閾值，是為了防止當紅黑樹的結點從8個減為7個時，又得換成鏈式結構而造成對table表的頻繁操作。試問3相比4有轉換的必要，而2.6相比3就沒有轉換的必要？所以閾值取8是時間和空間上的綜合權衡。

總結

以上是生活随笔為你收集整理的为什么Map桶中个数超过8才转为红黑树的全部內容，希望文章能夠幫你解決所遇到的問題。

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