hashMap的数组长度为什么要求是2的整数次幂

为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀。Hash 值的范围值-2147483648到2147483647，前后加起来大概40亿的映射空间，只要哈希函数映射得比较均匀松散，一般应用是很难出现碰撞的。但问题是一个40亿长度的数组，内存是放不下的。所以这个散列值是不能直接拿来用的。用之前还要先做对数组的长度取模运算，得到的余数才能用来要存放的位置也就是对应的数组下标。这个数组下标的计算方法是“ (n - 1) & hash ”。（n代表数组长度）。
这个算法应该如何设计呢？
我们首先可能会想到采用%取余的操作来实现。但是，重点来了：“取余(%)操作中如果除数是2的幂次则等价于与其除数减一的与(&)操作（也就是说 hash%length==hash&(length-1)的前提是 length 是2的 n 次方；）。” 并且 采
用二进制位操作 &，相对于%能够提高运算效率，这就解释了 HashMap 的长度为什么是2的幂次方。
下面这张图很好的解释了找到对应数组下标的过程。
拿16举例，16-1=15,15的二进制为1111，15&hash的得到哈希值的低四位，这个第四位刚好对应着16长度的0-15下标，而且实现了散列。

java获取hashmap的值 hashmap数组长度_数组

hashMap的加载因子为什么是0.75

加载因子*数组长度就是hashMap扩容的阈值。例如hashMap默认数组长度为16，当put值时，如果当前数组位置补位空且已占用的数组长度达到12，那么hashMap就会进行扩容。
如果加载因子为1，即当数组所有位置都有元素时进行扩容，这样虽然减少了空间开销，提高了空间利用率，但是哈希冲突肯定会变多，势必造成链表的堆积，增加查询时间。
如果加载因子为0.5，虽然可以减少查询时间成本，但是空间利用率很低，同时提高了扩容次数，增加了性能开销。
所以0.75这个值是对空间利用率和时间利用率的折中。

hashMap为什么当链表长度为8时转为红黑树

java获取hashmap的值 hashmap数组长度_数组_02

这是hashMap源码中的一段注释，从这段注释中我们可以得到想要的答案。

*Ignoring variance, the expected
     * occurrences of list size k are (exp(-0.5) * pow(0.5, k) /
     * factorial(k))

这段源码意思是：忽略方差，列表大小k的预期出现次数 列表大小k的预期出现次数 遵循(exp(-0.5) * pow(0.5, k) / * factorial(k))。而这个就是泊松分布。

java获取hashmap的值 hashmap数组长度_链表_03

泊松分布中λ的值注释中也给出。

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

在理想的随机hashCodes下，容器中节点的频率遵循泊松分布，对于0.75的默认调整阈值，泊松分布的概率质量函数中参数λ（事件发生的平均次数）的值约为0.5，尽管λ的值会因为load factor值的调整而产生较大变化。

在按照泊松分布公式来看，链表达到长度为8的概率为0.00000006，概率非常的小，那hashMap为什么要选取概率最小的时候将链表转换为红黑树。

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)

注释也解释了，TreeNode虽然改善了链表增删改查的性能，但是其节点大小是链表节点的两倍。
虽然引入TreeNode但是不会轻易转变为TreeNode（如果存在大量转换那么资源代价比较大），根据泊松分布来看当k=8,转变是小概率事件，性价比是值得的。