Java面试-HashMap 的线程不安全性及解决方案（ConcurrentHashMap）-CSDN博客

请添加图片描述

👋 欢迎阅读《Java面试200问》系列博客！

🚀大家好，我是Jinkxs，一名热爱Java、深耕技术一线的开发者。在准备和参与了数十场Java面试后，我深知面试不仅是对知识的考察，更是对理解深度与表达能力的综合检验。

✨本系列将带你系统梳理Java核心技术中的高频面试题，从源码原理到实际应用，从常见陷阱到大厂真题，每一篇文章都力求深入浅出、图文并茂，帮助你在求职路上少走弯路，稳拿Offer！

🔍今天我们要聊的是：《HashMap 的线程不安全性及解决方案（ConcurrentHashMap）》。准备好了吗？Let’s go！

🔐 `HashMap` 的线程不安全性深度剖析与 `ConcurrentHashMap` 的终极解决方案

“在多线程的‘迷宫’中，HashMap 如同一位‘独行侠’，
它的‘非线程安全’特性，
让每一次并发访问都充满‘未知的陷阱’。
而 ConcurrentHashMap，
则是一位‘全副武装’的‘守护者’，
用‘分段锁’与‘CAS’的‘利剑’，
为数据安全开辟出一条‘康庄大道’。
今天，就让我们深入这场‘并发战争’，
揭开 HashMap 的‘致命弱点’，
并掌握 ConcurrentHashMap 的‘制胜法宝’！”

📚 目录导航

💥 HashMap 的“三宗罪”：线程不安全的根源
🧩 经典案例：put() 操作的“并发灾难”
🔥 经典案例：resize() 的“并发死循环”（JDK 7）
🛡️ 解决方案一：Collections.synchronizedMap()——“笨重的盔甲”
⚔️ 解决方案二：ConcurrentHashMap——“轻盈的利刃”
🧱 ConcurrentHashMap (JDK 8) 底层揭秘：CAS + synchronized 的“艺术”
🧪 实战性能对比：谁才是真正的“并发王者”？
🧠 面试官最爱问的 5 个“灵魂拷问”
🔚 终章：ConcurrentHashMap 的“并发哲学”

1. `HashMap` 的“三宗罪”：线程不安全的根源

HashMap 在多线程环境下使用，极易导致数据不一致、死循环甚至程序崩溃。其“罪魁祸首”主要有三点：

🔴 罪行一：`size` 的非原子性

size 变量（记录元素个数）没有使用 volatile 修饰，也不是原子操作。
后果：多个线程同时 put 时，size++ 操作可能发生丢失更新，导致 size 值不准确。更严重的是，错误的 size 会错误地触发或延迟 resize()，引发连锁反应。

🔴 罪行二：`put()` 操作的非原子性

put(K key, V value) 操作包含多个步骤：计算 hash -> 找到桶 -> 插入/更新节点。
后果：在多线程环境下，这些步骤可能被交叉执行。例如，线程 A 和 B 同时向同一个桶插入元素，可能导致一个元素被覆盖，或者链表结构被破坏。

🔴 罪行三：`resize()` 的“并发灾难”（尤其在 JDK 7）

resize() 操作本身非常复杂，涉及创建新数组和迁移所有元素。
后果：如果多个线程同时触发 resize()，它们可能同时操作同一个旧数组，导致链表成环，从而在 get() 操作时陷入死循环（CPU 100%）。这是 HashMap 最臭名昭著的并发问题。

💡 核心原因：HashMap 的所有方法都没有任何同步控制（如 synchronized 或 volatile），它假设所有操作都在单线程环境下进行。

2. 经典案例：`put()` 操作的“并发灾难”

设想两个线程 A 和 B 同时向一个空的 HashMap（初始容量 16）插入键值对，且它们的 hashCode 经过计算后都映射到索引 0。

// 初始状态
HashMap<String, Integer> map = new HashMap<>(); // size = 0, table[0] = null

