ConcurrentHashMap深度解析
一、ConcurrentHashMap 核心作用
ConcurrentHashMap是 Java 并发包（java.util.concurrent）中提供的线程安全的哈希表实现，它的核心作用是：
- 在多线程环境下，支持高并发的读写操作，避免了
HashMap线程不安全导致的问题（如死循环、数据丢失）。 - 相比传统的
Hashtable（全表加锁）或Collections.synchronizedMap()（包装后的 HashMap，也是全表锁），ConcurrentHashMap采用分段锁 / 精细化锁机制，大幅提升了并发性能。 - 支持并发度（默认 16），允许多个线程同时操作不同的分段区域，读写之间尽可能不阻塞。
二、ConcurrentHashMap 底层实现（按 JDK 版本划分）
ConcurrentHashMap的底层实现在 JDK 1.7 和 JDK 1.8 有重大变化，其中 JDK 1.8 是目前主流使用的版本，我会重点讲解。
1. JDK 1.7 实现：分段锁（Segment + HashEntry）
核心结构
- Segment：继承自
ReentrantLock，是一个可重入锁，相当于 “锁桶”。一个ConcurrentHashMap包含多个Segment（默认 16 个），每个Segment对应一个数组，数组元素是HashEntry链表。 - HashEntry：存储键值对的节点，结构和
HashMap的Entry类似，但value和next用volatile修饰，保证可见性。
核心原理
- 哈希计算：key 先经过一次哈希得到
Segment的索引，再对Segment内的数组做二次哈希，定位到具体的HashEntry节点。 - 加锁粒度：只对操作的
Segment加锁，其他Segment不受影响。例如线程 A 操作 Segment1，线程 B 操作 Segment2，两者可以并行执行，只有操作同一个 Segment 的线程才会互斥。 - 读写规则：
- 写操作（put/remove）：获取对应
Segment的锁，完成操作后释放锁。 - 读操作（get）：无需加锁，通过
volatile保证节点值的可见性。
- 写操作（put/remove）：获取对应
2. JDK 1.8 实现：CAS(Compare-And-Swap（比较并交换）) + synchronized + 红黑树（废弃 Segment）
JDK 1.8 抛弃了分段锁，借鉴了HashMap的结构（数组 + 链表 + 红黑树），并通过更精细化的锁机制提升并发性能。
核心结构
- Node 数组：底层是
Node<K,V>类型的数组，Node的value和next同样用volatile修饰。 - TreeNode：当链表长度超过 8，且数组长度≥64 时，链表转为红黑树（和 HashMap 逻辑一致），提升查询效率。
- ForwardingNode：扩容时的特殊节点，标记当前桶正在扩容，引导读操作到新数组，写操作协助扩容。
核心原理
哈希计算：和 HashMap 一致（扰动函数 + 取模），直接定位到数组的桶（bucket）。
加锁粒度：从 “Segment 级” 缩小到 “桶级”—— 只对操作的数组桶（单个 Node 节点）加锁，并发度更高。
核心操作逻辑：
- put 操作：
- 计算 key 的哈希值，定位到数组桶。
- 如果桶为空，通过CAS无锁方式插入节点（避免加锁开销）。
- 如果桶不为空，检查桶的首节点：
- 若首节点是
ForwardingNode（扩容中），协助扩容后再插入。 - 否则用
synchronized锁定首节点，遍历链表 / 红黑树，完成插入 / 覆盖。
- 若首节点是
- 插入后检查链表长度，超过阈值则转为红黑树。
- get 操作：无需加锁！通过
volatile保证节点的可见性，步骤：- 定位到数组桶，检查首节点是否匹配 key，匹配则返回 value。
- 不匹配则遍历链表 / 红黑树，找到则返回 value，否则返回 null。
- 扩容操作：采用 “多线程分段扩容”—— 每个线程负责一部分桶的迁移，通过
ForwardingNode标记扩容状态，避免重复扩容。 - size 操作：无需遍历全表，通过累加
baseCount（基础计数）和counterCells（分段计数）实现，避免全表加锁。
- put 操作：
线程安全保障：
- 写操作：CAS（无锁场景） + synchronized（锁桶）保证原子性。
- 读操作：volatile 保证可见性，无需加锁（弱一致性，允许读到旧值，但不会读到脏数据）。
- 扩容：多线程协作，避免单线程扩容的性能瓶颈。
三、ConcurrentHashMap 与 HashMap 的核心区别
| 特性 | HashMap | ConcurrentHashMap |
|---|---|---|
| 线程安全 | 非线程安全 | 线程安全 |
| 锁机制 | 无锁 | JDK1.7：分段锁；JDK1.8：CAS+synchronized |
| 空值支持 | 允许 key/value 为 null（key 仅 1 个） | 不允许 key/value 为 null（避免并发场景下判空歧义） |
| 迭代器特性 | 快速失败（fail-fast）：迭代中修改会抛ConcurrentModificationException | 弱一致性（fail-safe）：迭代器是快照，不会抛异常，可能读到旧值 |
| 扩容机制 | 单线程扩容 | 多线程分段扩容（JDK1.8） |
| 性能（多线程） | 高并发下可能死循环 / 数据错乱，性能差 | 高并发下性能优异，锁粒度极小 |
| 使用场景 | 单线程 / 低并发读多写少 | 高并发多线程环境 |
补充说明
为什么 ConcurrentHashMap 不支持 null？HashMap 中
get(key)返回 null 时，无法区分 “key 不存在” 还是 “key 对应 value 是 null”；而 ConcurrentHashMap 用于多线程场景，若允许 null，会增加并发下的歧义处理成本，因此直接禁止。弱一致性的体现：迭代 ConcurrentHashMap 时，迭代器会先获取当前数组的快照，后续数组的修改不会反映到迭代器中，因此不会抛
ConcurrentModificationException，但可能读到迭代前的旧数据。
总结
ConcurrentHashMap的核心价值是多线程安全 + 高并发性能，相比传统的线程安全哈希表（Hashtable），它通过精细化锁（分段锁 / JDK1.8 桶锁）和 CAS 机制大幅提升并发效率。- JDK 1.8 是 ConcurrentHashMap 的主流实现，抛弃分段锁，采用 “CAS + synchronized + 红黑树”，锁粒度缩小到单个桶，并发性能更优。
- 与 HashMap 的核心区别在于：线程安全、空值支持、迭代器特性，前者适用于高并发场景，后者适用于单线程 / 低并发场景。