- Java的HashMap竟然不是线程安全的，现在才知道！*
引言
在Java开发中，HashMap是最常用的数据结构之一，几乎每个Java开发者都使用过它来存储键值对。然而，很多开发者在使用HashMap时，往往会忽略一个关键问题：HashMap不是线程安全的 。这个问题在高并发场景下可能会导致严重的数据不一致问题，甚至引发程序崩溃。本文将深入探讨HashMap的线程安全问题，分析其背后的原因，并提供解决方案。
为什么HashMap不是线程安全的？
1. HashMap的基本实现原理
HashMap是基于哈希表实现的，它通过数组和链表（或红黑树）的组合来存储数据。当我们向HashMap中插入一个键值对时，它会根据键的哈希值计算出数组的索引位置，然后将键值对存储在该位置。如果多个键的哈希值相同（即发生哈希冲突），HashMap会使用链表或红黑树来解决冲突。
2. 线程不安全的表现
HashMap的线程不安全主要体现在以下几个方面：
(1) 并发修改导致的无限循环
在Java 8之前，HashMap在扩容时（即重新哈希）可能会因为多线程并发操作而导致链表成环。具体来说，当两个线程同时触发resize()操作时，可能会导致链表中的节点互相引用，形成一个环形链表。这种情况下，后续的get()操作可能会陷入无限循环，导致CPU占用率飙升。
(2) 数据丢失
在多线程环境下，如果两个线程同时向HashMap中插入数据，且两个键的哈希值相同，可能会导致其中一个线程的插入操作被覆盖。这是因为HashMap的put()操作不是原子性的，而是分为多个步骤（计算哈希、定位桶、插入节点），在这些步骤之间可能会被其他线程打断。
(3) 不一致的状态
HashMap的内部状态（如size、modCount等字段）在多线程环境下可能会被破坏。例如，size字段可能无法正确反映HashMap中实际存储的键值对数量，导致程序逻辑错误。
3. 源码分析
我们可以通过HashMap的源码来验证它的线程不安全问题。以下是HashMap的putVal()方法的简化逻辑：
java
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
Node<K,V>[] tab; Node<K,V> p; int n, i;
if ((tab = table) == null || (n = tab.length) == 0)
n = (tab = resize()).length;
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null); // 非原子操作，可能导致数据覆盖
else {
// 处理哈希冲突
}
+ +modCount; // 非原子操作，可能导致modCount不一致
if (++size > threshold)
resize(); // 并发resize可能导致链表成环
return null;
}从代码中可以看到，putVal()方法中的多个操作都是非原子性的，因此在多线程环境下可能会导致问题。
如何解决HashMap的线程安全问题？
1. 使用Collections.synchronizedMap
Java提供了Collections.synchronizedMap()方法，可以将HashMap包装成一个线程安全的Map。例如：
java
Map<String, String> map = Collections.synchronizedMap(new HashMap<>());这种方式的原理是通过在Map的所有方法上加锁（使用synchronized关键字）来保证线程安全。缺点是性能较差，因为所有操作都需要竞争同一把锁。
2. 使用ConcurrentHashMap
ConcurrentHashMap是Java提供的线程安全的哈希表实现，它在设计上采用了分段锁（Java 7）或CAS + synchronized（Java 8）的机制，大大提高了并发性能。例如：
java
Map<String, String> map = new ConcurrentHashMap<>();(1) Java 7的分段锁
在Java 7中，ConcurrentHashMap将数据分成多个段（Segment），每个段独立加锁。这样，不同线程可以同时访问不同的段，从而提高了并发性能。
(2) Java 8的CAS + synchronized
在Java 8中，ConcurrentHashMap放弃了分段锁的设计，改为使用CAS（Compare-And-Swap）和synchronized来保证线程安全。具体来说：
- 对于桶的第一个节点，使用CAS操作插入。
- 对于桶的其他节点，使用
synchronized锁定链表或红黑树的头节点。
这种设计进一步提高了并发性能，尤其是在高并发场景下。
3. 使用Hashtable（不推荐）
Hashtable是Java早期提供的线程安全的哈希表实现，它的所有方法都是synchronized的。虽然它是线程安全的，但由于全局锁的设计，性能较差，因此不推荐使用。
性能对比
为了更直观地理解不同方案的性能差异，我们可以通过简单的基准测试来比较HashMap、Collections.synchronizedMap和ConcurrentHashMap的性能：
| 实现方式 | 读性能 | 写性能 | 适用场景 |
|---|---|---|---|
HashMap |
高 | 高 | 单线程环境 |
Collections.synchronizedMap |
低 | 低 | 低并发环境 |
ConcurrentHashMap |
高 | 高 | 高并发环境 |
从表中可以看出，ConcurrentHashMap在高并发场景下的性能优势非常明显。
实际案例分析
案例1：缓存系统
假设我们正在开发一个高并发的缓存系统，使用HashMap来存储缓存数据。由于HashMap不是线程安全的，可能会导致以下问题：
- 缓存数据丢失：多个线程同时写入缓存时，部分数据可能被覆盖。
- 缓存数据不一致：
size字段不准确，导致缓存清理逻辑错误。
解决方案是使用ConcurrentHashMap：
java
public class Cache {
private final Map<String, Object> cache = new ConcurrentHashMap<>();
public void put(String key, Object value) {
cache.put(key, value);
}
public Object get(String key) {
return cache.get(key);
}
}案例2：计数器
假设我们需要实现一个全局计数器，统计某个事件的触发次数。如果使用HashMap，可能会因为并发问题导致计数不准确：
java
// 错误实现
Map<String, Integer> counter = new HashMap<>();
counter.put("count", counter.getOrDefault("count", 0) + 1); // 非原子操作正确的做法是使用ConcurrentHashMap的compute()方法：
java
Map<String, Integer> counter = new ConcurrentHashMap<>();
counter.compute("count", (k, v) -> v == null ? 1 : v + 1); // 原子操作总结
HashMap是Java中最常用的数据结构之一，但由于其非线程安全的特性，在高并发场景下可能会导致严重的问题。通过本文的分析，我们了解到：
HashMap的线程不安全主要体现在并发修改、数据丢失和不一致状态上。- 可以通过
Collections.synchronizedMap或ConcurrentHashMap来解决线程安全问题，其中ConcurrentHashMap是更优的选择。 - 在实际开发中，应根据具体场景选择合适的线程安全方案。
希望本文能帮助你更好地理解HashMap的线程安全问题，并在实际开发中避免相关的陷阱。