JDK8 ConcurrentHashMap的Bug集锦

news/2024/5/20 8:54:06 标签: java, jdk, bug, JUC, hashmap

前言

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

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

构造器

关于构造器的bug

java">    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,正确的做法应该是下面这个构造器的做法。

java">    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

这个bughelpTransferaddCount中都有,主要对sizeCtl的临时变量的判断有问题。

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

扩容部分的sweep recheck

Doug Lea老爷子给我的回复

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

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

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

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

computeIfAbsent

computeIfAbsent的bug

当你执行这段代码时:

java">        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,不过提之前先搜搜看是否有人已经提过了。


http://www.niftyadmin.cn/n/768185.html

相关文章

JUC集合类 ConcurrentLinkedQueue源码解析 JDK8

文章目录前言概述不变式基本不变式headtail初始化队列初始化Node初始化add/offer 入队操作出队操作pollpeekfirstremove 删除操作remove的bugsize 弱一致性的方法addAll迭代器总结前言 ConcurrentLinkedQueue是一种FIFO&#xff08;first-in-first-out 先入先出&#xff09;的…

JUC集合类 ConcurrentLinkedDeque源码解析 JDK8

文章目录前言概述linkFirst 入队pollFirst 获取并出队first()succ()unlink()unlinkFirstskipDeletedPredecessorsupdateHeadupdateTailgc-unlinking松弛阈值unlink的Unlink interior node逻辑peekFirst 仅获取remove 删除操作size迭代器总结前言 ConcurrentLinkedDeque是一个无…

JUC集合类 ArrayBlockingQueue源码解析 JDK8

文章目录前言成员构造器入队addofferput超时offer总结出队peekpolltake超时poll总结remove 删除操作总结前言 ArrayBlockingQueue是一种FIFO&#xff08;first-in-first-out 先入先出&#xff09;的有界阻塞队列&#xff0c;底层是数组&#xff0c;也支持从内部删除元素。并发…

JDK8 ArrayBlockingQueue迭代器 源码解析

文章目录前言Itr成员Itr构造器以及public方法Itrs对Itr的管理ArrayBlockingQueue里对Itrs的调用itrs.elementDequeued()itrs.removedAt(removeIndex)为什么Itrs会去掉失效的迭代器总结前言 ArrayBlockingQueue的迭代器也是弱一致性的&#xff0c;体现在于队列元素被删除后&…

JUC集合类 LinkedBlockingQueue源码解析 JDK8

文章目录前言成员构造器入队addofferput超时offer入队方法总结出队removepolltake超时poll出队方法总结内部删除 remove(Object o)获取操作peekelement迭代器总结前言 LinkedBlockingQueue是一种FIFO&#xff08;first-in-first-out 先入先出&#xff09;的有界阻塞队列&#…

JUC集合类 LinkedBlockingDeque源码解析 JDK8

文章目录前言成员构造器入队操作putFirstputLast出队操作takeFirsttakeLast删除内部节点removeFirstOccurrenceremoveLastOccurrence迭代器总结前言 LinkedBlockingDeque是一种有界阻塞队列&#xff0c;它的底层是双向链表&#xff0c;所以它是双向的。也就是说&#xff0c;在…

打印一颗基于数组的完全二叉树——Python3实现

前言 最近在复习堆排序的内容&#xff0c;发现基于数组的堆虽然用起来很方便&#xff0c;但打印不方便。所以本文实现了一个简单美观的打印一颗基于数组的完全二叉树的算法&#xff08;堆就是一种完全二叉树嘛&#xff0c;但实现最小堆一般是基于数组的&#xff09;。 算法思…

表单设计器资料收集

由于公司一些需求&#xff0c;收集了一些有关表单设计器&#xff0c;主要是一些技术特点、各自的优缺点记录&#xff0c;以此记录一下。 FormMaking http://form.making.link/ FormMaking 表单设计器是一个基于 Vue 和 ElementUI 的可视化表单设计器&#xff0c;支持 i18n 国…