什么？JDK8 的 ConcurrentHashMap 有 Bug

大家看到标题是不是第一反应，怎么可能 JDK8 的 ConcurrentHsahMap 会有 bug，肯定是个标题党

且慢，的确我们 JDK8 中存在这个 Bug，但是这个 Bug 不影响使用，并且在 JDK12 中对其进行了修复

在这个 JDK 的 Bug 收集论坛上，我们可以看到这个报告指出的是在 ConcurrentHsahMap 进行 addCount() 的时候会有问题存在，我们先看一下具体在 JDK8 和 JDK12 中该方法的体现

JDK8

private final void addCount(long x, int check) {
        //...
        if (check >= 0) {
            Node[] tab, nt; int n, sc;
            while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
                   (n = tab.length) < MAXIMUM_CAPACITY) {
                int rs = resizeStamp(n);
                if (sc < 0) {
                    if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
                        sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
                        transferIndex <= 0)
                        break;
                    //...
                }
                //...
            }
        }
    }

 JDK12

private final void addCount(long x, int check) {
    //...
    if (check >= 0) {
        Node[] tab, nt;
        int n, sc;
        while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
                (n = tab.length) < MAXIMUM_CAPACITY) {
            int rs = resizeStamp(n) << RESIZE_STAMP_SHIFT;
            if (sc < 0) {
                if (sc == rs + MAX_RESIZERS || sc == rs + 1 ||
                        (nt = nextTable) == null || transferIndex <= 0)
                    break;
                //...
            } 
            //...
        }
    }
}

我们仔细对比一下代码，就可以发现在 JDK12 中去除了 (sc >>> RESIZE_STAMP_SHIFT) != rs

这个条件判断，那问题就来，这个条件出现了什么问题？

Doug Lea 这么细的人当初为什么没考虑到，欢迎走入今天的文章，揭秘一下这个 BUG 的前世今生，对 ConcurrentHashMap 扩容和计数逻辑熟悉的同学，可直接跳转第三部份看问题分析即可

基本定义

默认小伙伴对 ConcurrentHashMap 有初步的了解，以及清楚 CAS 算法等基础知识，此文不做展开说明

想要知道 ConcurrentHashMap 中的扩容和计数逻辑，我们需要先明白一些定义，不然直接开始读源码，我们会有点吃力

接下来会罗列一下一会我们 addCount 方法中会用到的一些基本定义，我们先混个眼熟

• sizeCtl

• sizeCtl 的定义有点复杂，但是也有