谈谈ConcurrentHashMap1.7和1.8的不同实现

原文链接：http://www.jianshu.com/p/e694f1e868ec

http://pettyandydog.com/2017/07/27/concurrentHashMap/

ConcurrentHashMap

在多线程环境下，使用HashMap进行put操作时存在丢失数据的情况，为了避免这种bug的隐患，强烈建议使用ConcurrentHashMap代替HashMap，为了对ConcurrentHashMap有更深入的了解，本文将对ConcurrentHashMap1.7和1.8的不同实现进行分析。

1.7实现

数据结构

jdk1.7中采用Segment + HashEntry的方式进行实现，结构如下：

ConcurrentHashMap初始化时，计算出Segment数组的大小ssize和每个Segment中HashEntry数组的大小cap，并初始化Segment数组的第一个元素；其中ssize大小为2的幂次方，默认为16，cap大小也是2的幂次方，最小值为2，最终结果根据根据初始化容量initialCapacity进行计算，计算过程如下：

if (c * ssize < initialCapacity)    ++c;int cap = MIN_SEGMENT_TABLE_CAPACITY;while (cap < c)    cap <<= 1;

其中Segment在实现上继承了ReentrantLock，这样就自带了锁的功能。

put实现

当执行put方法插入数据时，（第一次hash）根据key的hash值，在Segment数组中找到相应的位置，如果相应位置的Segment还未初始化，则通过CAS进行赋值，（第二次hash）接着执行Segment对象的put方法通过加锁机制插入数据，实现如下：

场景：线程A和线程B同时执行相同Segment对象的put方法

1、线程A执行tryLock()方法成功获取锁，则把HashEntry对象插入到相应的位置；
2、线程B获取锁失败，则执行scanAndLockForPut()方法，在scanAndLockForPut方法中，会通过重复执行tryLock()方法尝试获取锁，在多处理器环境下，重复次数为64，单处理器重复次数为1，当执行tryLock()方法的次数超过上限时，则执行lock()方法挂起线程B；
3、当线程A执行完插入操作时，会通过unlock()方法释放锁，接着唤醒线程B继续执行；

size实现

因为ConcurrentHashMap是可以并发插入数据的，所以在准确计算元素时存在一定的难度，一般的思路是统计每个Segment对象中的元素个数，然后进行累加，但是这种方式计算出来的结果并不一样的准确的，因为在计算后面几个Segment的元素个数时，已经计算过的Segment同时可能有数据的插入或则删除，在1.7的实现中，采用了如下方式：

try {    for (;;) {        if (retries++ == RETRIES_BEFORE_LOCK) {            for (int j = 0; j < segments.length; ++j)                ensureSegment(j).lock(); // force creation        }        sum = 0L;        size = 0;        overflow = false;        for (int j = 0; j < segments.length; ++j) {            Segment<K,V> seg = segmentAt(segments, j);            if (seg != null) {                sum += seg.modCount;                int c = seg.count;                if (c < 0 || (size += c) < 0)                    overflow = true;            }        }        if (sum == last)            break;        last = sum;    }} finally {    if (retries > RETRIES_BEFORE_LOCK) {        for (int j = 0; j < segments.length; ++j)            segmentAt(segments, j).unlock();    }}

（乐观方法）先采用不加锁的方式，连续计算元素的个数，最多计算3次：
1、如果前后两次计算结果相同，则说明计算出来的元素个数是准确的；
2、如果前后两次计算结果都不同，则给每个Segment进行加锁，再计算一次元素的个数；

1.8实现

数据结构

1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现，结构如下：

只有在执行第一次put方法时才会调用initTable()初始化Node数组，实现如下：

private final Node<K,V>[] initTable() {    Node<K,V>[] tab; int sc;    while ((tab = table) == null || tab.length == 0) {        if ((sc = sizeCtl) < 0)            Thread.yield(); // lost initialization race; just spin        else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {            try {                if ((tab = table) == null || tab.length == 0) {                    int n = (sc > 0) ? sc : DEFAULT_CAPACITY;                    @SuppressWarnings("unchecked")                    Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];                    table = tab = nt;                    sc = n - (n >>> 2);                }            } finally {                sizeCtl = sc;            }            break;        }    }    return tab;}

put实现

当执行put方法插入数据时，根据key的hash值，在Node数组中找到相应的位置，实现如下：

1、如果相应位置的Node还未初始化，则通过CAS插入相应的数据；

else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {    if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value, null)))        break;                   // no lock when adding to empty bin}

2、如果相应位置的Node不为空，且当前该节点不处于移动状态，则对该节点加synchronized锁，如果该节点的hash不小于0，则遍历链表更新节点或插入新节点；

if (fh >= 0) {    binCount = 1;    for (Node<K,V> e = f;; ++binCount) {        K ek;        if (e.hash == hash &&            ((ek = e.key) == key ||             (ek != null && key.equals(ek)))) {            oldVal = e.val;            if (!onlyIfAbsent)                e.val = value;            break;        }        Node<K,V> pred = e;        if ((e = e.next) == null) {            pred.next = new Node<K,V>(hash, key, value, null);            break;        }    }}

3、如果该节点是TreeBin类型的节点，说明是红黑树结构，则通过putTreeVal方法往红黑树中插入节点；

else if (f instanceof TreeBin) {    Node<K,V> p;    binCount = 2;    if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key, value)) != null) {        oldVal = p.val;        if (!onlyIfAbsent)            p.val = value;    }}

