ConcurrentHashMap 高并发的安全实现原理解析

一、概述

ConcurrentHashMap (以下简称C13Map) 是并发编程出场率最高的数据结构之一，大量的并发CASE背后都有C13Map的支持，同时也是JUC包中代码量最大的组件(6000多行)，自JDK8开始Oracle对其进行了大量优化工作。

本文从 HashMap 的基础知识开始，尝试逐一分析C13Map中各个组件的实现和安全性保证。

二、HashMap基础知识

分析C13MAP前，需要了解以下的HashMap知识或者约定：

哈希表的长度永远都是2的幂次方，原因是hashcode%tableSize==hashcode&(tableSize-1)，也就是哈希槽位的确定可以用一次与运算来替代取余运算。

会对hashcode调用若干次扰动函数，将高16位与低16位做异或运算，因为高16位的随机性更强。

当表中的元素总数超过tableSize * 0.75时，哈希表会发生扩容操作，每次扩容的tableSize是原先的两倍。

下文提到的槽位(bucket)、哈希分桶、BIN均表示同一个概念，即哈希table上的某一列。

旧表在做搬运时i槽位的node可以根据其哈希值的第tableSize位的bit决定在新表上的槽位是i还是i+tableSize。

每个槽位上有可能会出现哈希冲突，在未达到某个阈值时它是一个链表结构，达到阈值后会升级到红黑树结构。

HashMap本身并非为多线程环境设计，永远不要尝试在并发环境下直接使用HashMap，C13Map不存在这个安全问题。

三、C13Map的字段定义

C13Map的字段定义

//最大容量
private static final int MAXIMUM_CAPACITY = 1 << 30;
 
//默认初始容量
private static final int DEFAULT_CAPACITY = 16;
 
//数组的最大容量,防止抛出OOM
static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;
 
//最大并行度，仅用于兼容JDK1.7以前版本
private static final int DEFAULT_CONCURRENCY_LEVEL = 16;
 
//扩容因子
private static final float LOAD_FACTOR = 0.75f;
 
//链表转红黑树的阈值
static final int TREEIFY_THRESHOLD = 8;
 
//红黑树退化阈值
static final int UNTREEIFY_THRESHOLD = 6;
 
//链表转红黑树的最小总量
static final int MIN_TREEIFY_CAPACITY = 64;
 
//扩容搬运时批量搬运的最小槽位数
private static final int MIN_TRANSFER_STRIDE = 16;
 
 
//当前待扩容table的邮戳位,通常是高16位
private static final int RESIZE_STAMP_BITS = 16;
 
//同时搬运的线程数自增的最大值
private static final int MAX_RESIZERS = (1 << (32 - RESIZE_STAMP_BITS)) - 1;
 
//搬运线程数的标识位，通常是低16位
private static final int RESIZE_STAMP_SHIFT = 32 - RESIZE_STAMP_BITS;
 
static final int MOVED     = -1; // 说明是forwardingNode
static final int TREEBIN   = -2; // 红黑树
static final int RESERVED  = -3; // 原子计算的占位Node
static final int HASH_BITS = 0x7fffffff; // 保证hashcode扰动计算结果为正数
 
//当前哈希表
transient volatile Node<K,V>[] table;
 
//下一个哈希表
private transient volatile Node<K,V>[] nextTable;
 
//计数的基准值
private transient volatile long baseCount;
 
//控制变量，不同场景有不同用途，参考下文
private transient volatile int sizeCtl;
 
//并发搬运过程中CAS获取区段的下限值
private transient volatile int transferIndex;
 
//计数cell初始化或者扩容时基于此字段使用自旋锁
private transient volatile int cellsBusy;
 
//加速多核CPU计数的cell数组
private transient volatile CounterCell[] counterCells;

四、安全操作Node<K,V>数组

static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
    return (Node<K,V>)U.getReferenceAcquire(tab, ((long)i << ASHIFT) + ABASE);
}
static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
                                    Node<K,V> c, Node<K,V> v) {
    return U.compareAndSetReference(tab, ((long)i << ASHIFT) + ABASE, c, v);
}
static final <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v) {
    U.putReferenceRelease(tab, ((long)i << ASHIFT) + ABASE, v);
}

对Node<K,V>[] 上任意一个index的读取和写入都使用了Unsafe辅助类，table本身是volatile类型的并不能保证其下的每个元素的内存语义也是volatile类型；

需要借助于Unsafe来保证Node<K,V>[]元素的“读/写/CAS”操作在多核并发环境下的原子或者可见性。

五、读操作get为什么是线程安全的

首先需要明确的是，C13Map的读操作一般是不加锁的(TreeBin的读写锁除外)，而读操作与写操作有可能并行；可以保证的是，因为C13Map的写操作都要获取bin头部的syncronized互斥锁，能保证最多只有一个线程在做更新，这其实是一个单线程写、多线程读的并发安全性的问题。

C13Map的get方法

public V get(Object key) {
    Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
    //执行扰动函数
    int h = spread(key.hashCode());
    if ((tab = table) != null && (n = tab.length) > 0 && (e = tabAt(tab, (n - 1) & h)) != null) {
        if ((eh = e.hash) == h) {
            if ((ek = e.key) == key || (ek != null && key.equals(ek)))
                return e.val;
        }
        else if (eh < 0)
            return (p = e.find(h, key)) != null ? p.val : null;
        while ((e = e.next) != null) {
            if (e.hash == h &&
                ((ek = e.key) == key || (ek != null && key.equals(ek))))
                return e.val;
        }
    }
    return null;
}

