关于hashMap中 计算hashCode的逻辑推理（二）

hashMap中，为了使元素在数组中尽量均匀的分布，所以使用取模的算法来决定元素的位置.如下：

 //方法一：
 static final int hash(Object key){//jdk1.8
   int h;
   return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
 }
 //方法二：
 static int indexFor(int h,int length){//低版本的源码
   return h & (length - 1);//第三步，取模运算
 }

方法一是我当前使用jdk版本的源码，

方法二是在网上查到的低版本的源码，

首先确认：当length总是2的n次方时，  h & (length - 1)   等价于   hash对length取模      ，但是&比%具有更高的效率；（下文有对该方法的说明）.

其次，方法一和方法二的原理是一样的，

在JDK1.8的实现中，优化了高位运算的算法，通过hashCode()的高16位异或低16位实现的：(h = k.hashCode()) ^ (h >>> 16)，

主要是从速度、功效、质量来考虑的，这么做可以在数组table的length比较小的时候，也能保证考虑到高低Bit都参与到Hash的计算中，同时不会有太大的开销。

-----------------------------------

另开头：

为什么数组大小为2的幂时hashmap访问性能最高？

我在网上查了一些博文，好多都”举例说明“，来以事实说话，

其实我感觉这有取巧的嫌疑，

以下为我个人理解（错误的理解，文章结尾处已写明）：

为什么取length（奇数）-1？  而不是 length（偶数）-1？

在进行&（逻辑与）运算时（例：a & b），只有当 a =true and b =true 时，结果才是 1，否则都是0；

所以，当 hash & 偶数  时，  二进制结果 就总会是偶数，这就导致 数组的偶数位被浪费，数组的奇数位的冲突概率 增高.

基于以上，所以  存储位置index = h & (length - 1)；   中length取偶数 使得  hashMap具有更高的性能.

至于为什么选择 为2的幂？    接触尚短，我暂时还没想到，待后续.

-----------------------------------------------------------------------------------------

通过研读前辈们的博文，以下 为 为什么使用 2的幂 作为数组长度：

当容量一是为2的幂 时，h&(length - 1) == h%length,它俩是等价不等效的.！！！！！！！！

-------------------------

推导：

2^n转换成二进制就是1+n个0，减1之后就是0+n个1， 如16 -> 10000，15 -> 01111,那根据&位运算规则，都为1时，才为1，那0≤运算后的结果≤15，

假设h <= 15，那么运算后的结果就是h本身，h >15，运算后的结果就是最后三位二进制做&运算后的值，最终，就是%运算后的余数.

补充：

通过位运算（不用模运算符%）求余

前提：a/b的除数 b必须为2的 你次方.也就是说b必须是

2的一次方 1

2的二次方 4

2的三次方 8

......

......

只有是这样的一种情况，这种方法才是正确的.

如下两种方法：

方法一：a%b = a&( b -1);

例：

a=9 ， b= 8.   小括号内的值为b-1 = 8-1 =7. 9 的二进制表现：1001,7的二进制表现：0111， a%b = a&(b-1) = 9%8 = 9&(8-1) 的结果值：0001 = 1.也就是说，余数为1.结果是正确的.

方法二：a%b = a-((a>>log2[b])<<log2[b]);

例:

初始值还是 a= 9，b = 8. a-((a>>3）<<3) 先右移3位，再左移三维，然后a减去移位后的值.

在hashMap中使用的方法一.

因此，容量（数组长度）必须为2的幂方.

上文中我自己的想法也是不对的. 长度取偶数  那只是取2的幂方的  结果属性.并不是原因之一.上文就不删改了， 留下个记号完整学习过程.