4、如果binCount不为0，说明put操作对数据产生了影响，如果当前链表的个数达到8个，则通过treeifyBin方法转化为红黑树，如果oldVal不为空，说明是一次更新操作，没有对元素个数产生影响，则直接返回旧值；

if (binCount != 0) {    if (binCount >= TREEIFY_THRESHOLD)        treeifyBin(tab, i);    if (oldVal != null)        return oldVal;    break;}

5、如果插入的是一个新节点，则执行addCount()方法尝试更新元素个数baseCount；

size实现

1.8中使用一个volatile类型的变量baseCount记录元素的个数，当插入新数据或则删除数据时，会通过addCount()方法更新baseCount，实现如下：

if ((as = counterCells) != null ||    !U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {    CounterCell a; long v; int m;    boolean uncontended = true;    if (as == null || (m = as.length - 1) < 0 ||        (a = as[ThreadLocalRandom.getProbe() & m]) == null ||        !(uncontended =          U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {        fullAddCount(x, uncontended);        return;    }    if (check <= 1)        return;    s = sumCount();}

1、初始化时counterCells为空，在并发量很高时，如果存在两个线程同时执行CAS修改baseCount值，则失败的线程会继续执行方法体中的逻辑，使用CounterCell记录元素个数的变化；

2、如果CounterCell数组counterCells为空，调用fullAddCount()方法进行初始化，并插入对应的记录数，通过CAS设置cellsBusy字段，只有设置成功的线程才能初始化CounterCell数组，实现如下：

elseif (cellsBusy == 0&& counterCells == as &&         U.compareAndSwapInt(this, CELLSBUSY, 0,1)) {    booleaninit = false;    try{                           // Initialize table        if(counterCells == as) {            CounterCell[] rs = newCounterCell[2];            rs[h & 1] = newCounterCell(x);            counterCells = rs;            init = true;        }    }finally{        cellsBusy = 0;    }    if(init)        break;}

3、如果通过CAS设置cellsBusy字段失败的话，则继续尝试通过CAS修改baseCount字段，如果修改baseCount字段成功的话，就退出循环，否则继续循环插入CounterCell对象；

else if (U.compareAndSwapLong(this, BASECOUNT, v = baseCount, v + x))    break;

所以在1.8中的size实现比1.7简单多，因为元素个数保存baseCount中，部分元素的变化个数保存在CounterCell数组中，实现如下：

public int size() {    long n = sumCount();    return ((n < 0L) ? 0 :            (n > (long)Integer.MAX_VALUE) ? Integer.MAX_VALUE :            (int)n);} final long sumCount() {    CounterCell[] as = counterCells; CounterCell a;    long sum = baseCount;    if (as != null) {        for (int i = 0; i < as.length; ++i) {            if ((a = as[i]) != null)                sum += a.value;        }    }    return sum;}

通过累加baseCount和CounterCell数组中的数量，即可得到元素的总个数；

JDK1.8的实现已经摒弃了Segment的概念，而是直接用Node数组+链表+红黑树的数据结构来实现，并发控制使用Synchronized和CAS来操作，整个看起来就像是优化过且线程安全的HashMap，虽然在JDK1.8中还能看到Segment的数据结构，但是已经简化了属性，只是为了兼容旧版本。

Node是ConcurrentHashMap存储结构的基本单元，继承于HashMap中的Entry，用于存储数据，

Node数据结构很简单，从上可知，就是一个链表，但是只允许对数据进行查找，不允许进行修改。

TreeNode

TreeNode继承与Node，但是数据结构换成了二叉树结构，它是红黑树的数据的存储结构，用于红黑树中存储数据，当链表的节点数大于8时会转换成红黑树的结构，他就是通过TreeNode作为存储结构代替Node来转换成黑红树源代码如下。

TreeBin

TreeBin从字面含义中可以理解为存储树形结构的容器，而树形结构就是指TreeNode，所以TreeBin就是封装TreeNode的容器，它提供转换黑红树的一些条件和锁的控制，部分源码结构如下。

总结与思考

其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树,相对而言，总结如下思考：

1. JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
2. JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
3. JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
4. JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点：

• 因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
• JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
• 在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据