HashMap的底层容量为什么要设置成2的次幂？

之前看到一篇帖子讨论初始化HashMap的时候是否应该设置初始容量，那篇帖子讲了很多，最后的结论是应该设置，但是设置成多少没有提，评论区有不少人说那就用多少设置多少，比如用6个就设置为6。

且不说真正业务场景上你是很难提前定义一个集合类应该存放多少数据的，因为大多数场景都是业务相关决定的，就算真的可能确定，也不应该是这样一个结论，因为你设置的值其实并不是HashMap初始化时真正的容量，真正的初始化容量是大于你设置的容量的第一个2次幂。

为什么这么设计呢，其实是和HashMap的底层涉及有关，我们知道HashMap是一个数组➕链表（之后是红黑树）的结构，根据当前key的Hash值来确定数组中的位置，如果这个位置选择的不好，就会导致数组有一些地方始终放不进去值，有一些地方一直在链式加元素，造成资源的浪费。

这个HashMap中的位置是怎么计算的，我们再看看代码

核心就是这一句

p = tab[i = (n - 1) & hash]

这里关注下(n - 1) & hash，n是目前的数组容量，hash是当前key的hash值，看到n-1你可能已经有感觉了，我们不妨把n的各种情况模拟一下，假设n=16，hash值从0递增

hash值	(n - 1) & hash	结果
0	1111&0000	0
1	1111&0001	1
2	1111&0010	2
3	1111&0011	3
4	1111&0100	4
...	...	...
14	1111&1110	14
15	1111&1111	15
16	01111&10000	0（链式存储在0后面）

 

能发现算出来的位置基本是散列开的，很均匀。

那么我们把n换成15试试，n-1 = 14 (1110)

hash值	(n - 1) & hash	结果
0	1110&0000	0
1	1110&0001	0
2	1110&0010	2
3	1110&0011	2
4	1110&0100	4
...	...	...
14	1110&1110	14
15	1110&1111	14

 

会发现0，2，4等位置都链式存储了两个数据，而1，3等位置始终没有数据存储，这就造成了浪费。

这里面还有一个小彩蛋，其实这种计算数组位置的问题，我的第一想法就是取余运算，那么为什么这里不用取余呢？取余就没这个问题了，这里其实还是因为&的性能要优于取余运算，实际上位运算(&)效率要比代替取模运算(%)高很多，主要原因是位运算直接对内存数据进行操作，不需要转成十进制，因此处理速度非常快。所以这种最底层的计算逻辑，优先考虑位运算，这样就不难理解为什么如此设计了