之前参加阿里的性能挑战大赛，需要使用缓存，我就采用了HashMap对数据进行缓存，可运行了一段时间电脑爆卡，我查了一下，可能是死循环问题，就用 jstack dump 了当时的线程快照，发现这次死循环问题的起源是 HashMap 的 get()方法。今天总结一下。
这次事故的原因是因为开发时没有注意到 HashMap 是非线程安全的，而使用 HashMap 的那个地方又是千万数据级别的代码，我就使用了多线程处理，多线程并发非常容易出现问题。
这里需要了解一下HashMap的底层实现原理，我之前转载过一篇：《HashMap的实现原理总结》
我们知道，如果要造成死循环，肯定和链表链表有关，因为只有链表才有指针。其实，关键就在于rehash过程。在前面我们说了是HashMap的get()方法造成的死锁。既然是 get()造成的死锁，一定是跟put()进去元素的位置有关，所以我们从 put()方法开始看起。
进入addEntry()方法：
在addEntry()方法中，有个扩容函数resize()，进入：
重点就在这个transfer()中：
经过这几步，我们会发现转移的时候是逆序的。假如转移前链表顺序是1->2->3，那么转移后就会变成3->2->1。这时候就有点头绪了，死锁问题不就是因为1->2的同时2->1造成的吗？所以，HashMap 的死锁问题就出在这个transfer()函数上。当然，单线程是不会有任何问题的，多线程并发才会出问题。
下面分析可能出现的情况：
假设原来oldTable里存放a1,a2的hash值是一样的，那么entry链表顺序是：
P1:oldTable[i]->a1->a2->null P2:oldTable[i]->a1->a2->null
线程P1运行到上面595行时，e=a1(a1.next=a2),继续运行到597行时，next=a2。这个时候切换到线程P2，线程P2执行完这个链表的循环。如果恰a1,a2在新的table中的hash值又是一样的，那么此时的链表顺序是：
主存:newTable[i]->a2->a1->null
注意这个时候，a1,a2连接顺序已经反了。现在cpu重新切回P1，在第602行以后：e.next = newTable[i];即： a1.next=newTable[i];
newTable[i]=a1;
e=a2;
开始第二次while循环(e=a2,next=a1)：
a2.next=newTable[i];//也就是a2.next=a1
newTable[i]=a2
e=a1
开始第三次while循环（e=a1,next=null）
a1.next=newTable[i];//也就是a1.next=a2
这个时候a1.next=a2,a2.next=a1,形成回环了，这样就造成了死循环，在get操作的时候next永远不为null，造成死循环。
put()过程造成了环形链表，但是它没有发生错误。一旦再调用get()就悲剧了。
可以看到很偶然的情况下会出现死循环，不过一旦出现后果是非常严重的，多线程的环境还是应该用ConcurrentHashMap。
启示：
一、单线程改造为多线程真的不是想象中那么容易，而且性能不一定会提高，反而会出现各种问题
二、ReHash的代价
ReHash的代价实在很大，我们平常理解中的哈希表是“以空间换时间的一种数据结构”。这样说的太久了，大家可能会有一种直观上的错觉，就是哈希表牺牲的是空间，争取的是时间。
但是，ReHash的过程其实是空间和时间的双重重大损失，因为分析源代码，我们知道ReHash的过程其实就是一个动态扩容的过程，而哈希表的扩容是个空间和时间消耗都非常惊人的内部操作。
为什么说ReHash是个空间和时间消耗都非常惊人的内部操作呢？
1、原来当我们对哈希结构的容器进行扩容时，散列表内部要重新new一个更大的数组，然后把原来数组的内容拷贝到新数组，并进行重新散列；
2、new出来的这个更大的新数组容量有多大，一般来说新数组的大小会设置成原数组双倍大小
从1和2这两点可以看出，ReHash的代价确实非常高。
至于我们平时所理解的“以空间换时间“，其实是指哈希具有O(1)复杂度的数据检索效率，但它受填充因子影响，空间开销通常很大，空间利用率不高。
所以我们常常说哈希表适用于读操作频繁，写操作较少应用场景，比如把哈希表当做缓存容器。
————————————————
原文链接：https://blog.csdn.net/u010010428/java/article/details/52042644