HashMap的树化因子为什么是8

网上主流的答案：
红黑树的平均查找长度是log(n)，如果长度为8，平均查找长度为log(8)=3，链表的平均查找长度为n/2，当长度为8时，平均查找长度为8/2=4，红黑树的查找效率更高，这才有转换成树的必要；
链表长度如果是小于等于6，6/2=3，而log(6)=2.6，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短
这个答案是从查找效率的角度解释的，这种解释虽然有一定的合理性，但并不是设计者真正的想法

真正的原因——JDK设计者的解释
摘自HashMap源码中的Implementation notes.

• 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
• more: less than 1 in ten million
  上面的内容：当hashCode离散性很好的时候，树型bin(容器)用到的概率非常小，因为数据均匀分布在每个bin中，几乎不会有bin中链表长度会达到阈值（树化门槛）。但是在随机hashCode下，离散性可能会变差，然而JDK又不能阻止用户实现这种不好的hash算法，因此就可能导致不均匀的数据分布。不过理想情况下随机hashCode算法下所有bin中节点的分布频率会遵循泊松分布，我们可以看到，一个bin中链表长度达到8个元素的概率为0.00000006，几乎是不可能事件。所以，之所以选择8，不是拍拍屁股决定的，而是根据概率统计决定的。由此可见，发展30年的Java每一项改动和优化都是非常严谨和科学的。