参考原文地址

一、HashMap剖析

首先看看HashMap的顶部注释说了些什么：

image.png

再来看看HashMap的类继承图：

image.png

下面我们来看一下HashMap的属性：

image.png

成员属性有这么几个：

image.png

再来看一下hashMap的一个内部类Node：

image.png

我们知道Hash的底层是散列表，而在Java中散列表的实现是通过数组+链表的~

再来简单看看put方法就可以印证我们的说法了：数组+链表-->散列表

image.png

我们可以简单总结出HashMap：

无序，允许为null，非同步
底层由散列表(哈希表)实现
初始容量和装载因子对HashMap影响挺大的，设置小了不好，设置大了也不好
1.1HashMap构造方法
HashMap的构造方法有4个：

image.png

image.png

在上面的构造方法最后一行，我们会发现调用了tableSizeFor()，我们进去看看：

image.png

这是位运算算法，具体流程可参考：

https://www.cnblogs.com/loading4/p/6239441.html
https://blog.csdn.net/fan2012huan/article/details/51097331

看完上面可能会感到奇怪的是：为啥是将2的整数幂的数赋给threshold？

threshold这个成员变量是阈值，决定了是否要将散列表再散列。它的值应该是：capacity * load factor才对的。

其实这里仅仅是一个初始化，当创建哈希表的时候，它会重新赋值的：

image.png

至于别的构造方法都差不多，这里我就不细讲了：

image.png

1.2put方法

put方法可以说是HashMap的核心，我们来看看：

image.png

我们来看看它是怎么计算哈希值的：

image.png

为什么要这样干呢？？我们一般来说直接将key作为哈希值不就好了吗，做异或运算是干嘛用的？？

我们看下来：

image.png

我们是根据key的哈希值来保存在散列表中的，我们表默认的初始容量是16，要放到散列表中，就是0-15的位置上。也就是tab[i = (n - 1) & hash]。可以发现的是：在做&运算的时候，仅仅是后4位有效~那如果我们key的哈希值高位变化很大，低位变化很小。直接拿过去做&运算，这就会导致计算出来的Hash值相同的很多。

而设计者将key的哈希值的高位也做了运算(与高16位做异或运算，使得在做&运算时，此时的低位实际上是高位与低位的结合)，这就增加了随机性，减少了碰撞冲突的可能性！

下面我们再来看看流程是怎么样的：