// 线程 A 执行: map.put("A", 1)
// 1. 计算 hash("A") -> 假设 index = 0
// 2. 发现 table[0] 为空
// 3. 创建新节点 Node("A", 1, null)
// 4. 将 table[0] 指向这个新节点
// 5. size++ (size 从 0 变成 1)

// 线程 B 执行: map.put("B", 2)
// 1. 计算 hash("B") -> 假设 index = 0
// 2. 发现 table[0] 为空 (注意：如果线程A的步骤4还没完成，table[0]仍是null)
// 3. 创建新节点 Node("B", 2, null)
// 4. 将 table[0] 指向这个新节点
// 5. size++ (size 从 0 变成 1，但线程A的size++也执行了，最终size=2，但只有一个节点！)

灾难发生：

场景1：如果线程 A 和 B 都在对方完成 table[0] 赋值前，发现 table[0] 为空，它们都会创建自己的节点并尝试赋值给 table[0]。后执行的线程会覆盖先执行的线程的结果，导致一个键值对丢失。
场景2：即使没有覆盖，size++ 的非原子性也可能导致 size 值不准确（例如，最终 size=1，但实际有两个元素）。

3. 经典案例：`resize()` 的“并发死循环”（JDK 7）

这是 HashMap 在 JDK 7 中最恐怖的并发 Bug。虽然 JDK 8 已通过优化避免了此问题，但理解它有助于深刻认识并发风险。

🔧 JDK 7 `resize()` 的迁移逻辑（简化）

JDK 7 在迁移链表时，采用的是头插法（将旧链表的节点逐个插入到新链表的头部）。

// JDK 7 resize 伪代码 (简化)
void transfer(Entry[] newTable) {
    Entry[] src = table;
    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; // 1. 保存下一个节点
                int i = indexFor(e.hash, newCapacity);
                e.next = newTable[i];     // 2. e的next指向新桶的头节点
                newTable[i] = e;          // 3. 新桶头节点指向e
                e = next;                 // 4. e移动到下一个
            } while (e != null);
        }
    }
}

💣 并发死循环是如何产生的？

假设有两个线程（Thread1 和 Thread2）同时触发 resize()，它们操作同一个链表 A -> B -> null。

初始状态：e = A, next = B。
Thread1 执行到 do 循环内：
- next = e.next; -> next = B
- 此时 Thread1 被挂起。
Thread2 完整执行 resize()：
- Thread2 从 e = A 开始。
- 使用头插法，将 A 和 B 迁移到新数组。
- 最终新链表为 B -> A -> null。
- 旧数组 table[j] 被清空。
Thread1 恢复执行：
- e = A (它不知道链表已被 Thread2 修改)
- next = B (从之前保存的变量读取)
- e.next = newTable[i]; -> 此时 newTable[i] 可能是 B（被 Thread2 设置），所以 A.next = B。
- newTable[i] = e; -> newTable[i] = A。
- e = next; -> e = B。
- 进入下一轮循环。
Thread1 继续执行：
- next = e.next; -> e = B, B.next = A (因为 Thread2 迁移后 B.next = A)，所以 next = A。
- e.next = newTable[i]; -> newTable[i] 现在是 A，所以 B.next = A。
- newTable[i] = e; -> newTable[i] = B。
- e = next; -> e = A。
无限循环：现在 A.next = B 且 B.next = A，形成了一个环形链表 A <-> B。当任何线程尝试 get() 一个位于此桶的 key 时，遍历链表会陷入死循环，导致 CPU 100%。

💡 JDK 8 的改进：JDK 8 将头插法改为尾插法，并且利用 (e.hash & oldCap) 优化，将链表拆分为两个子链表整体迁移，从根本上避免了成环的可能性。

4. 解决方案一：`Collections.synchronizedMap()`——“笨重的盔甲”

Java 提供了 Collections.synchronizedMap() 方法，可以将一个普通的 Map 包装成线程安全的版本。

Map<String, Integer> syncMap = Collections.synchronizedMap(new HashMap<>());

🔧 原理

它返回一个 SynchronizedMap 对象。
这个对象的每一个 public 方法（如 get, put, remove）都使用了 synchronized 关键字，锁住的是 SynchronizedMap 对象本身（mutex）。

