HashMap 1.7多线程死循环问题：从链表反转看并发陷阱

最近在技术社区看到一个高频面试题："HashMap 1.7为什么会在多线程环境下出现死循环？"这个问题看似简单，却涉及Java集合框架的底层实现和并发编程的核心痛点。今天我们就用工程师的视角，通过流程图解+代码分析的方式，彻底拆解这个经典问题。

1. 问题背景与前置知识

HashMap作为Java中最常用的数据结构之一，在1.7版本采用数组+链表的实现方式。当发生哈希冲突时，新元素会以头插法的方式插入链表头部。这种设计在单线程环境下效率很高，但在并发场景下却暗藏杀机。

先看几个关键概念：

• 负载因子：默认0.75，当元素数量超过容量*负载因子时触发扩容
• rehash：扩容时需要重新计算所有元素在新数组中的位置
• 头插法：新节点总是插入链表头部，与1.8之后的尾插法形成对比

java复制// JDK 1.7中的transfer方法关键代码
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);
        }
    }
}

2. 死循环产生的具体场景

假设我们有一个初始容量为2的HashMap，当前状态如下：

现在有两个线程同时执行put操作并触发扩容，我们来看并发冲突的具体过程：

2.1 初始状态

• 线程1和线程2都进入transfer方法
• 当前处理桶1，链表为A→B→null
• 两个线程都执行到Entry<K,V> next = e.next后被挂起

此时内存状态：

code复制线程1：e = A, next = B
线程2：e = A, next = B

2.2 线程2先执行完成

线程2完整执行transfer后，新表的桶1链表变为B→A→null：

2.3 线程1恢复执行

此时线程1恢复执行，但关键的是：

• 线程1的局部变量e和next仍保留挂起前的值（e=A, next=B）
• 但此时newTable[1]已经被线程2修改为B→A→null

执行流程如下：

java复制e.next = newTable[i];  // A.next = B→A (形成环)
newTable[i] = e;       // newTable[1] = A→B→A
e = next;              // e = B

接下来的循环中：

java复制// 第二轮循环
Entry<K,V> next = e.next;  // B.next = A
e.next = newTable[i];      // B.next = A→B
newTable[i] = e;           // newTable[1] = B→A→B
e = next;                  // e = A

// 第三轮循环
Entry<K,V> next = e.next;  // A.next = B
e.next = newTable[i];      // A.next = B→A
newTable[i] = e;           // newTable[1] = A→B→A
e = next;                  // e = B

这样无限循环下去，最终形成A→B→A→B...的环形链表。

3. 问题本质与解决方案

这个问题的根源在于头插法+多线程并发修改的组合：

1. 头插法会反转链表顺序
2. 线程挂起时保留的局部变量与共享内存不一致
3. 没有同步机制保证可见性和原子性

解决方案对比：

实际开发中，ConcurrentHashMap是最推荐的解决方案，它在1.7版本采用分段锁，1.8改为CAS+synchronized，性能表现优异。

4. 问题复现与验证

如果想亲眼见证这个死循环，可以编写以下测试代码：

java复制public class HashMapDeadLoop {
    final static HashMap<Integer, Integer> map = new HashMap<>(2);
    
    public static void main(String[] args) throws InterruptedException {
        map.put(3, 3);
        map.put(7, 7);  // 这两个key会哈希冲突
        
        new Thread(() -> {
            map.put(15, 15);
        }, "Thread-1").start();
        
        new Thread(() -> {
            map.put(11, 11);
        }, "Thread-2").start();
    }
}

运行后可能出现以下症状：

• CPU占用率飙升
• 使用jstack查看线程状态会发现线程卡在HashMap.get()方法
• 内存dump显示链表形成环状结构

5. 面试深度思考

当面试官提出这个问题时，他们通常希望考察：

1. 对HashMap底层实现的熟悉程度
2. 多线程编程的实践经验
3. 分析复杂问题的逻辑能力

建议回答时采用"现象→原理→解决方案"的结构：

1. 先说明现象：多线程扩容可能导致死循环
2. 通过画图展示具体形成过程
3. 分析根本原因是头插法+缺乏同步
4. 给出解决方案和选型建议

常见误区：

• 只描述现象不解释原理
• 混淆1.7和1.8的实现差异
• 无法准确描述线程切换的关键点

在准备这类问题时，最好的方式就是像我们今天这样：

1. 手写关键代码片段
2. 绘制线程执行时序图
3. 对比不同版本的实现差异
4. 实际编写测试代码验证