HashMap中的indexFor方法分析

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/j1231230/article/details/78072115

在整理HashMap的工作原理时,发现它调用了 indexFor(int h, int length) 方法来计算Entry对象保存在 table中的数组索引值:

static int indexFor(int h, int length) {
    return h & (length-1);
}

它没有对hash表的长度取余而使用了位运算来得到索引,这是为什么呢,顿生怀疑~

分析

//获取当前table的长度
int newCapacity = table.length;
//若长度小于目标长度,则扩展为之前的2倍
while (newCapacity < targetCapacity)
    newCapacity <<= 1;

HashMap的初始容量和扩容都是以2的次方来进行的,那么length-1换算成二进制的话肯定所有位都为1,就比如2的3次方为8,length-1的二进制表示就是111, 而按位与计算的原则是两位同时为“1”,结果才为“1”,否则为“0”。所以h& (length-1)运算从数值上来讲其实等价于对length取模,也就是h%length。

如果不满足前提条件“HashMap的初始容量和扩容都是以2的次方来进行的”,会发生什么问题呢?

假设当前table的length是15,二进制表示为1111,那么length-1就是1110,此时有两个hash值为8和9的key需要计算索引值,计算过程如下:

8的二进制表示:1000
8&(length-1)= 1000 & 1110 = 1000,索引值即为8;

9的二进制表示:1001
9&(length-1)= 1001 & 1110 = 1000,索引值也为8;

这样一来就产生了相同的索引值,也就是说两个hash值为8和9的key会定位到数组中的同一个位置上形成链表,这就产生了碰撞。

而查询的时候需要遍历这个链表,这样就降低了查询的效率。同时,我们也可以发现,当数组长度为15的时候,hash值会与length-1(1110)进行按位与,那么最后一位永远是0,而0001,0011,0101,1001,1011,0111,1101这几个位置永远都不能存放元素了,会造成严重的空间浪费,更糟的是这种情况下,数组可以使用的位置比数组长度小了很多,这意味着进一步增加了碰撞的几率,减慢了查询的效率。

因此可以看出,只有当数组长度为2的n次方时,不同的key计算得出的index索引相同的几率才会较小,数据在数组上分布也比较均匀,碰撞的几率也小,相对的,查询的时候就不用遍历某个位置上的链表,这样查询效率也就较高了。

此外,位运算快于十进制运算,hashmap扩容也是按位扩容,这样同时也提高了运算效率。

展开阅读全文

没有更多推荐了,返回首页