public V put(K key, V value) {
    synchronized (mutex) { // 锁住整个 map
        return m.put(key, value);
    }
}

⚠️ 缺点

性能低下：全局锁！同一时刻只能有一个线程访问 Map，并发度极低。在高并发场景下，性能甚至不如单线程。
迭代器仍需手动同步：SynchronizedMap 返回的迭代器是弱一致的，不是故障快速的。如果在迭代过程中有其他线程修改了 Map，可能会抛出 ConcurrentModificationException。因此，必须手动同步迭代操作：

Map<String, Integer> m = Collections.synchronizedMap(new HashMap<>());
...
Set<String> s = m.keySet();  // 需要同步的集合
synchronized(m) { // 必须同步 m
    for (String key : s)
        System.out.println(key + ": " + m.get(key));
}

💡 总结：synchronizedMap 是一个“简单粗暴”的解决方案，适用于并发不高或对性能要求不苛刻的场景。它像一件“笨重的盔甲”，虽然能防身，但行动迟缓。

5. 解决方案二：`ConcurrentHashMap`——“轻盈的利刃”

ConcurrentHashMap 是 HashMap 在并发环境下的首选，它专为高并发场景设计。

ConcurrentHashMap<String, Integer> concurrentMap = new ConcurrentHashMap<>();

✅ 核心优势

高并发性能：采用分段锁（JDK 7）或 CAS + synchronized（JDK 8）技术，将锁的粒度降到桶级别，大大提高了并发度。
线程安全：所有操作都是线程安全的，无需额外同步。
支持高并发：设计目标就是应对高并发读写。
丰富的并发工具：提供 putIfAbsent, remove, replace, compute, merge 等原子性复合操作。

6. `ConcurrentHashMap` (JDK 8) 底层揭秘：`CAS + synchronized` 的“艺术”

JDK 8 对 ConcurrentHashMap 进行了彻底重构，放弃了 Segment 分段锁，采用了更轻量级的 CAS（Compare-And-Swap）和 synchronized。

🔧 核心数据结构

与 HashMap 基本一致：Node<K,V>[] table。
新增 volatile Node<K,V>[] nextTable：用于扩容时的新数组。
新增 volatile int sizeCtl：一个重要的控制变量，用于控制初始化和扩容。

🔧 关键机制

1. 初始化 (`initTable`)

使用 sizeCtl 作为锁。sizeCtl 为负数时表示有线程正在初始化或扩容。
通过 CAS 操作竞争初始化权，只有一个线程能成功初始化数组。

2. `put()` 操作 (`putVal`)

计算索引：i = (n - 1) & hash。
检查桶状态：
- 桶为空：使用 CAS 尝试将新节点放入 table[i]。如果成功则结束，失败则说明有竞争，进入下一步。
- 桶被占用：检查该节点是否是 ForwardingNode（表示正在扩容），如果是，则帮助扩容。
- 正常节点：对 table[i] 使用 synchronized 加锁（锁住链表的头节点或红黑树的根节点），然后进行链表遍历、插入或更新。
链表转红黑树：如果链表长度超过 TREEIFY_THRESHOLD (8)，且数组长度大于 MIN_TREEIFY_CAPACITY (64)，则将链表转换为红黑树以提高查找效率。

💡 精髓：CAS 用于无竞争时的快速插入，synchronized 用于有竞争时的细粒度锁。锁的粒度是桶级别（一个链表或一棵树），而不是整个 Map，并发性能极高。

3. 扩容 (`transfer`)

扩容过程更复杂，采用多线程协助扩容机制。
使用 sizeCtl 和 nextTable 控制。
多个线程可以同时迁移不同区间的桶，大大加快了扩容速度。
当一个线程发现当前操作的桶属于一个正在扩容的 Map 时，它会主动帮助完成扩容任务。

4. `get()` 操作

无锁！ get 操作是完全无锁的。
通过 volatile 保证内存可见性。
遍历链表或红黑树查找元素。
这使得 ConcurrentHashMap 的读操作性能几乎与 HashMap 一样快。

