首先小伙伴要明确：死循环问题在JDK 1.8 之前是存在的，JDK 1.8 通过增加loHead和loTail进行了修复。
在JDK 1.7及之前 HashMap在并发情况下导致循环问题，致使服务器cpu飙升至100%，那么今天就来解析一下线程不安全的HashMap在高并发的情况下是如何造成死循环的。
要探究hashmap死循环的原因 首先要知道hashmap的源码 这样才能从根本上对hashmap进行理解 。
首先hashmap进行元素的插入，在元素个数达到阀值时：
首先小伙伴要明确：死循环问题在JDK 1.8 之前是存在的，JDK 1.8 通过增加loHead和loTail进行了修复。
在JDK 1.7及之前 HashMap在并发情况下导致循环问题，致使服务器cpu飙升至100%，那么今天就来解析一下线程不安全的HashMap在高并发的情况下是如何造成死循环的。
要探究hashmap死循环的原因 首先要知道hashmap的源码 这样才能从根本上对hashmap进行理解 。
首先hashmap进行元素的插入，在元素个数达到阀值时：
addEntry对判断桶有没有达到阀值，达到阀值就会走resize方法：
resize方法里调用transfer方法转移元素：
下面这个方法就是出现死循环的方法了，下面请听我一一道来：
添加元素达到阀值后对hashmap进行扩容，走reaize方法，在对hashmap进行扩容时，又会调用一个transfer对旧的hashmap中的元素进行转移,那么我们今天要探究的死循环问题 就是发生在这个方法里的，在进行元素转移时transfer方法里会调用下面四行代码 :
Entry<k,v> next = e.next;
e.next = newTable[i];
newTable[i] = e;
e = next;把元素插入新的hashmap中，粗略的看下这四行代码 似乎并没有什么问题 元素进行转移的图如下（线程不冲突的情况下）：
那么当多线程（A、B线程）同时访问我们这段代码时：
现在A线程执行到以下代码时：
Entry<k,v> next = e.next;线程A交出时间片，线程B这时候接手转移并且完成了元素的转移，这个时候线程A又拿到时间片并接着执行代码：
执行后代码如图，当e = a时，这时候这时候再执行：
e.next = newTable[i];// a元素指向了b元素 产生循环
这样链表就就产生了循环，在get元素的时候，线程会一直在环了遍历，无法跳出，从而导致cpu飙升！
总结：在多线程情况下尽量不要用HashMap，可以用ConcurrentHashMap代替。
