前言：我们都知道HashMap是线程不安全的，在多线程环境中不建议使用，但是其线程不安全主要体现在什么地方呢，本文将对该问题进行解密。
1.jdk1.7中的HashMap
HashMap 死循环是一个比较常见、比较经典的问题，在日常的面试中出现的频率比较高，所以接下来咱们通过图解的方式，带大家彻底理解死循环的原因。
前置知识
死循环问题发生在 JDK 1.7 版本中，造成这个问题主要是由于 HashMap 自身的运行机制，加上并发操作，从而导致了死循环。在 JDK 1.7 中 HashMap 的底层数据实现是数组 + 链表的方式，如下图所示：
而 HashMap 在数据添加时使用的是头插入，如下图所示：
HashMap 正常情况下的扩容实现如下图所示：
旧 HashMap 的节点会依次转移到新 HashMap 中，旧 HashMap 转移的顺序是 A、B、C，而新 HashMap 使用的是头插法，所以最终在新 HashMap 中的顺序是 C、B、A，也就是上图展示的那样。有了这些前置知识之后，咱们来看死循环是如何诞生的？
死循环执行步骤1
死循环是因为并发 HashMap 扩容导致的，并发扩容的第一步，线程 T1 和线程 T2 要对 HashMap 进行扩容操作，此时 T1 和 T2 指向的是链表的头结点元素 A，而 T1 和 T2 的下一个节点，也就是 T1.next 和 T2.next 指向的是 B 节点，如下图所示：
死循环执行步骤2
死循环的第二步操作是，线程 T2 时间片用完进入休眠状态，而线程 T1 开始执行扩容操作，一直到线程 T1 扩容完成后，线程 T2 才被唤醒，扩容之后的场景如下图所示：图片从上图可知线程 T1 执行之后，因为是头插法，所以 HashMap 的顺序已经发生了改变，但线程 T2 对于发生的一切是不可知的，所以它的指向元素依然没变，如上图展示的那样，T2 指向的是 A 元素，T2.next 指向的节点是 B 元素。
死循环执行步骤3
当线程 T1 执行完，而线程 T2 恢复执行时，死循环就建立了，如下图所示：
因为 T1 执行完扩容之后 B 节点的下一个节点是 A，而 T2 线程指向的首节点是 A，第二个节点是 B，这个顺序刚好和 T1 扩完容完之后的节点顺序是相反的。T1 执行完之后的顺序是 B 到 A，而 T2 的顺序是 A 到 B，这样 A 节点和 B 节点就形成死循环了，这就是 HashMap 死循环导致的原因。
解决方案
HashMap 死循环的常用解决方案有以下 3 个：
使用线程安全容器 ConcurrentHashMap 替代（推荐使用此方案）。
使用线程安全容器 Hashtable 替代（性能低，不建议使用）。
使用 synchronized 或 Lock 加锁 HashMap 之后，再进行操作，相当于多线程排队执行（比较麻烦，也不建议使用）。
总结
HashMap 死循环发生在 JDK 1.7 版本中，形成死循环的原因是 HashMap 在 JDK 1.7 使用的是头插法，头插法 + 链表 + 多线程并发 + HashMap 扩容，这几个点加在一起就形成了 HashMap 的死循环，解决死锁可以采用线程安全容器 ConcurrentHashMap 替代。
2.jdk1.8中HashMap
在jdk1.8中对HashMap进行了优化，在发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程的情况下仍然不安全，这里我们看jdk1.8中HashMap的put操作源码：
1 final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
2 boolean evict) {
3 Node<K,V>[] tab; Node<K,V> p; int n, i;
4 if ((tab = table) == null || (n = tab.length) == 0)
5 n = (tab = resize()).length;
6 if ((p = tab[i = (n - 1) & hash]) == null) // 如果没有hash碰撞则直接插入元素
7 tab[i] = newNode(hash, key, value, null);
8 else {
9 Node<K,V> e; K k;
10 if (p.hash == hash &&
11 ((k = p.key) == key || (key != null && key.equals(k))))
12 e = p;
13 else if (p instanceof TreeNode)
14 e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
15 else {
16 for (int binCount = 0; ; ++binCount) {
17 if ((e = p.next) == null) {
18 p.next = newNode(hash, key, value, null);
19 if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
20 treeifyBin(tab, hash);
21 break;
22 }
23 if (e.hash == hash &&
24 ((k = e.key) == key || (key != null && key.equals(k))))
25 break;
26 p = e;
27 }
28 }
29 if (e != null) { // existing mapping for key
30 V oldValue = e.value;
31 if (!onlyIfAbsent || oldValue == null)
32 e.value = value;
33 afterNodeAccess(e);
34 return oldValue;
35 }
36 }
37 ++modCount;
38 if (++size > threshold)
39 resize();
40 afterNodeInsertion(evict);
41 return null;
42 }这是jdk1.8中HashMap中put操作的主函数， 注意第6行代码，如果没有hash碰撞则会直接插入元素。如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，所以这线程A、B都会进入第6行代码中。假设一种情况，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，问题出现：线程A会把线程B插入的数据给覆盖，发生线程不安全。
这里只是简要分析下jdk1.8中HashMap出现的线程不安全问题的体现，后续将会对java的集合框架进行总结，到时再进行具体分析。
总结
首先HashMap是线程不安全的，其主要体现：
#1.在jdk1.7中，在多线程环境下，扩容时会造成环形链或数据丢失。
#2.在jdk1.8中，在多线程环境下，会发生数据覆盖的情况。
