【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 来实现互斥

pivate final Node<K, V>[] initTable() {
  Node<K,V>[] tab; int sc;
  while ((tab = table) == null || tab.length == 0) {
    if ((sc = sizeCtl) < 0)
      // 存在多线程冲突，需等待
      Thread.yield();
    else if (U.compareAndSetInt(this, SIZECTL, sc, -1)) {
      // CAS 成功，进入真正的初始化逻辑
      ...
    }
  }
  return tab;
}