并发下HashMap为什么不是线程安全的？

HashMap的结构就是哈希表，底层是一个数组，这个数组中尽可能地分散所有的key，通过key的hash值得到数组下标，然后把entry插到该数组，假如有两个不同的key被分到相同的下标，也就是哈希冲突，那么该数组在该下标下就会形成链表。

为了减少冲突，我们需要时刻留意当前的size是否太大，检查是否需要扩容，一旦超过设定的threshold，那么就要重新增大数组尺寸，此时所有元素都需要重新计算应该放置的下标。

扩容、rehash

上面为扩容的方法，可以看到，实际上扩容就是新建了一个数组，同时调用了transfer方法，给新数组赋值后覆盖掉原来的table。那我们来看看transfer里面发生了什么：

从代码上可以看出，原来链表的元素有可能已经不在原来的数组上，也就是元素都被重新排到数组上了。

图解rehash

扩容前的结构：

在transfer方法中，对原来的table进行遍历重排序，我们来模拟一下这个过程。重新排序的关键在于，数组长度变了以后，重新计算得出的下标，这与哈希算法有关，为了便于理解，我们简单地认为本HashMap的哈希算法为用key 去mod数组的长度，这也是理解transfer如何重新排列链表的关键。

这是第一次循环后的结果：

第二步：

继续遍历，最终结果如下

以上就是在单线程下，重新排列后的链表。

多线程下的rehash

我们从上文看到，单线程下的rehash是完全没有问题的，那么在多线程下会出现什么问题呢？我们仍然用清晰明了的图来做演示

首先，我们假设有两个进程同时进行put操作，且让HashMap进行扩容，同时进入transfer方法

此时的状态如下：

然后线程2完成了transfer方法，如下

此时，又回到线程1，但此时，完成第一次循环过程：

继续进行下一次循环：

然后e = next = key(3),再继续下一次循环：

当执行完：

e.next = newTable[3];

newTable[3] = e;

时，至此，循环链表形成了。