java HashMap的不安全分析

HashMap在多线程环境下不安全，主要表现为JDK 1.7中put扩容引发的死循环、各版本均存在的数据覆盖与丢失、结构性修改导致的竞态条件及迭代异常；推荐使用ConcurrentHashMap替代。

HashMap在多线程环境下是不安全的，这主要体现在多个线程同时操作同一个HashMap实例时可能出现数据错乱、死循环、甚至程序崩溃等问题。下面从几个关键方面分析其不安全的原因。

1. put操作导致的死循环（JDK 1.7 中的问题）

在JDK 1.7中，HashMap使用头插法进行链表插入。当多个线程同时触发扩容（resize）时，可能会形成环形链表，从而在get操作时造成死循环。

问题场景：

• 两个线程同时发现元素数量超过阈值，开始扩容。
• 在转移旧桶中的链表时，使用头插法将节点插入到新桶中。
• 由于并发执行，某个链表的节点被反复反转，最终形成环。
• 后续调用get遍历链表时，会陷入无限循环。

虽然JDK 1.8改用尾插法解决了这个问题，但并不意味着HashMap变得线程安全了。

2. 数据覆盖与丢失（所有版本都存在）

多个线程同时执行put操作时，可能因为缺乏同步机制导致数据被覆盖。

典型情况：

• 线程A和线程B同时对同一个key执行put。
• 它们都读取了相同的初始状态，计算出相同的索引位置。
• 没有加锁的情况下，后写入的值会覆盖前一个，且无法保证最终结果符合预期。

这是因为put操作不是原子的：包括查找、创建节点、链接等多个步骤，中间状态可能被其他线程干扰。

3. 结构性修改的竞态条件

结构性修改如put、remove、clear等，在并发下可能导致内部结构不一致。

例如：

• 一个线程正在遍历EntrySet，另一个线程执行了remove或put引发扩容。
• 此时迭代器可能抛出ConcurrentModificationException（fail-fast机制），也可能返回不完整或重复的数据。

虽然fail-fast能及时发现问题，但它只是“检测”错误，并不能防止错误发生。

4. 替代方案：线程安全的Map实现

为解决HashMap的线程安全问题，Java提供了以下替代选择：

• Hashtable：方法用synchronized修饰，性能差，已基本弃用。
• Collections.synchronizedMap(map)：包装HashMap，提供同步支持，但仍需手动控制迭代过程的同步。
• ConcurrentHashMap：推荐方案。JDK 1.8采用CAS + synchronized分段锁优化，并发性能高，安全性强。

基本上就这些。HashMap设计初衷就是非线程安全的，追求高性能。多线程环境下必须使用 ConcurrentHashMap 或采取外部同步措施，否则极易引发难以排查的问题。不复杂但容易忽略。