HashMap是Java开发中常用的集合类，默认情况下它不是线程安全的，在多线程并发操作尤其是触发扩容的场景下，很容易出现不可预期的问题，其中CPU 100%就是非常典型的一种故障表现，核心原因和扩容过程中的指针环路有关。
HashMap扩容的基本逻辑
HashMap在元素数量超过阈值（容量*负载因子，默认负载因子0.75）时会触发扩容，核心流程是创建一个新的更大的数组，然后把旧数组中的元素重新哈希分配到新数组中。单线程下的扩容逻辑是稳定的，关键代码逻辑如下：
// 简化的HashMap扩容转移节点逻辑
void transfer(Entry[] newTable) {
Entry[] src = table;
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) {
Entry<K,V> e = src[j];
if (e != null) {
src[j] = null;
do {
Entry<K,V> next = e.next; // 记录当前节点的下一个节点
int i = indexFor(e.hash, newCapacity); // 计算新数组下标
e.next = newTable[i]; // 头插法插入新数组
newTable[i] = e;
e = next; // 处理下一个节点
} while (e != null);
}
}
}
这里使用的是头插法转移节点，也就是新插入的节点会放在链表的头部，这个特性是后续多线程下出现指针环路的重要前提。
多线程并发扩容的指针环路形成过程
假设现在有两个线程A和线程B同时触发HashMap扩容，初始状态下旧数组某个位置的链表是a->b->null，两个线程都执行到记录next节点的步骤：
- 线程A执行到
Entry<K,V> next = e.next，此时e是a，next记录为b，然后线程A被挂起 - 线程B完成整个扩容流程，由于头插法，新数组中对应位置的链表会变成
b->a->null - 线程A恢复执行，此时它持有的e还是a，next还是b，按照原来的逻辑继续处理：先把a插入新数组，此时新数组该位置是
a->null，然后e变成b - 线程A继续处理b节点，此时记录b的next，因为线程B已经把b的next改成了a，所以next变成a，然后把b插入新数组头部，新数组该位置变成
b->a->null，接着e变成a - 线程A处理a节点，记录a的next，此时a的next是null，然后把a插入新数组头部，新数组该位置变成
a->b->a，形成了a指向b，b指向a的环路
指针环路导致CPU 100%的原因
当扩容完成后，这个位置的链表已经形成了环路，后续如果有查询操作需要遍历这个位置的链表，就会陷入死循环：
// 简化的HashMap查询逻辑
final Entry<K,V> getEntry(Object key) {
int hash = (key == null) ? 0 : hash(key.hashCode());
for (Entry<K,V> e = table[indexFor(hash, table.length)]; e != null; e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k))))
return e;
}
return null;
}
遍历的时候e会不断在a和b之间切换，永远无法满足e == null的退出条件，这个循环会一直执行，持续消耗CPU资源，最终导致CPU占用率飙升到100%。
如何避免这类问题
要避免HashMap多线程下的并发问题，最直接的方式是替换线程安全的集合类：
- 如果是并发场景，优先使用
ConcurrentHashMap，它采用了分段锁或者CAS+synchronized的方式保证线程安全，同时避免了扩容时的指针环路问题 - 如果不需要高并发，只是偶尔有多线程访问，也可以使用
Collections.synchronizedMap包装HashMap，保证操作的原子性 - 尽量避免在多线程环境下使用非线程安全的HashMap，尤其是在会触发扩容的写操作场景下
理解HashMap的扩容机制和线程不安全的原因，能够帮助我们在开发中合理选择集合类，避免类似的线上故障。