这道题几乎每场 Java 面试都会问，但很多人的回答停留在"HashMap 线程不安全，ConcurrentHashMap 线程安全"这一句，然后就没了。
面试官听到这个回答，通常会追问："为什么 HashMap 线程不安全？ConcurrentHashMap 怎么保证线程安全的？"这两个追问才是真正考察理解深度的地方。
这篇从数据结构开始，把这道题完整说清楚。
先说 HashMap
底层结构
JDK 8 之后，HashMap 的底层是 数组 + 链表 + 红黑树。
数组（默认长度16）
├── index 0: null
├── index 1: Node(key1) → Node(key2) → ... ← 链表（冲突时）
├── index 2: TreeNode ← 红黑树（链表长度 > 8 且数组长度 >= 64 时转换）
└── ...
put 一个元素的过程：
- 计算 key 的 hash 值
- 用 hash 值确定数组下标
- 如果该位置为空，直接放
- 如果不为空（hash 冲突），加到链表尾部
- 链表长度超过 8 且数组长度超过 64，转成红黑树
为什么线程不安全
主要有两个问题：
问题一：put 操作不是原子的
多个线程同时 put，可能同时判断某个位置为空，然后都往那个位置写，后写的覆盖先写的，导致数据丢失。
问题二：扩容时可能死循环（JDK 7 及之前）
JDK 7 扩容时用头插法迁移链表，多线程并发扩容可能形成环形链表，导致 get 操作死循环，CPU 直接打满。
JDK 8 改成了尾插法，解决了死循环问题，但并发下数据丢失的问题依然存在。
再说 ConcurrentHashMap
JDK 7 的实现：分段锁
JDK 7 的 ConcurrentHashMap 用的是 Segment 分段锁。
ConcurrentHashMap
├── Segment[0]（继承 ReentrantLock）
│ └── HashEntry 数组
├── Segment[1]
│ └── HashEntry 数组
└── ...（默认16个Segment）
默认有 16 个 Segment，每个 Segment 相当于一个独立的小 HashMap，各自有一把锁。不同 Segment 的操作互不干扰，最多支持 16 个线程并发写。
JDK 8 的实现：CAS + synchronized
JDK 8 放弃了分段锁，结构改成和 HashMap 一样的数组 + 链表 + 红黑树，并发控制改用 CAS + synchronized。
put 操作的核心流程：
// 简化版核心逻辑
if (数组该位置为空) {
// 用 CAS 原子操作写入，不加锁
casTabAt(tab, i, null, new Node(hash, key, value));
} else {
// 该位置有值，用 synchronized 锁住这个链表/红黑树的头节点
synchronized (头节点) {
// 遍历链表，插入或更新
}
}
关键点：
- 只有发生 hash 冲突时才加锁，而且只锁冲突的那个桶（数组位置）
- 不同桶之间的操作完全并行，锁粒度比 JDK 7 的分段锁更细
- CAS 用于无竞争的快速路径，synchronized 用于有竞争的情况
get 为什么不加锁
public V get(Object key) {
// Node 的 val 和 next 都是 volatile 修饰的
// volatile 保证可见性，读操作不需要加锁
}
Node 节点的 val 和 next 字段用 volatile 修饰，保证可见性，所以 get 操作不需要加锁，性能极高。
面试常见追问
1. ConcurrentHashMap 能保证复合操作的原子性吗？
不能。
// 这两行操作不是原子的，并发下仍然有问题
if (!map.containsKey(key)) {
map.put(key, value);
}
// 正确做法：用 putIfAbsent
map.putIfAbsent(key, value);
// 或者用 computeIfAbsent
map.computeIfAbsent(key, k -> computeValue(k));
2. size() 返回的结果准确吗？
不一定准确。
ConcurrentHashMap 的 size() 返回的是一个估计值，在并发修改的情况下可能不精确。如果需要精确统计，应该在外部加同步控制，或者改用其他方案。
3. 为什么不用 Hashtable？
Hashtable 是给所有方法加 synchronized，相当于整张表只有一把锁，并发性能极差。现代代码里已经基本不用了。
对比总结
| 对比项 | HashMap | ConcurrentHashMap |
|---|---|---|
| 线程安全 | 否 | 是 |
| null key/value | 允许 | 不允许 |
| 底层结构（JDK8） | 数组+链表+红黑树 | 数组+链表+红黑树 |
| 并发控制 | 无 | CAS + synchronized（锁单个桶） |
| get 加锁 | 否 | 否（volatile 保证可见性） |
| 适用场景 | 单线程 | 多线程并发读写 |
面试怎么答
回答这道题的思路：先说区别 → 展开线程安全机制 → 说 JDK 版本演进 → 点出注意事项
开口可以这样说：
"HashMap 线程不安全，主要体现在并发 put 时可能数据丢失，JDK7 还有扩容死循环的问题。ConcurrentHashMap 是线程安全的，JDK7 用分段锁，JDK8 改成了 CAS + synchronized 锁单个桶的方式，锁粒度更细，并发性能更好。get 操作因为 Node 的 val 用了 volatile 修饰，不需要加锁。不过需要注意，ConcurrentHashMap 只保证单个操作的原子性，复合操作还是需要用 putIfAbsent、computeIfAbsent 这类原子方法。"
这个回答长度适中，覆盖了核心点，面试官听完基本能满意。
