ConcurrentHashMap1.8的一个bug！

第二遍看ConcurrentHashMap的过程中注意到了一个细节。
几乎把网上的博客都找遍了也没找到合理的解释，最后发现是一个bug。。。。。

private final void addCount(long x, int check) {
   //...
    if (check >= 0) {
        Node<K,V>[] 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) {
            	// 就是在这里！
            	// sc == rs + 1 和 sc == rs + MAX_RESIZERS是永远不会成立的。
           	    if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
                    sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
                    transferIndex <= 0)
                    break;
                if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
                    transfer(tab, nt);
            }
            else if (U.compareAndSwapInt(this, SIZECTL, sc,
                                         (rs << RESIZE_STAMP_SHIFT) + 2))
                transfer(tab, null);
            s = sumCount();
        }
    }
}

第一个去扩容的线程会把SIZECTL设成(rs << RESIZE_STAMP_SHIFT) + 2。
这样的话SIZECTL的低16位就表示当前正在扩容的线程数+1。

但是！！！
sc == rs + 1 和 sc == rs + MAX_RESIZERS 这两处判断里并没有把rs左移RESIZE_STAMP_SHIFT。
所以这里的判断是没有任何意义的。

正确的写法

sc == ( rs<<<RESIZE_STAMP_SHIFT ) +1 || sc == ( rs<<<RESIZE_STAMP_SHIFT ) + MAX_RESIZERS

影响到的地方还有helpTransfer

JDK bug地址：JDK-8214427