JDK8 ConcurrentHashMap的Bug集锦

蔚落 2023-02-26 02:28 27阅读 0赞

# 前言 #

JDK8的ConcurrentHashMap并不是完美的，从[https://bugs.openjdk.java.net/projects/JDK/issues][https_bugs.openjdk.java.net_projects_JDK_issues]上也可以看到JDK的很多Bug，当然，通过给[concurrency-interest][]发邮件也可以和Doug Lea直接对话。

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

# 构造器 #

[关于构造器的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;
        }

这里的`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;
        }

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

# sizeCtl #

[关于sizeCtl的bug][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老爷子给我的回复][Doug Lea]

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

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

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

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

# computeIfAbsent #

[computeIfAbsent的bug][computeIfAbsent_bug]

当你执行这段代码时：

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

会发生无限循环。

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

*  第一次调用`computeIfAbsent`，参数是`"AaAa"`。第一次循环创建table，第二次循环将索引处从null设置为一个ReservationNode，第二次循环中，紧接着递归调用`computeIfAbsent`。
    
     *  第二次调用`computeIfAbsent`，参数是`"BBBB"`。第一次循环，发现该索引处（获得的是同一个索引）是一个ReservationNode，`if (binCount != 0)`分支没有进入，循环继续。一直重复这个循环。

# 后记 #

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

[https_bugs.openjdk.java.net_projects_JDK_issues]: https://bugs.openjdk.java.net/projects/JDK/issues
[concurrency-interest]: http://cs.oswego.edu/mailman/listinfo/concurrency-interest
[bug]: https://bugs.openjdk.java.net/browse/JDK-8202422
[sizeCtl_bug]: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8214427
[Doug Lea]: http://cs.oswego.edu/pipermail/concurrency-interest/2020-July/017171.html
[computeIfAbsent_bug]: https://bugs.openjdk.java.net/browse/JDK-8062841
[JDK_bug]: https://bugreport.java.com/bugreport/hotspot_form.do?submit=Submit%20your%20Bug%20Report