一篇了解ConcurrentHashMap的底层结构与演进过程

都知道ConcurrentHashMap可以用于解决HashMap等KV键值对集合的并发问题。本篇文章将从JDK7和JDK8两个重要版本中来介绍ConcurrentHashMap的底层结构与演进过程。

1.JDK7中的ConcurrentHashMap

先回顾一下HashMap。在JDK8以前，HashMap是基于数组+链表来实现的。从整体上看HashMap是一个数组，数组中的每个元素都是一个链表，如下图：

当向HashMap中增加元素时，会先根据此元素的Key的hash值计算出该元素将要保存在数组中的下标。如果多个元素计算出的下标值相同，就会以链表的形式存储在数组的同一个元素中。

JDK8以前的ConcurrentHashMap间接地实现了Map<K,V>，并将每一个元素称为一个segment，每个segment都是一个HashEntry<K,V>数组（称为table）,table的每个元素都是HashEntry的单向队列，如下图所示：

默认情况下，ConcurrentHashMap会生成16个segment。

采用此结构的ConcurrentHashMap解决并发问题的思路是更加细粒度地给Map加锁。HashMap是非线程安全的，而线程安全的HashTable在并发写环境下，会给整个HashTable容器加上锁。但是如果有多个线程同时修改HashTable，仍然会发生写冲突，从而导致并发异常；而ConcurrentHashMap不会给整个容器加锁，而是会给容器中的每个segment都加一把锁。这样一来，在第一个线程修改segment-1的同时，其他线程也可以修改其余的segment，即只要各个线程同一时刻访问的是不同的segment，就不会发生写冲突。

2.JDK8中的ConcurrentHashMap

从JDK8开始，HashMap/ConcurrentHashMap的存储结构发生了改变，增加了条件性的“红黑树”。

为了优化查询，当链表中的元素超过8个时，HashMap就会将该该链表转换为红黑树，即采用了数组+链表/红黑树的存储结构，如下图：

不仅是HashMap，JDK8中的ConcurrentHashMap也改为数组+链表/红黑树的存储结构，并且废弃了segment，采用了比之前segment还要细粒度的“锁”，直接采用volatile HashEntry<K,V>对象保存数据，即对每一条数据直接通过volatile避免冲突。(即将segment的“小段锁”，改为对每个元素进行一次volatile)。此外，JDK8中的ConcurrentHashMap还使用了大量的synchronize和CAS算法来保证线程安全。

另外需要注意的是，ConcurrentHashMap和HashMap是同一层次的，它们都是AbstractMap的子类，二者之间没有继承关系。

代码层面，ConcurrentHashMap与HashMap的使用方法非常类似，读者可以自行查阅API进行学习，以下是一个ConcurrentHashMap的基础示例。

public class ConcurrentHashMapTest {
    public static void main(String[] args) {
        ConcurrentHashMap<String,String> concurrentHashMap = new ConcurrentHashMap<>(8);
        concurrentHashMap.put("aaa","111");
        concurrentHashMap.put("bbb","222");
        concurrentHashMap.put("ccc","333");
        //如果key已存在，则不再增加;如果不存在，则增加
        concurrentHashMap.putIfAbsent("aaa","111");
        System.out.println(concurrentHashMap);
    }
}