再次翻到以前工作中遇到的一个问题，HashMap在多线程下会出现死循环的问题，以前只是知道会死循环，导致CPU100%把机器拖跨，今天来彻底看看
首先来看下，HashMap的原理：HashMap是一个数组，对key使用hash算法计算出数组对应的下标i，然后把<key, value>插到table[i]，如果两个不同的key被算在同一个i，那就出现冲突，又叫碰撞，这样就会在table[i]上形成一个链表；总结下来HashMap是一个数组+链表组成的数据结构；
我们知道，在往HashMap里put元素的时候，会有一个key，我们先会取到这个key的下标，实际上是key对应类型的hashCode()方法，而HashCode又是什么呢？
提到HashCode，首先我们要了解到一种数据结构，散列表(HashTable，也叫哈希表），是根据关键码值(Key Value)而直接进行访问的数据结构，也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做散列函数，存放记录的数组叫做散列表。
散列函数能使对一个数据序列的访问过程更加迅速有效，通过散列函数，数据元素将被更快定位。
Java中的hashCode方法就是根据一定的规则将与对象相关的信息（比如对象的存储地址，对象的 字段等）映射成一个数值，这个数值称作为散列值。
再回来看看，HashCode对应的就是关键码值的Key，然后我们把Java代码中String的hashCode计算代码撸出来看看：
算出来的hashCode，实际上是根据字符的值进行计算，假设我们要计算“abc”的hashCode，收计算出来是多少呢？
a对应的int值是97，b=98，c=99；那么根据以上算式计算出来的结果应该是：31 * (31 * (31 * 0 + 97) + 98) + 99
结果是多少不重要，但是我们看的出来，这个字符串的hashCode肯定是唯一的，因为每个字符对应的值是不一样的，算出来肯定不一样
理解了上面的过程，我们再来看看多线程下面的死锁的问题，有很多文章 写的很复杂，总结下来需要满足以下几个条件：
- 两个线程在对同一个hashMap进行处理
- put数据的时候产生了冲突，就是在table[i]上需要存储多个元素（即一个链表）,冲突太多，执行效率就会下降，所以数组大小的设定很重要
- 现在假设出现冲突比较厉害的时候，这个时候需要对HashMap进行重组，即容量增加，用以减少冲突
- 这个时候需要将老的HashMap的元素重新拷贝（实际上不是拷贝，而只是重新引用地址，不new新对象）到新的HashMap中，在table[i]上存储多个元素的时候，两线程同时进行，导致链表出现循环链表即：A->B && B->A
- 假设现有的链表数据是A->B->null
- 第一个线程执行时e=A，next=B，暂停
- 第二个线程执行新链表执行完成，数据为B->A->null；
- 此时第一个线程继续执行
- 第一次循环的时候是A->null，
- 第二次循环的时候是B->A->null，
- 由于第二个线程已经修改了链表的结构(B->A->null)，此时取B的next的时候，取到的是A
- 将A放到新数组中，结构为：A->B->A；此时老的链表取的的e = null，结束循环
- 此时链表已形成A<->B
- 出现循环链表之后，触发条件是在get循环链表中的数据时，出现无限循环，导致CPU被耗尽，机器挂掉
在理解这个问题的时候有很重要一点，当多个线程在执行时，每个线程都会定义一个table对象，假设是两个线程在执行，那么这里有三个table
- 老的table
- 线程1的table
- 线程2的table
但是表里的链表是引用类型的，即地址是一样的，对链表做变更的时候，会影响全局Map;
这里面有几个点：每个table都是引用类型，而表里面的每个链表结构元素也是引用类型，改变了引用类型的结构是全局的改变，不单是一个线程的变量；
解决办法：
- 在使用HashMap的时候，不要在多线程的环境中使用，如果需要使用，可以使用ConcurrentHashMap
- 确实要使用的时候使用synchronized关键字
后记：在前面讨论的时候我们看到，如果在hashMap里面将老的元素拷贝到新的表上去时，就不会出现死循环了，但是又会出现新的问题，元素永远不一致，因为各个线程上的值不一致，所以在多线程中使用集合类型时一定要注意线程安全问题
参考文章：
浅谈Java中的hashcode方法：http://www.cnblogs.com/dolphin0520/p/3681042.html
疫苗：JAVA HASHMAP的死循环：https://coolshell.cn/articles/9606.html
这个例子更加清晰，我是看这个看懂的：https://blog.csdn.net/zhuqiuhui/article/details/51849692
