java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > Java HashMap非线程安全

Java HashMap是非线程安全的底层原因

作者：Seal^_^

本文将从定义结论、源码分析、5大并发不安全场景、可视化流程图、JDK1.7与1.8差异五个维度,彻底讲透 HashMap 线程不安全的底层原因,帮你避开开发中的并发大坑,感兴趣的朋友一起看看吧

前言

HashMap 是 Java 开发中最常用的键值对集合，也是面试高频考点。在单线程环境下，HashMap 性能高效、使用便捷，但在多线程并发环境中，HashMap 是绝对线程不安全的，强行使用会导致数据覆盖、死循环、数据丢失等严重问题。

本文将从定义结论、源码分析、5大并发不安全场景、可视化流程图、JDK1.7与1.8差异五个维度，彻底讲透 HashMap 线程不安全的底层原因，帮你避开开发中的并发大坑！

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

结论：HashMap 不是线程安全的集合！

1.1 直观判断依据

  1. HashMap 源码中没有任何锁机制（synchronized、Lock 都不存在）；
  2. 多线程同时对 HashMap 执行插入、删除、扩容操作时，会出现数据错乱；
  3. 官方明确标注：Note that this implementation is not synchronized.

1.2 线程安全的替代方案

如果需要在多线程中使用键值对集合，推荐使用：

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

2.1 根本原因

所有修改操作（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<K,V>[] resize() {
    // 扩容逻辑...
}

2.3 并发冲突的核心场景

多线程同时操作同一个哈希桶 + 同时触发扩容，是 HashMap 线程不安全的重灾区，会直接引发数据覆盖、丢失、死循环。

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

这是你描述的最核心、最常见的线程不安全场景，我用流程图+文字完整还原：

3.1 场景前提

  1. 线程 A、线程 B 同时向 HashMap 插入数据；
  2. 两个数据哈希值相同，指向同一个空哈希桶；
  3. 该位置无数据，无哈希冲突。

3.2 执行流程图

3.3 详细步骤解释

  1. 线程A：哈希定位到空桶，判断通过，还未插入数据就被挂起；
  2. 线程B：同时定位同一个空桶，判断为空，成功插入数据；
  3. 线程A：恢复执行，不会重新判断桶位是否为空，直接插入；
  4. 最终结果：线程A直接覆盖线程B的插入数据，导致数据丢失。

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

除了数据覆盖，HashMap 在多线程下还会出现 3 种致命问题：

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 不安全差异总结

版本插入方式线程不安全问题核心区别
JDK1.7头插法数据覆盖、死循环、数据丢失扩容会形成环形链表，死循环风险高
JDK1.8尾插法数据覆盖、数据丢失、size错误解决死循环，但依旧无锁，不安全

六、关键面试题标准答案（背会直接用）

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 线程不安全是 Java 并发编程的基础知识点，也是面试必考题。理解了无锁设计导致的并发冲突，不仅能轻松应对面试，更能在实际开发中避免因误用 HashMap 导致的线上故障。

到此这篇关于Java HashMap是非线程安全的底层原因的文章就介绍到这了,更多相关Java HashMap非线程安全内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文