从“jdk1.8对HashMap的改进”想到的

转载：https://www.cnblogs.com/fangtingfei/p/12964224.html

 

一、改进

1，jdk1.7底层采用entry数组+链表的数据结构，而1.8采用node数组+链表/红黑树的数据结构。

2，jdk1.7的HashMap插入新值时使用头插法，1.8使用尾插法。

使用头插法比较快，但在多线程扩容时会引起倒序和闭环的问题。所以1.8就采用了尾插法。

3，扩容后新表中的索引位置计算方式不同，jdk1.7扩容时是将旧表元素的所有数据重新进行哈希计算，即hashCode & (length-1)。而1.8中扩容时只需将hashCode和老数组长度做与运算判断是0还是1，是0的话索引不变，是1的话索引变为老索引位置+老数组长度。

 

二、扩容为什么是2的n次方

1，插入新元素确定索引位置的时候是采用key的hashCode和数组长度做与运算，即hashCode&(length-1)。模拟的是取模运算，但速度比取模快很多，要保证这种运算的正确性，必须要求数组的长度是2的n次方。

2，在扩容时进行新索引位置的计算时也要求数组长度是2的n次方。

 

=======================

以上是转载的内容，我转载的目的主要是想聊聊自己想法，很感慨。其实也是顺便做个分析和总结。

感慨源于三处：

a、上面的“一”中的“2”，

尾插法比头插法似乎更笨，但是为了稳定性和功能准确上的考虑，必须这样。

验证了那句话，合适的才是最好的，不一定是最快的。其实我们在具体方案设计中何尝不是这样子的？！

b、上面的“一”中的“3”

jdk1.7会重新计算；而在1.8中却尽量保持和原来的一致，不变。

kafka分区策略之一也有这种方式。其实尽量保持数据不动才是最合适不过的了，是不是由回到了"a"!

c、“二”中的“1”

让我注意的是取模方式的改变。

我从ipanel出来后，就非常喜欢用“与或非”，因为在ipanel大量使用，性能提高也是用这个代替。不过我后面倒是没想过性能的问题，可能顺手了！

看来我是滞后的，这就是性能提高的手段，这里就是佐证。事实上，“一”中的“3”也是用与运算，是不是又回到了“b”!

 

今天这个总结何尝不是提炼了一种学习方法。同一个方法论可以适用很广，不是吗？

 

最后，再来一句陈海贤老师的话：

道理最大的好处是，当你到了那里时，你知道有人来过，于是心生安慰！