在HashMap中当数组长度到达64且链表长度大于8时，为什么链表转为红黑树

HashMap的结构

1.首先我们来看一下HashMap的结构，HashMap的底层是基于数组＋链表+红黑树的原理。

2.数组特点：查询快，增删慢。
链表特点：查询慢，增删快。
红黑树特点：查询快，增删快，是一棵二叉排序树，有自平衡的特点，时间复杂度能控制到O(log(n))。

HashMap的扩容机制

HashMap的默认容量为16，默认的负载因子为0.75，当HashMap中元素个数超过容量乘以负载因子的个数时，就创建一个大小为前一次两倍的新数组，再将原来数组中的数据复制到新数组中。当数组长度到达64且链表长度大于8时，链表转为红黑树。
底层源码：

    //负载因子
    static final float DEFAULT_LOAD_FACTOR = 0.75f;

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

    /**
     * The bin count threshold for untreeifying a (split) bin during a
     * resize operation. Should be less than TREEIFY_THRESHOLD, and at
     * most 6 to mesh with shrinkage detection under removal.
     */

为什么数组长度达到64且链表长度大于8时，转为红黑树

每次遍历一个链表，平均查找的时间复杂度是 O(n)，n 是链表的长度。红黑树有和链表不一样的查找性能，由于红黑树有自平衡的特点，可以防止不平衡情况的发生，所以可以始终将查找的时间复杂度控制在 O(log(n))。
最初链表还不是很长，所以可能 O(n) 和 O(log(n)）的区别不大，但是如果链表越来越长，那么这种区别便会有所体现。所以为了提升查找性能，需要把链表转化为红黑树的形式。
那么问题来了，既然红黑树这么好用，为什么不直接使用红黑树呢？

为什么不直接用红黑树

这个问题其实在源码中已经给出了答案

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.

通过源码我们可以发现，系统默认的是链表长度达到8就转成红黑树，而当链表长度降到6就转换回链表，这体现了时间和空间平衡的思想。
我们也可以理解成最开始使用链表的时候，空间占用是比较少的，而且由于链表短，所以查询时间也没有太大的问题。可是当链表越来越长，需要用红黑树的形式来保证查询的效率。此时对于何时应该从链表转化为红黑树，就应该需要确定一个阈值，于是系统把这个阈值默认设置为8。
那么问题又来了，为什么这个阈值刚好是8呢？

为什么链表转成红黑树的阈值为8

这个问题在源码中也有解释

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 分布的比较良好，也就是 hash 冲突比较少，那么红黑树这种形式是很少会被用到的，因为各个值都均匀分布，很少出现链表很长的情况。在理想情况下，链表长度符合泊松分布，各个长度的命中概率依次递减，当长度为8的时候，概率仅为0.00000006。这是一个小于千万分之一的概率，在实际情况中我们的 Map 里面是不会存储这么多的数据的，所以通常情况下，并不会发生从链表向红黑树的转换。
那么问题又来了，当数组长度小于64，但链表长度大于8时，链表还会转成红黑树吗？

数组长度小于64，链表长度大于8时

如果链表长度大于8，但是数组长度小于64时，还是会进行扩容操作，不会转换为红黑树。因为数组的长度较小，应该尽量避开红黑树。因为红黑树需要进行左旋，右旋，变色操作来保持平衡。
所以当数组长度小于64，使用数组加链表比使用红黑树查询速度要更快、效率要更高。

总结

一般情况下，HashMap底层使用数组+链表，当数据量非常大时，长度大的链表（大于8）自动转成红黑树，此时，HashMap底层使用数组+链表+红黑树。至于这个阈值是系统设置的。当链表长度降到6时就自动转换回链表。
通常情况下不会使用红黑树，当数据量较小时，如何强制使用红黑树，不但不能提高效率，反而耗费内存空间。只有当数据量非常大时，使用红黑树才能更好地提高效率。