为什么HashMap集合在多线程操作扩容时会出现死循环问题：

---

前言

HashMap 的死循环问题只在 JDK1.7 版本中会出现，主要是 HashMap 自身的工作机制，再加上并发操作，从而导致出现死循环。JDK1.8 以后，官方彻底解决了这个问题。

---

一、数据插入原理：

由于 JDK 1.7 中 HashMap 的底层存储结构采用的是数组 加 链表的方式。
而 HashMap 在数据插入时又采用的是头插法，也就是说新插入的数据会从链表的头节点进行插入。

因此，HashMap 正常情况下的扩容就是是这样一个过程。
我们来看，旧 HashMap 的节点会依次转移到新的 HashMap中，旧 HashMap转移链表元素的顺序是A、B、C，而新 HashMap使用的是头插法插入，所以，扩容完成后最终在新 HashMap中链表元素的顺序是 C、B、A。

二、导致死循环的原因：

第一步： 线程启动，有线程 T1 和线程 T2 都准备对HashMap 进行扩容操作，此时 T1 和 T2 指向的都是链表的头节点 A，而 T1 和 T2 的下一个节点分别是 T1.next 和 T2.next，它们都指向 B 节点。

第二步： 开始扩容，这时候，假设线程 T2 的时间片用完，进入了休眠状态，而线程 T1 开始执行扩容操作，一直到线程 T1 扩容完成后，线程 T2 才被唤醒。因为 HashMap 扩容采用的是头插法，线程 T1 执行之后，链表中的节点顺序发生了改变。但线程 T2 对于发生的一切还是不可知的，所以它指向的节点引用依然没变。如图所示，T2 指向的是 A 节点，T2.next 指向的是 B 节点。

当线程 T1 执行完成之后，线程 T2 恢复执行时，死循环就发生了。

因为 T1 执行完扩容之后，B 节点的下一个节点是 A，而T2 线程指向的首节点是 A，第二个节点是 B，这个顺序刚好和 T1 扩容之前的节点顺序是相反的。T1 执行完之后的顺序是 B 到 A，而 T2 的顺序是 A 到 B，这样 A 节点和 B 节点就形成了死循环。

三、解决方案：

避免 HashMap 发生死循环的常用解决方案有三个：

1)、使用线程安全的 ConcurrentHashMap 替代 HashMap，个人推荐使用此方案。

2)、使用线程安全的容器 Hashtable 替代，但它性能较低，不建议使用。

3. 、使用 synchronized 或 Lock 加锁之后，再进行操作，相当于多线程排队执行，也会影响性能，不建议使用。

四、总结：

HashMap 死循环只发生在 JDK1.7 版本中，主要原因是JDK1.7 中的 HashMap，在头插法 加 链表 加 多线程并发 加 扩容这几个情形累加到一起就会形成死循环。多线程环境下建议采用 ConcurrentHashMap 替代。在 JDK1.8 中，HashMap 改成了尾插法，解决了链表死循环的问题