直白一點(diǎn)：就是trade-off，空間和時(shí)間上的權(quán)衡！
源碼中有如下內(nèi)容：

* 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

當(dāng)hashCode離散性很好的時(shí)候，樹型bin用到的概率非常小，因?yàn)閿?shù)據(jù)均勻分布在每個(gè)bin中，幾乎不會(huì)有bin中鏈表長度會(huì)達(dá)到閾值。但是在隨機(jī)hashCode下，離散性可能會(huì)變差，然而JDK又不能阻止用戶實(shí)現(xiàn)這種不好的hash算法，因此就可能導(dǎo)致不均勻的數(shù)據(jù)分布。不過理想情況下隨機(jī)hashCode算法下所有bin中節(jié)點(diǎn)的分布頻率會(huì)遵循泊松分布，可以看到，一個(gè)bin中鏈表長度達(dá)到8個(gè)元素的概率為0.00000006，幾乎是不可能事件。所以，之所以選擇8，是根據(jù)概率統(tǒng)計(jì)決定的。

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

總結(jié)

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

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