# 并发容器:HashMap死循环形成的原因是什么?

# 介绍
HashMap 死循环主要发生在 JDK 1.7 及以前的版本中,其根本原因在于:在多线程并发扩容时,HashMap 使用的“头插法”倒序迁移链表节点,导致链表形成了环形结构(
当后续对该位置进行 get() 或 put() 操作遍历此链表时,CPU 就会陷入 while(e != null) 的死循环,占用率飙升至 100%
void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}
Entry[] newTable = new Entry[newCapacity];
transfer(newTable, initHashSeedAsNeeded(newCapacity));
table = newTable;
threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}
发生的具体时机在transfer函数中,默认情况下rehash为false
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
# 正常的transfer过程
例子不考虑扩容阈值,假设放4个元素时开始扩容

主要有2个有意思的地方
- 原来在oldTable[i]位置的元素,会被放到newTable[i]或者newTable[i+oldTable.length]的位置
- 链表在复制的时候会反转
# 并发下异常的transfer
假设线程1执行完Entry<K,V> next = e.next后被挂起,此时e指向key3,next指向key7
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next; // 线程1执行完这一句被挂起
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}

线程2也来执行transfer函数,并执行完成,此时的状态为

此时线程1接着执行余下的代码,将key3放到线程1的table[3]处

接着将e指向key7,不为null,再次进入循环,将next指向key3如下图

当跑完这次循环时key7被放入线程1的table中,e指向key3,next指向null

e不为null,还能再次执行循环,key3再次插入线程1中table[3]的头节点,此时e变为null,循环完毕。结构如下

环形链表形成,此时无论将线程1还是线程2的table设置为newTable,当调用get方法执行到这条链上时,死循环形成
JDK 1.8 对 HashMap 的扩容机制进行了重大改进,改用尾插法,彻底解决了死循环问题
尾插法:保持链表中元素的相对顺序不变(原序迁移),不再翻转链表