彻底弄懂为什么HashMap的数组容量是2的幂次方以及0.75的负载因子值

HashMap必然是Java程序员最经使用的Key-Value映射集合，所以往往搞懂其底层实现put流程、get流程还不够，在面试的过程中我们经常会被面试官问到为什么HashMap的数组容量始终是2的幂次方以及为什么是设计者选择了0.75作为负载因子。

那么首先先来回答第一个问题。

（1）定位哈希桶下标的时候先调用key的hashCode()，一般返回的哈希值都较大，所以在使用之前需要先Ian对数组长度进行取模运算，得到的余数才是元素存放的桶下标。

（2）那这时候定位桶下标的算法应该是key.hashCode%map.capacity，但是我们看源码的时候他的计算方式是map.capacity&(n-1)。

事实上，两种方式都能计算出桶下标，但是使用位运算的在cpu的计算效率比取模运算要高得多，因为计算机认01嘛，据说是快了6-7倍。

下面我们就来看看为什么位运算快？

在JDK1.8以后，HashMap的底层数组在首次调用put方法时创建，初始容量为16，以16扩容到32数组容量为例。

16的二进制数是10000,15的二进制数就是1111；

32的二进制数是100000,31的二进制数就是11111。

因此，我们在扩容HashMap的时候，不需要重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，如果是0的话表示索引没变，扩容之后还是存放在原来的桶中；如果是1的话也只需要在原来的桶下标的基础上加上oldCapacity。如图中的低4位往前再看1位发现是1，原来的桶下标是5，那扩容以后，这个key-value对就应该存放在5+16=21号桶中。

现在是不是觉得非常的妙。

我们再来看看为什么HashMap默认的负载因子是0.75。

首先我们知道，HashMap中的桶中元素都是以链表的形式相连接的，当链表元素>8个并且当前Map中所有元素>64个时，该链表就会转换成红黑树的形式来存储元素。红黑树是一种不追求绝对平衡的二叉树。具体细节放在下一章讲解，其时间复杂度是O(logN)，而链表的时间复杂度是O(N)。当桶中元素少的时候，效率其实都差不多。进入正题，

（1）0.75的负载因子是对内存空间和时间效率的一个平衡选择，根据泊松分布，负载因子取0.75的情况下，链表达到8个元素的概率是非常小的，不仅是0.75的负载因子加持还有二次hash算法，这些都是为了解决哈希冲突问题，尽量在不要让一个桶中元素达到8个转换成红黑树。因为链表的插入删除效率是比红黑树高的，红黑树通过左旋、右旋、变色来达到完美黑色平衡。所以在负载因子取0.75的情况下，也能够减少频繁在链表与红黑树之间相互转换而造成性能损失，同时也能够解决一部分特殊情况下，链表元素达到8个时时间复杂度是O(N)的慢效率。

如果内存资源充足的话，并且对时间复杂度要求较高，我们就可以调低负载因子的值。比如HashMap初始容量是16，负载因子0.75，当Map中元素达到12个在插入13个时就会发生扩容现象。但我们不希望链表太长影响性能，就是追求响应速度快，就可以调低这个值，比如在插入第9个元素时就扩容。

如果内存资源紧张，并且对时间复杂度要求不高的场景下，我们就可以增加负载因子的值，把负载因子的值设置成>1，那就不会触发扩容，以时间换空间。最差的情况就是16个桶中全是红黑树嘛