JDK8 ConcurrentHashMap的Bug集锦

https://blog.csdn.net/anlian523/article/details/107328200

前言

JDK8的ConcurrentHashMap并不是完美的，从- Java Bug System上也可以看到JDK的很多Bug，当然，通过给concurrency-interest发邮件也可以和Doug Lea直接对话。

最重要的是，知道了这些bug的存在，可以避免我们去分析这些不正确的代码的“正确性”。

构造器

关于构造器的bug

    public ConcurrentHashMap(int initialCapacity) {
        if (initialCapacity < 0)
            throw new IllegalArgumentException();
        int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1))
                   MAXIMUM_CAPACITY :
                   tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
        this.sizeCtl = cap;
    }
12345678

这里的initialCapacity + (initialCapacity >>> 1) + 1其实是一个bug，正确的做法应该是下面这个构造器的做法。

    public ConcurrentHashMap(int initialCapacity,
                             float loadFactor, int concurrencyLevel) {
        if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
            throw new IllegalArgumentException();
        if (initialCapacity < concurrencyLevel)   // Use at least as many bins
            initialCapacity = concurrencyLevel;   // as estimated threads
        long size = (long)(1.0 + (long)initialCapacity / loadFactor);
        //获得cap的正确做法
        int cap = (size >= (long)MAXIMUM_CAPACITY) ?
            MAXIMUM_CAPACITY : tableSizeFor((int)size);
        this.sizeCtl = cap;
    }
123456789101112

主要问题在于，两个构造器的行为不一致，即使第一个构造器传入(16)、第二个构造器传入(16, 0.75f, 1)，最终table的长度是不一样的。

sizeCtl

关于sizeCtl的bug

这个bug在helpTransfer和addCount中都有，主要对sizeCtl的临时变量的判断有问题。

它们都有这样一个判断sc == rs + 1 || sc == rs + MAX_RESIZERS，其中sc是获得了sizeCtl的临时变量，rs是一个与容量唯一对应的一个标签值（它占sizeCtl的高16bit）。所以应该这样写：sc == (rs << RESIZE_STAMP_SHIFT) + 1、sc == (rs << RESIZE_STAMP_SHIFT) + MAX_RESIZERS。

扩容部分的sweep recheck

Doug Lea老爷子给我的回复

在transfer的函数实现中，最后一个线程来归还sizeCtl的线程数时，需要从尾到头再检查一遍每个哈希桶是否都完成了转移，但这没有必要的。

Doug Lea也说了，这个sweep扫查机制是之前版本遗留下来的，本来是可以删除掉的。

删除掉没有任何影响，因为当最后一个线程来归还许可时，这意味着其他线程已经归还了许可。且只有在当前线程 完成了领取的任务后，才会归还许可，所以当最后一个线程来归还许可时，每个哈希桶都已经完成了转移，所以说最后的sweep检查是没有必要的。

看以后有时间，按照Request for Enhancement提个issue吧。

computeIfAbsent

computeIfAbsent的bug

当你执行这段代码时：

        Map<String, Integer> map = new ConcurrentHashMap<>(16);
        map.computeIfAbsent("AaAa", key -> {
            return map.computeIfAbsent("BBBB", key2 -> 42);
        });
1234

会发生无限循环。

过程如下（我们以左框距离代表调用深度）：

• 第一次调用

  computeIfAbsent

  ，参数是

  "AaAa"

  。第一次循环创建table，第二次循环将索引处从null设置为一个ReservationNode，第二次循环中，紧接着递归调用

  computeIfAbsent

  。

  • 第二次调用computeIfAbsent，参数是"BBBB"。第一次循环，发现该索引处（获得的是同一个索引）是一个ReservationNode，if (binCount != 0)分支没有进入，循环继续。一直重复这个循环。

后记

ConcurrentHashMap的bug其实不少，大家阅读源码时不要觉得源码就一定是正确的。另外，给一下JDK提bug的链接，以后有机会给JDK提提Bug，不过提之前先搜搜看是否有人已经提过了。