友情提示:本文推理结果是不准确的,因为在HashMap中处于数组同一位置的元素的哈希值大部分情况是不同的,但整个思考过程比较完整,有兴趣的可以看看。
话不多说,我们直接看HashMap的resize方法源码:
重点在715-744行,我直接说结论,我会用一行代码去替换掉这近30行,如下:
newTab[e.hash & (newCap - 1)] = e;
你可能看出来了,这和上面的 e.next == null 判断之后的操作是一样的,所以可以直接将这2个判断合并,重写之后的resize方法如下:
final Node<K,V>[] resize() {
Node<K,V>[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
if (oldCap > 0) {
if (oldCap >= MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return oldTab;
}
else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = oldThr << 1; // double threshold
}
else if (oldThr > 0) // initial capacity was placed in threshold
newCap = oldThr;
else { // zero initial threshold signifies using defaults
newCap = DEFAULT_INITIAL_CAPACITY;
newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
}
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
threshold = newThr;
@SuppressWarnings({"rawtypes","unchecked"})
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
table = newTab;
if (oldTab != null) {
for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null;
if (e instanceof TreeNode)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
else { // preserve order
newTab[e.hash & (newCap - 1)] = e;
}
}
}
}
return newTab;
}
分析思考:
下面来分析一下我的思考过程,其实我首先想到的是下面这个版本:
if ((e.hash & oldCap) == 0) {
newTab[j] = e;
}else {
newTab[j+ oldCap]= e;
}
然后觉得能不能更优,就有了下面这个2行的代码:
newTab[e.hash & oldCap == 0?j:j+ oldCap] = e;
本来都这儿可以结束了,但我突然发现,还可以更简洁,所以有了开头的那一行代码,和源码中的712行一样,所以直接就能合并了。
在我发现了这个优化后,是考虑弄个类继承HashMap去测试验证一下,但由于resize方法不是public修饰的,且是final关键字修饰的,所以必须得将整个 HashMap的源码复制过来,再修改其resize方法即可实现验证,我觉得太麻烦,而且也没必要。
所以这里呢我会以原作者的思路,通过逆推的方式来验证我这个优化的准确性。我们继续来分析一下resize方法的 715-744行 代码,它首先定义了 loHead,loTail 和 hiHead,hiTail 这四个变量,目的就是为了区分 (e.hash & oldCap) == 0 和 (e.hash & oldCap) != 0 的情况,这个情况是因为在HashMap扩容后 e.hash & 2n-1 的值只可能是原数组的索引下标 j 或者原数组的索引下标加上原数组的长度 j + oldCap 。但其实完全没必要定义四个变量,只需要定义2个 head 和 tail 即可。为什么呢?现在我们着重看下do-while 循环中的代码:
重点在 721 行,可以看出来 e.hash() 和 oldCap 这2个变量在 do-while 循环中 是不变的,因为整个链表e都是在原数组的同一个位置的,所以它们的哈希值肯定是相等的。基于这个结论,我们在原作者的思路上可以一下优化他的715-744行代码,如下:
Node<K,V> head = null, tail = null;
Node<K,V> next;
do {
next = e.next;
if (tail == null)
head = e;
else
tail.next = e;
tail = e;
} while ((e = next) != null);
if (tail != null) {
tail.next = null;
newTab[(head.hash & oldCap) == 0?j:j+ oldCap] = head;
}
只用了 head 和 tail 2个变量就完成了原来的功能。写到这儿,我想你大概明白了,分析上面的代码可以看出来,其实 head 和 tail 变量并没有什么实际用处。在do-while 循环结束后,先判断 tail 是否为空 ,这行完全没必要,因为在588行已经判断了e不为null了,如下:
所以进入循环后 tail 肯定不会为空的,然后用 head 的哈希值与 oldCap 按位与运算后得到在数组中的索引位置,将head放入新数组中,这行根本就是多余的,因为 head=e 只会在第一次循环的时候赋值,所以整个do-while 循环没有必要,直接用 e 替换head是完全没问题的,这样用 e 替换后就得到了我开头优化的那行代码:
newTab[(e.hash & oldCap) == 0?j:j+ oldCap] = e;
然后发现 e.hash 值既然是固定的,就没必要用三元表达式了,直接用 e.hash & (newCap - 1) 得到下标索引就行了:
newTab[e.hash & (newCap - 1)] = e;
所以我们用原作者的思路推出了我们这个优化代码。
总结:
我第一次看到 715-744行 这段代码是有点不知所云的,总觉得有些别扭,在看了一遍之后,我得到的结论就是newTab[j] = e;
所以在经过思考和分析后就得到了这一行优化代码:
newTab[e.hash & (newCap - 1)] = e;
另外在源码中可以感觉到有点花里胡哨,弄得很复杂。事实上我们回过头来思考,会发现 715-744行整个的目的就是将原数组中的链表顺序复制进新数组中即可,避免jdk1.7中扩容数据迁移时候的死循环,所以其实很简单就能做到了
如果觉得有问题的同学,可以在评论中指出来