美文网首页
JDK8 hashMap 为什么在桶节点数量为8时转红黑树

JDK8 hashMap 为什么在桶节点数量为8时转红黑树

作者: 有你我就不孤单 | 来源:发表于2019-07-23 18:20 被阅读0次

利用泊松离散分布公式,在参数为0.5的情况下, 存量在8以后就达到最小值,也就意味在8以后出现treemap的概率会一直增加,这样就减少了treeMap和链表之间的相互切换的概率。

前提是以默认扩容因子0.75位基础计算的。

如下是代码注释

/*

    * Implementation notes.

    *

    * 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. Most methods try to use normal bins, but

    * relay to TreeNode methods when applicable (simply by checking

    * instanceof a node).  Bins of TreeNodes may be traversed and

    * used like any others, but additionally support faster lookup

    * when overpopulated. However, since the vast majority of bins in

    * normal use are not overpopulated, checking for existence of

    * tree bins may be delayed in the course of table methods.

    *

    * Tree bins (i.e., bins whose elements are all TreeNodes) are

    * ordered primarily by hashCode, but in the case of ties, if two

    * elements are of the same "class C implements Comparable<C>",

    * type then their compareTo method is used for ordering. (We

    * conservatively check generic types via reflection to validate

    * this -- see method comparableClassFor).  The added complexity

    * of tree bins is worthwhile in providing worst-case O(log n)

    * operations when keys either have distinct hashes or are

    * orderable, Thus, performance degrades gracefully under

    * accidental or malicious usages in which hashCode() methods

    * return values that are poorly distributed, as well as those in

    * which many keys share a hashCode, so long as they are also

    * Comparable. (If neither of these apply, we may waste about a

    * factor of two in time and space compared to taking no

    * precautions. But the only known cases stem from poor user

    * programming practices that are already so slow that this makes

    * little difference.)

    *

    * 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

    *

相关文章

网友评论

      本文标题:JDK8 hashMap 为什么在桶节点数量为8时转红黑树

      本文链接:https://www.haomeiwen.com/subject/ozwalctx.html