点击上方蓝字关注我！
jdk1.7 hashmap的循环依赖问题是面试经常被问到的问题，如何回答不好，可能会被扣分。今天我就带大家一下梳理一下，这个问题是如何产生的，以及如何解决这个问题。
一、hashmap的数据结构
先一起看看jdk1.7 hashmap的数据结构
数组 + 链表
hashmap会给每个元素的key生成一个hash值，然后根据这个hash值计算一个在数组中的位置i。i不同的元素放在数组的不同位置，i相同的元素放在链表上，最新的数据放在链表的头部。
往hashmap中保存元素会调用put方法，获取元素会调用get方法。接下来，我们重点看看put方法。
二、put方法
重点看看put方法
public V put(K key, V value) {
再看看addEntry方法
void addEntry(int hash, K key, V value, int bucketIndex) {
看看resize是如何扩容的
void resize(int newCapacity) {
出问题的就是这个transfer方法
void transfer(Entry[] newTable, boolean rehash) {
我来给大家分析一下，为什么这几个代码是头插法，网上很多技术文章都没有说清楚。
三、头插法
我们把目光聚焦到这几行代码：
//获取下一个元素，记录到一个临时变量，以便后面使用
假设刚开始hashMap有这些数据
调用put方法需要进行一次扩容，刚开始会创建一个空的数组，大小是以前的2倍，如图所示：
开始第一轮循环：
//next= 7 e = 3 e.next = 7
执行完之后，第一轮循环之后数据变成这样的
再接着开始第二轮循环：
//next= 5 e = 7 e.next = 5
上面会构成一个新链表，连接的顺序正好反过来了。
由于第二次循环时，节点key=7的元素插到相同位置上已有元素key=3的前面，所以说是采用的头插法。
四、死循环的产生
接下来重点看看死循环是如何产生的？
假设数据跟元素数据一致，有两个线程：线程1 和 线程2，同时执行put方法，最后同时调用transfer方法。
线程1 先执行，到 Entry<K,V> next = e.next; 这一行，被挂起了。
//next= 7 e = 3 e.next = 7
此时线程1 创建的数组会创建一个空数组
接下来，线程2开始执行，由于线程2运气比较好，没有被中断过，执行完毕了。
过一会儿，线程1被恢复了，重新执行代码。
//next= 7 e = 3 e.next = 7
这时候线程1的数组会变成这样的
再执行第二轮循环，此时的e=7
//next= 3 e = 7 e.next = 3
这里特别要说明的是 此时e=7，而e.next为什么是3呢？
因为hashMap的数据是公共的，还记得线程2中的生成的数据吗？
此时e=7，那么e.next肯定是3。
经过上面第二轮循环之后，线程1得到的数据如下：
此时由于循环判断还没有退出，判断条件是： while(null != e)，所以要开始第三轮循环：
//next= null e = 3 e.next = null
由于e=null，此时会退出循环，最终线程1的数据会是这种结构：
key:3 和 key:7又恢复了刚开始的顺序，但是他们的next会相互引用，构成环形引用。
注意，此时调用hashmap的get方法获取数据时，如果只是获取循环链上key:3 和 key:7的数据，是不会有问题的，因为可以找到。就怕获取循环链上没有的数据，比如：key:11，key:15等，会进入无限循环中导致CPU使用率飙升。
五、如何避免死循环
为了解决这个问题，jdk1.8把扩容是复制元素到新数组由 头插法 改成了 尾插法 。此外，引入了红黑树，提升遍历节点的效率。在这里我就不过多介绍了，如果有兴趣的朋友，可以关注我的公众号，后面会给大家详细分析jdk1.8的实现，以及 jdk1.7、jdk1.8 hashmap的区别。
此外，HashMap是非线程安全的，要避免在多线程的环境中使用HashMap，而应该改成使用ConcurrentHashMap。
所以总结一下要避免发生死循环的问题的方法：
升级jdk到1.8以上
改成ConcurrentHashMap
如果这篇文档对您有所帮助的话，麻烦关注一下我的公众账号：苏三说技术，或者帮忙点赞或转发，坚持原创不易，您的支持是我坚持最大的动力。后面我会分享更多更实用的干货，谢谢大家的支持。
本文分享自微信公众号 - 苏三说技术（gh_9f551dfec941）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
