JavaHashMap是非线程安全的底层原因

前言

HashMap 可以说是 Ja va 开发中间出镜率最高的键值对集合之一，面试十有八九也会问到它。单线程用起来那叫一个顺手，可一旦放到多线程的并发场景里，事情就坏了——HashMap 是绝对线程不安全的，强行使用的话，数据覆盖、死循环、数据丢失，一样都跑不了。

这篇文章会从结论、源码分析、五个并发不安全的典型场景、可视化流程图，以及 JDK1.7 和 1.8 的差异这几个面，把 HashMap 线程不安全的底裤彻底扒干净，帮你避开那些在并发下踩过的坑。

一、核心结论：HashMap 是线程安全的吗？

直接上结论：HashMap 不是线程安全的集合，这一点毋庸置疑。

1.1 直观判断依据

1. 你翻遍 HashMap 的源码，找不到任何锁机制，synchronized 和 Lock 全都不存在；
2. 多线程同时往里插数据、删数据、或者扩容，数据必然乱套；
3. 官方文档也白纸黑字写着：Note that this implementation is not synchronized.

1.2 线程安全的替代方案

要是非要在多线程环境下用键值对集合，那这几个方案可以参考：

• ConcurrentHashMap（推荐，性能最好，没有之一）
• Hashtable（已经过时了，方法上都加了 synchronized，效率低）
• Collections.synchronizedMap(new HashMap())（包装类，效率一般般）

二、底层核心：HashMap 为什么非线程安全？

2.1 根本原因

说白了，根本原因就一句话：HashMap 里所有修改数据的操作——put、remove、resize——都没有加锁。多线程并发修改共享变量（数组、链表、红黑树），数据一致性自然就崩了。

2.2 JDK 源码佐证

咱们直接看源码，HashMap 的 put 方法和 resize 扩容方法，全程无锁：

// JDK1.8 HashMap.put() 核心方法，无任何锁修饰
public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}
// 扩容方法，同样无锁
final Node[] resize() {
    // 扩容逻辑...
}

2.3 并发冲突的核心场景

多线程同时操作同一个哈希桶，再赶上一起触发扩容，这基本就是 HashMap 线程不安全的“重灾区”。数据覆盖、丢失、死循环，全是从这儿冒出来的。

三、可视化图解：多线程数据覆盖（最经典场景）

下面这个场景，是 HashMap 线程不安全里最经典、最常见的一个，咱们用流程图加文字完整还原一遍：

3.1 场景前提

1. 线程 A 和线程 B 同时往 HashMap 里插入数据；
2. 两个数据的哈希值一样，指向同一个还没有数据的空桶；
3. 那个位置目前是空的，没有哈希冲突。

3.2 执行流程图

3.3 详细步骤解释

1. 线程 A 先通过哈希定位到了那个空桶，判断条件都通过了，但还没等它把数据插进去，就被系统挂起了；
2. 线程 B 也定位到了同一个空桶，判断为空，顺利把数据插了进去；
3. 线程 A 恢复执行后，它不会重新检查桶位是不是空的，直接就把自己的数据插进去；
4. 最终结果就是：线程 A 的数据把线程 B 的数据覆盖了，B 的数据丢了。

四、HashMap 线程不安全的 4 种典型后果

除了数据覆盖，HashMap 在多线程下还会搞出另外几个幺蛾子：

4.1 数据丢失（除覆盖外）

比如多线程同时往同一个哈希桶的链表尾部追加节点，大家都在改链表指针，结果就是部分节点根本没挂上去，直接失踪。

4.2 死循环（JDK1.7 经典 Bug）

JDK1.7 扩容用的是头插法，多线程并发扩容时，链表会变成环形链表。你后面再调用 get() 方法遍历这个环，程序就死循环了，CPU 直接飙到 100%，下都下不来。

到了 JDK1.8，把头插法改成尾插法，扩容死循环的问题算是解决了，但它依然不是线程安全的。

4.3 size 统计错误

HashMap 里的 size 变量没有原子性保障，多线程同时往里插数据，size 的计数不是少算就是错算，集合的实际大小和你看到的永远对不上。

4.4 扩容数据错乱

多个线程一起触发扩容，数组迁移的时候数据就会乱成一锅粥，最后出现重复数据、null 数据、节点丢失，什么情况都有可能。

五、JDK1.7 与 JDK1.8 不安全差异总结

六、关键面试题标准答案（背下这几句，面试官当场闭嘴）

6.1 问：HashMap 是线程安全的吗？为什么？

答：

1. HashMap 不是线程安全的；
2. 因为 HashMap 的 put、remove、resize 等所有修改方法都没有加锁机制；
3. 多线程并发操作时，会出现数据覆盖、数据丢失、size 统计错误，JDK1.7 还会出现死循环；
4. 本质是共享资源（哈希表、链表）被并发修改，破坏了数据一致性。

6.2 问：多线程下用什么替代 HashMap？

答：优先用 ConcurrentHashMap，它采用分段锁加 CAS 加 synchronized 来保证线程安全，性能远高于 Hashtable。

七、总结

1. 核心结论：HashMap 无锁设计，绝对非线程安全；
2. 核心原因：多线程并发修改共享数据，无同步机制保护；
3. 典型问题：数据覆盖、数据丢失、size 错误、JDK1.7 死循环；
4. 开发规范：单线程用 HashMap，多线程用 ConcurrentHashMap；
5. 关键提醒：JDK1.8 解决了死循环，但依旧不能在多线程中使用！

结束语

HashMap 线程不安全这件事，说到底是并发编程里的一个基础题，但也是面试里最容易翻车的地方。把无锁设计导致的并发冲突这个点吃透了，不光面试能轻松过关，实际开发里也能少踩几个因为误用 HashMap 导致的线上故障。