7. 实战性能对比：谁才是真正的“并发王者”？

import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ConcurrentMapPerformanceTest {

    private static final int THREAD_COUNT = 10;
    private static final int OPERATIONS_PER_THREAD = 10000;

    public static void main(String[] args) throws InterruptedException {
        // 1. 测试 HashMap (危险！仅用于对比，生产环境禁止)
        // testMapPerformance("HashMap (UNSAFE)", new HashMap<>(), true);

        // 2. 测试 SynchronizedMap
        testMapPerformance("SynchronizedMap",
                Collections.synchronizedMap(new HashMap<>()),
                false);

        // 3. 测试 ConcurrentHashMap
        testMapPerformance("ConcurrentHashMap",
                new ConcurrentHashMap<>(),
                false);
    }

    private static void testMapPerformance(String name, Map<Integer, String> map, boolean unsafe) throws InterruptedException {
        System.out.println("\n=== 测试: " + name + " ===");
        ExecutorService executor = Executors.newFixedThreadPool(THREAD_COUNT);
        CountDownLatch latch = new CountDownLatch(THREAD_COUNT);

        long startTime = System.nanoTime();

        for (int t = 0; t < THREAD_COUNT; t++) {
            final int threadId = t;
            executor.submit(() -> {
                try {
                    // 每个线程执行写操作
                    for (int i = 0; i < OPERATIONS_PER_THREAD; i++) {
                        int key = threadId * OPERATIONS_PER_THREAD + i;
                        map.put(key, "Value-" + key);
                    }
                    // 模拟读操作
                    for (int i = 0; i < OPERATIONS_PER_THREAD / 10; i++) {
                        int key = (int) (Math.random() * (THREAD_COUNT * OPERATIONS_PER_THREAD));
                        map.get(key);
                    }
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();
        executor.shutdown();

        long duration = System.nanoTime() - startTime;
        System.out.println(name + " 总耗时: " + duration / 1_000_000 + " ms");
        System.out.println(name + " 最终大小: " + map.size());
    }
}

输出示例（具体数值因机器而异）：

=== 测试: SynchronizedMap ===
SynchronizedMap 总耗时: 1250 ms
SynchronizedMap 最终大小: 100000

=== 测试: ConcurrentHashMap ===
ConcurrentHashMap 总耗时: 280 ms
ConcurrentHashMap 最终大小: 100000

💡 结论：

ConcurrentHashMap 的性能远超 SynchronizedMap。
ConcurrentHashMap 的读写并发性能接近 HashMap，是高并发场景下的绝对王者。

8. 面试官最爱问的 5 个“灵魂拷问”

❓ Q1: `HashMap` 为什么是线程不安全的？

答：主要有三点：

size 非原子：size++ 可能丢失更新。
put 非原子：多线程同时 put 可能导致数据丢失或覆盖。
resize 并发问题：JDK 7 中可能导致链表成环，引发死循环；JDK 8 虽已修复，但 resize 期间仍可能因 size 计算错误导致问题。

❓ Q2: `ConcurrentHashMap` 在 JDK 7 和 JDK 8 中实现有何不同？

答：

JDK 7：采用 Segment 分段锁。ConcurrentHashMap 由多个 Segment 组成，每个 Segment 是一个锁，锁住一部分桶。并发度由 Segment 数量决定。
JDK 8：放弃 Segment，采用 CAS + synchronized。使用 CAS 操作在无竞争时快速插入，当发生哈希冲突时，使用 synchronized 锁住链表头节点或红黑树根节点。锁的粒度更细，性能更高。

❓ Q3: `ConcurrentHashMap` 的 `get()` 方法为什么不需要加锁？

答：get() 方法无锁，主要依赖：

volatile 关键字：Node 节点的 val 和 next 字段是 volatile 的，保证了其他线程的写操作对当前线程可见。
无状态修改：get 操作只读不写，不会改变数据结构。
链表/树的遍历：即使在遍历过程中链表被修改（如扩容），由于 volatile 的可见性，也能保证读到最新的节点，不会出错（可能读到旧值，但不会崩溃）。

❓ Q4: `Collections.synchronizedMap()` 和 `ConcurrentHashMap` 有什么区别？

答：

特性	`Collections.synchronizedMap()`	`ConcurrentHashMap`
锁粒度	全局锁（锁整个 `Map`）	桶级锁（锁单个链表/树）
并发度	低，同一时间只能一个线程访问	高，多个线程可同时访问不同桶
性能	低，在高并发下性能差	高，专为高并发优化
迭代器	弱一致，需手动同步	弱一致，但更安全
适用场景	并发不高，简单场景	高并发读写场景

❓ Q5: 如何保证 `ConcurrentHashMap` 的复合操作（如“检查再插入”）的原子性？

答：使用 ConcurrentHashMap 提供的原子性复合操作方法，例如：

putIfAbsent(K key, V value)：如果 key 不存在，则插入，返回 null；否则返回已存在的 value。
computeIfAbsent(K key, Function<? super K, ? extends V> mappingFunction)：如果 key 不存在，则使用函数计算 value 并插入。
remove(Object key, Object value)：只有当 key 映射到指定 value 时才移除。
这些方法内部使用了锁或 CAS，保证了操作的原子性。

9. 终章：`ConcurrentHashMap` 的“并发哲学”

小李（兴奋地）：“王总，我懂了！HashMap 的‘非线程安全’，就像一个没有‘交通规则’的十字路口，车辆（线程）随意穿行，必然导致‘事故’（数据不一致、死循环）。而 Collections.synchronizedMap() 就像在路口建了一座‘收费站’，虽然安全，但所有车辆必须排队，效率低下。”

王总（赞许地）：“说得好！那 ConcurrentHashMap 呢？”

小李（自信地）：“ConcurrentHashMap 就像一个设计精妙的‘立交桥’！它没有单一的收费站，而是让不同方向的车辆（线程）在各自的‘车道’（桶）上并行行驶。只有在车道交汇处（发生哈希冲突）才需要短暂的‘信号灯’（synchronized 锁）协调。而 CAS 就像‘智能导航’，让车辆在无车时快速通过。它用‘最小的阻塞’，实现了‘最大的并发’。这才是现代高并发系统的‘智慧’所在！”

王总（大笑）：“小李，你不仅懂了技术，更悟了‘道’！ConcurrentHashMap 的设计，正是‘分而治之’（Divide and Conquer）与‘无锁编程’（Lock-Free Programming）思想的完美体现。它告诉我们，解决复杂问题，不在于‘堵’，而在于‘疏’。记住：真正的‘安全’，是建立在‘高效’之上的‘优雅’平衡！”

🔥 窗外，城市的灯火通明，如同无数并发的线程在运行。小李知道，有了 ConcurrentHashMap 这把“利刃”，他已无惧任何“并发迷宫”。

🎉 至此，我们完成了对 HashMap 线程不安全性的深度剖析，并全面掌握了 ConcurrentHashMap 这一“并发神器”。希望这篇充满案例、源码、对比与“哲学思辨”的文章，能助你在多线程的战场上，稳操胜券！

📌 温馨提示：在多线程环境下，永远不要使用 HashMap。优先选择 ConcurrentHashMap。理解其底层原理，是成为高级 Java 工程师的必经之路。

🎯 总结一下：

本文深入探讨了《HashMap 的线程不安全性及解决方案（ConcurrentHashMap）》，从原理到实践，解析了面试中常见的考察点和易错陷阱。掌握这些内容，不仅能应对面试官的连环追问，更能提升你在实际开发中的技术判断力。

🔗 下期预告：我们将继续深入Java面试核心，带你解锁《ConcurrentHashMap 如何实现线程安全》的关键知识点，记得关注不迷路！

💬 互动时间：你在面试中遇到过类似问题吗？或者对本文内容有疑问？欢迎在评论区留言交流，我会一一回复！

如果你觉得这篇文章对你有帮助，别忘了点赞 + 收藏 + 转发，让更多小伙伴一起进步！我们下一篇见 👋