1、如果当前哈希表table为null

哈希表未初始化或者正在初始化未完成，直接返回null；虽然line5和line18之间其它线程可能经历了千山万水，至少在判断tab==null的时间点key肯定是不存在的，返回null符合某一时刻的客观事实。

2、如果读取的bin头节点为null

说明该槽位尚未有节点，直接返回null。

3、如果读取的bin是一个链表

说明头节点是个普通Node。

（1）如果正在发生链表向红黑树的treeify工作，因为treeify本身并不破坏旧的链表bin的结构，只是在全部treeify完成后将头节点一次性替换为新创建的TreeBin，可以放心读取。

（2）如果正在发生resize且当前bin正在被transfer，因为transfer本身并不破坏旧的链表bin的结构，只是在全部transfer完成后将头节点一次性替换为ForwardingNode，可以放心读取。

（3）如果其它线程正在操作链表，在当前线程遍历链表的任意一个时间点，都有可能同时在发生add/replace/remove操作。

• 如果是add操作，因为链表的节点新增从JDK8以后都采用了后入式，无非是多遍历或者少遍历一个tailNode。
• 如果是remove操作，存在遍历到某个Node时，正好有其它线程将其remove，导致其孤立于整个链表之外；但因为其next引用未发生变更，整个链表并没有断开，还是可以照常遍历链表直到tailNode。
• 如果是replace操作，链表的结构未变，只是某个Node的value发生了变化，没有安全问题。

结论：对于链表这种线性数据结构，单线程写且插入操作保证是后入式的前提下，并发读取是安全的；不会存在误读、链表断开导致的漏读、读到环状链表等问题。

4、如果读取的bin是一个红黑树

说明头节点是个TreeBin节点。

（1）如果正在发生红黑树向链表的untreeify操作，因为untreeify本身并不破坏旧的红黑树结构，只是在全部untreeify完成后将头节点一次性替换为新创建的普通Node，可以放心读取。

（2）如果正在发生resize且当前bin正在被transfer，因为transfer本身并不破坏旧的红黑树结构，只是在全部transfer完成后将头节点一次性替换为ForwardingNode，可以放心读取。

（3）如果其他线程在操作红黑树，在当前线程遍历红黑树的任意一个时间点，都可能有单个的其它线程发生add/replace/remove/红黑树的翻转等操作，参考下面的红黑树的读写锁实现。

TreeBin中的读写锁实现

 TreeNode<K,V> root;
    volatile TreeNode<K,V> first;
    volatile Thread waiter;
    volatile int lockState;
    // values for lockState
    static final int WRITER = 1; // set while holding write lock
    static final int WAITER = 2; // set when waiting for write lock
    static final int READER = 4; // increment value for setting read lock
 
    private final void lockRoot() {
        //如果一次性获取写锁失败，进入contendedLock循环体，循环获取写锁或者休眠等待
        if (!U.compareAndSetInt(this, LOCKSTATE, 0, WRITER))
            contendedLock(); // offload to separate method
    }
 
    private final void unlockRoot() {
        lockState = 0;
    }
    //对红黑树加互斥锁,也就是写锁
    private final void contendedLock() {
        boolean waiting = false;
        for (int s;;) {
            //如果lockState除了第二位外其它位上都为0，表示红黑树当前既没有上读锁，又没有上写锁，仅有可能存在waiter，可以尝试直接获取写锁
            if (((s = lockState) & ~WAITER) == 0) {
                if (U.compareAndSetInt(this, LOCKSTATE, s, WRITER)) {
                    if (waiting)
                        waiter = null;
                    return;
                }
            }
            //如果lockState第二位是0,表示当前没有线程在等待写锁
            else if ((s & WAITER) == 0) {
                //将lockState的第二位设置为1，相当于打上了waiter的标记，表示有线程在等待写锁
                if (U.compareAndSetInt(this, LOCKSTATE, s, s | WAITER)) {
                    waiting = true;
                    waiter = Thread.currentThread();
                }
            }
            //休眠当前线程
            else if (waiting)
                LockSupport.park(this);
        }
    }
     
    //查找红黑树中的某个节点
    final Node<K,V> find(int h, Object k) {
        if (k != null) {
            for (Node<K,V> e = first; e != null; ) {
                int s; K ek;
                //如果当前有waiter或者有写锁，走线性检索，因为红黑树虽然替代了链表，但其内部依然保留了链表的结构，虽然链表的查询性能一般，但根据先前的分析其读取的安全性有保证。
                //发现有写锁改走线性检索，是为了避免等待写锁释放花去太久时间; 而发现有waiter改走线性检索，是为了避免读锁叠加的太多，导致写锁线程需要等待太长的时间; 本质上都是为了减少读写碰撞
                //线性遍历的过程中，每遍历到下一个节点都做一次判断，一旦发现锁竞争的可能性减少就改走tree检索以提高性能
                if (((s = lockState) & (WAITER|WRITER)) != 0) {
                    if (e.hash == h &&
                        ((ek = e.key) == k || (ek != null && k.equals(ek))))
                        return e;
                    e = e.next;
                }
                //对红黑树加共享锁,也就是读锁,CAS一次性增加4，也就是增加的只是3~32位
                else if (U.compareAndSetInt(this, LOCKSTATE, s,
                                             s + READER)) {
                    TreeNode<K,V> r, p;
                    try {
                        p = ((r = root) == null ? null :
                             r.findTreeNode(h, k, null));
                    } finally {