【Java核心-基础】ConcurrentHashMap 高效地线程安全简介

JDK提供了一些线程安全的集合。

有粗粒度 synchronized 的集合。如，Hashtable、Collections.synchronizedXxx 包装的集合。

有细粒度，基于分离锁实现的集合。如，ConcurrentHashMap。

通常，并发包中提供的容器性能远优于早期的简单同步实现。

 

为什么需要ConcurrentHashMap？

HashMap 不是线程安全的。在并发场景中，可能会出现类似CPU占用100%之类的问题（死循环）。

Hashtable 和 Collections.synchronizedMap() 包装的HashMap：

内部都是通过 synchronized 同一把锁，来同步所有并发操作（put、get、size 等）。

这导致一个线程在操作时，其它线程只能等待，并发效率低。

它们只适合在并发程度较低的场景下使用。

 

ConcurrentHashMap 如何做到高效地线程安全？

ConcurrentHashMap 的设计实现一直在演化。不同JDK版本中的实现可能有较大改动。

Java 7

分离锁。内部分段（Segment，继承自ReentrantLock），段内是HashEntry数组，hash值相同的条目以链表形式存放。

HashEntry 内部用 volatile 的 value 字段保证可见性。利用Unsafe提供的底层能力优化性能。

Segment 的数量默认为16，可在相应的构造方法中指定（concurrencyLevel）。

并发操作时，只需锁定相应段，避免整体同步，以提高性能。

 

PUT：先对key的hash值再次hash，以减少hash冲突。然后利用Unsafe获取相应的Segment，再进行线程安全的put操作。

 

GET：需要可见性保证，没有同步逻辑。

 

Java 8 开始

• 总体结构与HashMap相似：桶数组（Buckets） + 内部链表（bin），同步粒度更细。

• 保留Segment定义，但仅用于保证序列化兼容性，不再有任何结构上的用处。

• 不再使用Segment后，初始化操作简化，改为 lazy-load 形式，减小初始化开销。

• size() 方法还是采用分而治之的算法。但使用了内部类 CounterCell（基于 LongAdder 和 Striped64）

• 使用 synchronized 作同步。因为 synchronized 已被优化，无需过分担心性能；内存消耗比 ReentrantLock 少。

• 更多地使用CAS等底层技术实现无锁化并发操作（Unsafe、AtomicReference等）

  如，利用 volatile 字段 sizeCtl 来实现互斥

Java代码

 

1. pivate final Node<K, V>[] initTable() {  

2.   Node<K,V>[] tab; int sc;  

3.   while ((tab = table) == null || tab.length == 0) {  

4.     if ((sc = sizeCtl) < 0)  

5.       // 存在多线程冲突，需等待  

6.       Thread.yield();  

7.     else if (U.compareAndSetInt(this, SIZECTL, sc, -1)) {  

8.       // CAS 成功，进入真正的初始化逻辑  

9.       ...  

10.     }  

11.   }  

12.   return tab;  

13. }