HashMap多线程下的循环链表问题-CSDN博客

文章目录

问题背景
原因
问题复现与分析
- HashMap 的扩容机制
- 多线程下的问题
如何避免这个问题
总结

大家好，今天来聊聊 Java 中一个经典的并发问题：HashMap 在多线程环境下的循环链表问题。这个问题在面试中经常被提到，也是在实际项目中容易踩的坑。如果你对 Java 集合类有兴趣，尤其是 HashMap 的内部实现，这篇文章应该能帮到你。

问题背景

HashMap 是 Java 集合框架中最常用的数据结构之一，它基于哈希表实现，允许 null 键和 null 值，在单线程环境下性能优秀。但 HashMap 不是线程安全的，这意味着在多线程并发访问时，可能会出现各种问题。其中，最著名的就是扩容（resize）过程中可能形成的循环链表，导致 CPU 飙升或无限循环。

原因

简单来说，HashMap 在容量不足时会进行扩容，这个过程涉及链表的转移（rehash）。在单线程下一切正常，但多线程下，如果多个线程同时触发扩容，链表的指针可能会被乱序调整，形成环状结构。

问题复现与分析

HashMap 的扩容机制

先回顾一下 HashMap 的工作原理（以 JDK 1.7 为例，因为这个问题在 JDK 1.7 中最明显，JDK 1.8 后虽有优化，但仍不推荐多线程使用）：

HashMap 内部用数组 + 链表存储元素。
当元素数量超过负载因子（默认 0.75）时，会扩容到原容量的 2 倍。
扩容时，需要将旧数组的元素重新哈希到新数组中。

关键代码在 resize() 方法中，转移链表的逻辑是这样的（简化版）：

void transfer(Entry[] newTable) {
    Entry[] src = table; // 旧数组
    int newCapacity = newTable.length;
    for (int j = 0; j < src.length; j++) {
        Entry e = src[j];
        if (e != null) {
            src[j] = null;
            do {
                Entry next = e.next; // 保存下一个节点
                int i = indexFor(e.hash, newCapacity); // 计算新位置
                e.next = newTable[i]; // 头插法插入
                newTable[i] = e;
                e = next; // 移动到下一个
            } while (e != null);
        }
    }
}

这里用的是头插法：新链表的顺序会反转旧链表。

多线程下的问题

假设有两个线程 A 和 B 同时对 HashMap 进行 put 操作，并触发扩容。

线程 A 开始转移链表：假设链表是 A -> B -> C（A.next = B, B.next = C）。
线程 A 执行到 Entry next = e.next; 时，被挂起。
线程 B 完成扩容，将链表转移到新数组，但由于头插法，新链表变成 C -> B -> A。
线程 A 恢复，继续执行，但此时旧链表已被 B 修改，指针混乱，最终可能形成 A -> B -> A 的循环。

结果：当 get 操作遍历这个链表时，会陷入无限循环，CPU 占用 100%。

如何避免这个问题

既然 HashMap 不线程安全，我们有几种解决方案：

使用 ConcurrentHashMap：这是首选。它支持高并发读写，通过分段锁（JDK 1.7）或 CAS + synchronized（JDK 1.8）实现线程安全，且性能比 Hashtable 高。

示例：
```
ConcurrentHashMap<String, String> map = new ConcurrentHashMap<>();
map.put("key", "value");
```
使用 Hashtable：老牌线程安全 Map，但全表锁导致性能低下，不推荐新项目使用。
手动同步：对 HashMap 加锁，比如用 Collections.synchronizedMap(new HashMap<>())，但锁粒度大，效率不高。