面试必问：HashMap和ConcurrentHashMap的区别，这次彻底说清楚

这道题几乎每场 Java 面试都会问，但很多人的回答停留在"HashMap 线程不安全，ConcurrentHashMap 线程安全"这一句，然后就没了。

面试官听到这个回答，通常会追问："为什么 HashMap 线程不安全？ConcurrentHashMap 怎么保证线程安全的？"这两个追问才是真正考察理解深度的地方。

这篇从数据结构开始，把这道题完整说清楚。

先说 HashMap

底层结构

JDK 8 之后，HashMap 的底层是 数组 + 链表 + 红黑树。

yaml 复制代码

数组（默认长度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 改成了尾插法，解决了死循环问题，但并发下数据丢失的问题依然存在。

Java面试通关宝典

再说 ConcurrentHashMap

JDK 7 的实现：分段锁

JDK 7 的 ConcurrentHashMap 用的是 Segment 分段锁。

css 复制代码

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 操作的核心流程：

java 复制代码

// 简化版核心逻辑
if (数组该位置为空) {
    // 用 CAS 原子操作写入，不加锁
    casTabAt(tab, i, null, new Node(hash, key, value));
} else {
    // 该位置有值，用 synchronized 锁住这个链表/红黑树的头节点
    synchronized (头节点) {
        // 遍历链表，插入或更新
    }
}

关键点：

只有发生 hash 冲突时才加锁，而且只锁冲突的那个桶（数组位置）
不同桶之间的操作完全并行，锁粒度比 JDK 7 的分段锁更细
CAS 用于无竞争的快速路径，synchronized 用于有竞争的情况

get 为什么不加锁

typescript 复制代码

public V get(Object key) {
    // Node 的 val 和 next 都是 volatile 修饰的
    // volatile 保证可见性，读操作不需要加锁
}

Node 节点的 val 和 next 字段用 volatile 修饰，保证可见性，所以 get 操作不需要加锁，性能极高。

面试常见追问

1. ConcurrentHashMap 能保证复合操作的原子性吗？

不能。

arduino 复制代码

// 这两行操作不是原子的，并发下仍然有问题
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 这类原子方法。"

这个回答长度适中，覆盖了核心点，面试官听完基本能满意。