阿里面試題：爲何Map桶中個數超過8才轉爲紅黑樹

（爲何一個是8一個是6：防止頻繁來回轉換小消耗性能）

 

這是筆者面試阿里時，被問及的一個問題，應該很多人看到這個問題都會一面懵逼。由於，大部分的文章都是分析鏈表是怎麼轉換成紅黑樹的，可是並無說明爲何當鏈表長度爲8的時候才作轉換動做。筆者第一反應也是同樣，只能初略的猜想是由於時間和空間的權衡。

要弄明白這個問題，咱們首先要明白爲何要轉換，這個問題比較簡單，由於Map中桶的元素初始化是鏈表保存的，其查找性能是O(n)，而樹結構能將查找性能提高到O(log(n))。當鏈表長度很小的時候，即便遍歷，速度也很是快，可是當鏈表長度不斷變長，確定會對查詢性能有必定的影響，因此才須要轉成樹。至於爲何閾值是8，我想，去源碼中找尋答案應該是最可靠的途徑。

8這個閾值定義在HashMap中，以下所示，這段註釋只說明瞭8是bin（bin就是bucket，即HashMap中hashCode值同樣的元素保存的地方）從鏈表轉成樹的閾值，可是並無說明爲何是8：

1 /**
2  * The bin count threshold for using a tree rather than list for a
3  * bin.  Bins are converted to trees when adding an element to a
4  * bin with at least this many nodes. The value must be greater
5  * than 2 and should be at least 8 to mesh with assumptions in
6  * tree removal about conversion back to plain bins upon shrinkage.
7  */
8 static final int TREEIFY_THRESHOLD = 8;

 

咱們繼續往下看，在HashMap中有一段Implementation notes，筆者摘錄了幾段重要的描述，第一段以下所示，大概含義是當bin變得很大的時候，就會被轉換成TreeNodes中的bin，其結構和TreeMap類似，也就是紅黑樹：

This map usually acts as a binned (bucketed) hash table, but when bins get too large, they are transformed into bins of TreeNodes, each structured similarly to those in java.util.TreeMap

繼續往下看，TreeNodes佔用空間是普通Nodes的兩倍，因此只有當bin包含足夠多的節點時纔會轉成TreeNodes，而是否足夠多就是由TREEIFY_THRESHOLD的值決定的。當bin中節點數變少時，又會轉成普通的bin。而且咱們查看源碼的時候發現，鏈表長度達到8就轉成紅黑樹，當長度降到6就轉成普通bin。

這樣就解析了爲何不是一開始就將其轉換爲TreeNodes，而是須要必定節點數才轉爲TreeNodes，說白了就是trade-off，空間和時間的權衡：

 1 Because TreeNodes are about twice the size of regular nodes, we
 2 use them only when bins contain enough nodes to warrant use
 3 (see TREEIFY_THRESHOLD). And when they become too small (due to
 4 removal or resizing) they are converted back to plain bins.  In
 5 usages with well-distributed user hashCodes, tree bins are
 6 rarely used.  Ideally, under random hashCodes, the frequency of
 7 nodes in bins follows a Poisson distribution
 8 (http://en.wikipedia.org/wiki/Poisson_distribution) with a
 9 parameter of about 0.5 on average for the default resizing
10 threshold of 0.75, although with a large variance because of
11 resizing granularity. Ignoring variance, the expected
12 occurrences of list size k are (exp(-0.5)*pow(0.5, k)/factorial(k)). 
13 The first values are:
14 0:    0.60653066
15 1:    0.30326533
16 2:    0.07581633
17 3:    0.01263606
18 4:    0.00157952
19 5:    0.00015795
20 6:    0.00001316
21 7:    0.00000094
22 8:    0.00000006
23 more: less than 1 in ten million

 

這段內容還說到：當hashCode離散性很好的時候，樹型bin用到的機率很是小，由於數據均勻分佈在每一個bin中，幾乎不會有bin中鏈表長度會達到閾值。可是在隨機hashCode下，離散性可能會變差，然而JDK又不能阻止用戶實現這種很差的hash算法，所以就可能致使不均勻的數據分佈。不過理想狀況下隨機hashCode算法下全部bin中節點的分佈頻率會遵循泊松分佈，咱們能夠看到，一個bin中鏈表長度達到8個元素的機率爲0.00000006，幾乎是不可能事件。因此，之因此選擇8，不是拍拍屁股決定的，而是根據機率統計決定的。因而可知，發展30年的Java每一項改動和優化都是很是嚴謹和科學的。

• 畫外音

筆者經過搜索引擎搜索這個問題，發現不少下面這個答案（猜想也是相互轉發）：

紅黑樹的平均查找長度是log(n)，若是長度爲8，平均查找長度爲log(8)=3，鏈表的平均查找長度爲n/2，當長度爲8時，平均查找長度爲8/2=4，這纔有轉換成樹的必要；鏈表長度若是是小於等於6，6/2=3，而log(6)=2.6，雖然速度也很快的，可是轉化爲樹結構和生成樹的時間並不會過短。

筆者認爲這個答案不夠嚴謹：「3相比4有轉換的必要，而2.6相比3就沒有轉換的必要？

 因此我認爲答這個題從下面3點：

1.TreeNodes佔用空間是普通Nodes的兩倍，爲了空間和時間的權衡，爲6時紅黑樹也比鏈表快，但轉換過程消耗和空間消耗不划算

2.節點的分佈頻率會遵循泊松分佈，鏈表長度達到8個元素的機率爲0.00000006，幾乎是不可能事件

3.提出來迴轉化的閾值8和6閾值爲何不同

至於爲何轉化爲紅黑樹的閾值8和轉化爲鏈表的閾值6不同，是爲了避免頻繁來回轉化

 

https://www.cnblogs.com/linghu-java/p/10598758.html