ConcurrentHashMap 的工作原理及源码分析,如何统计所有的元素个数

ConCurrentHashMap并发环境时,如何计数的?—— sumCount()、fullAddCount() ConCurrentHashMap 在并发环境下的计数问题。主要有两个手段。针对源码,本文进行详细的说明 阅读详情

1.ConcurrentHashMap(线程安全):

ConcurrentHashMap采用了非常精妙的"分段锁"策略,ConcurrentHashMap的主干是个Segment数组。

 final Segment<K,V>[] segments;

Segment继承了ReentrantLock(参照:https://blog.youkuaiyun.com/striveb/article/details/83421107),所以它就是一种可重入锁(ReentrantLock)。在ConcurrentHashMap,一个Segment就是一个子哈希表,Segment里维护了一个HashEntry数组,并发环境下,对于不同Segment的数据进行操作是不用考虑锁竞争的。(就按默认的ConcurrentLeve为16来讲,理论上就允许16个线程并发执行 )。所以,对于同一个Segment的操作才需考虑线程同步,不同的Segment则无需考虑。

Segment类似于HashMap,一个Segment维护着一个HashEntry数组:

transient volatile HashEntry<K,V>[] table;

HashEntry是目前我们提到的最小的逻辑处理单元了。一个ConcurrentHashMap维护一个Segment数组,一个Segment维护一个HashEntry数组。 

static final class HashEntry<K,V> {
        final int hash;
        final K key;
        volatile V value;
        volatile HashEntry<K,V> next;

        HashEntry(int hash, K key, V value, HashEntry<K,V> next) {
            this.hash = hash;
            this.key = key;
            this.value = value;
            this.next = next;
        }
    }

Segment构造方法: 

Segment(float lf, int threshold, HashEntry<K,V>[] tab) {
            this.loadFactor = lf;//负载因子
            this.threshold = threshold;//阈值
            this.table = tab;//主干数组即HashEntry数组
        }

 Segment类似哈希表,那么一些属性就跟我们之前提到的HashMap差不离,比如负载因子loadFactor,比如阈值threshold等等。

  • 存储结构: ConcurrentHashMap 和 HashMap 实现上类似,最主要的差别是 ConcurrentHashMap 采用了分段锁(Segment),每个分段锁维护着几个桶(HashEntry),多个线程可以同时访问不同分段锁上的桶,从而使其并发度更高(并发度就是 Segment 的个数)。
  • 数据结构(JDK1.7):

如图所示,是由 Segment 数组、HashEntry 数组组成,和 HashMap 一样,仍然是数组加链表组成。ConcurrentHashMap 采用了分段锁技术,其中 Segment 继承于 ReentrantLock。不会像 HashTable 那样不管是 put 还是 get 操作都需要做同步处理,理论上 ConcurrentHashMap 支持 CurrencyLevel (Segment 数组数量)的线程并发。每当一个线程占用锁访问一个 Segment 时,不会影响到其他的 Segment。

ConcurrentHashMap构造方法:

public ConcurrentHashMap(int initialCapacity,
                               float loadFactor, int concurrencyLevel) {
          if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
              throw new IllegalArgumentException();
          //MAX_SEGMENTS 为1<<16=65536,也就是最大并发数为65536
          if (concurrencyLevel > MAX_SEGMENTS)
              concurrencyLevel = MAX_SEGMENTS;
          //2的sshif次方等于ssize,例:ssize=16,sshift=4;ssize=32,sshif=5
         int sshift = 0;
         //ssize 为segments数组长度,根据concurrentLevel计算得出
         int ssize = 1;
         while (ssize < concurrencyLevel) {
             ++sshift;
             ssize <<= 1;
         }
         //segmentShift和segmentMask这两个变量在定位segment时会用到,后面会详细讲
         this.segmentShift = 32 - sshift;
         this.segmentMask = ssize - 1;
         if (initialCapacity > MAXIMUM_CAPACITY)
             initialCapacity = MAXIMUM_CAPACITY;
         //计算cap的大小,即Segment中HashEntry的数组长度,cap也一定为2的n次方.
         int c = initialCapacity / ssize;
         if (c * ssize < initialCapacity)
             ++c;
         int cap = MIN_SEGMENT_TABLE_CAPACITY;
         while (cap < c)
             cap <<= 1;
         //创建segments数组并初始化第一个Segment,其余的Segment延迟初始化
         Segment<K,V> s0 =
             new Segment<K,V>(loadFactor, (int)(cap * loadFactor),
                              (HashEntry<K,V>[])new HashEntry[cap]);
         Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
         UNSAFE.putOrderedObject(ss, SBASE, s0); 
         this.segments = ss;
     }

初始化方法有三个参数,如果用户不指定则会使用默认值,initialCapacity为16,loadFactor为0.75(负载因子,扩容时需要参考),concurrentLevel为16。

  从上面的代码可以看出来,Segment数组的大小ssize是由concurrentLevel来决定的,但是却不一定等于concurrentLevel,ssize一定是大于或等于concurrentLevel的最小的2的次幂。比如:默认情况下concurrentLevel是16,则ssize为16;若concurrentLevel为14,ssize为16;若concurrentLevel为17,则ssize为32。为什么Segment的数组大小一定是2的次幂?其实主要是便于通过按位与的散列算法来定位Segment的index。

  • 默认的并发级别为 16,也就是说默认创建 16 个 Segment。
  • get 方法:ConcurrentHashMap的 Segment的get操作实现非常简单和高效。,因为整个过程都不需要加锁。
    public V get(Object key) {
            Segment<K,V> s; 
            HashEntry<K,V>[] tab;
            int h = hash(key);
            long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE;
            //先定位Segment,再定位HashEntry
            if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null &&
                (tab = s.table) != null) {
                for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile
                         (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE);
                     e != null; e = e.next) {
                    K k;
                    if ((k = e.key) == key || (e.hash == h && key.equals(k)))
                        return e.value;
                }
            }
            return null;
        }

    只需要将 Key 通过 Hash 之后定位到具体的 Segment ,再通过一次 Hash 定位到具体的元素上。由于 HashEntry 中的 value 属性是用 volatile 关键词修饰的,保证了内存可见性,所以每次获取时都是最新值,但不能保证多个线程写。根据Java内存模型的happen before原则,对volatile字段的写入操作先于读操作,即使两个线程同时修改和获取volatile变量,get操作也能拿到最新的值,这是用volatile替换锁的经典应用场景。

  • put 方法:

    public V put(K key, V value) {
            Segment<K,V> s;
            //concurrentHashMap不允许key/value为空
            if (value == null)
                throw new NullPointerException();
            //hash函数对key的hashCode重新散列,避免差劲的不合理的hashcode,保证散列均匀
            int hash = hash(key);
            //返回的hash值无符号右移segmentShift位与段掩码进行位运算,定位segment
            int j = (hash >>> segmentShift) & segmentMask;
            if ((s = (Segment<K,V>)UNSAFE.getObject          // nonvolatile; recheck
                 (segments, (j << SSHIFT) + SBASE)) == null) //  in ensureSegment
                s = ensureSegment(j);
            return s.put(key, hash, value, false);
        }

    虽然 HashEntry 中的 value 是用 volatile 关键词修饰的,但是并不能保证并发的原子性,所以 put 操作时仍然需要加锁处理。首先也是通过 Key 的 Hash 定位到具体的 Segment,在 put 之前会进行一次扩容校验。这里比 HashMap 要好的一点是:HashMap 是插入元素之后再看是否需要扩容,有可能扩容之后后续就没有插入就浪费了本次扩容(扩容非常消耗性能)。而 ConcurrentHashMap 不一样,它是在将数据插入之前检查是否需要扩容,之后再做插入操作。在扩容的时,首先会创建一个容量是原来容量两倍的数组,然后将原数组里的元素进行再散列后插入到新的数组里。为了高效,ConcurrentHashMap不会对整个容器进行扩容,而只对某个segment进行扩容。主要就分为两步:1.定位segment并确保定位的Segment已初始化 2.调用Segment的put方法。

  • size 方法:每个 Segment 维护了一个 count 变量来统计该 Segment 中的键值对个数。
    /**
     * The number of elements. Accessed only either within locks
     * or among other volatile reads that maintain visibility.
     */
    transient int count;

    如果要统计整个ConcurrentHashMap里元素的大小,就必须统计所有Segment里元素的大小后求和。Segment里的全局变量count是一个volatile变量,在多线程场景下,是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢?不是的,虽然相加时可以获取每个Segment的count的最新值,但是可能累加前使用的count发生了变化,那么统计结果就不准了。所以,最安全的做法是在统计size的时候把所有Segment的put、remove和clean方法全部锁住,但是这种做法显然非常低效。

    因为在累加count操作过程中,之前累加过的count发生变化的几率非常小,所以ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小,如果统计的过程中,容器的count发生了变化,则再采用加锁的方式来统计所有Segment的大小。尝试次数使用 RETRIES_BEFORE_LOCK 定义,该值为 2,retries 初始值为 -1,因此尝试次数为 3。如果尝试的次数超过 3 次,就需要对每个 Segment 加锁。

    /**
     * Number of unsynchronized retries in size and containsValue
     * methods before resorting to locking. This is used to avoid
     * unbounded retries if tables undergo continuous modification
     * which would make it impossible to obtain an accurate result.
     */
    static final int RETRIES_BEFORE_LOCK = 2;
    
    public int size() {
        // Try a few times to get accurate count. On failure due to
        // continuous async changes in table, resort to locking.
        final Segment<K,V>[] segments = this.segments;
        int size;
        boolean overflow; // true if size overflows 32 bits
        long sum;         // sum of modCounts
        long last = 0L;   // previous sum
        int retries = -1; // first iteration isn't retry
        try {
            for (;;) {
                // 超过尝试次数,则对每个 Segment 加锁
                if (retries++ == RETRIES_BEFORE_LOCK) {
                    for (int j = 0; j < segments.length; ++j)
                        ensureSegment(j).lock(); // force creation
                }
                sum = 0L;
                size = 0;
                overflow = false;
                for (int j = 0; j < segments.length; ++j) {
                    Segment<K,V> seg = segmentAt(segments, j);
                    if (seg != null) {
                        sum += seg.modCount;
                        int c = seg.count;
                        if (c < 0 || (size += c) < 0)
                            overflow = true;
                    }
                }
                // 连续两次得到的结果一致,则认为这个结果是正确的
                if (sum == last)
                    break;
                last = sum;
            }
        } finally {
            if (retries > RETRIES_BEFORE_LOCK) {
                for (int j = 0; j < segments.length; ++j)
                    segmentAt(segments, j).unlock();
            }
        }
        return overflow ? Integer.MAX_VALUE : size;
    }

    每个 Segment 都有一个 modCount 变量,每当进行一次 put、remove和clean 等操作,modCount 将会 +1。只要 modCount 发生了变化就认为容器的大小也在发生变化。

  • JDK1.8的实现:

抛弃了原有的 Segment 分段锁,而采用了 CAS + synchronized 来保证并发安全性。

也将 1.7 中存放数据的 HashEntry 改为 Node,但作用都是相同的。其中的 val next 都用了 volatile 修饰,保证了可见性。

put方法:

 

  • 根据 key 计算出 hashcode 。
  • 判断是否需要进行初始化。
  • f 即为当前 key 定位出的 Node,如果为空表示当前位置可以写入数据,利用 CAS 尝试写入,失败则自旋保证成功。
  • 如果当前位置的 hashcode == MOVED == -1,则需要进行扩容。
  • 如果都不满足,则利用 synchronized 锁写入数据。
  • 如果数量大于 TREEIFY_THRESHOLD 则要转换为红黑树。

get方法:

 

  • 根据计算出来的 hashcode 寻址,如果就在桶上那么直接返回值。
  • 如果是红黑树那就按照树的方式获取值。
  • 都不满足那就按照链表的方式遍历获取值。

总结

1.8 在 1.7 的数据结构上做了大的改动,采用红黑树之后可以保证查询效率(O(logn)),甚至取消了 ReentrantLock 改为了 synchronized,这样可以看出在新版的 JDK 中对 synchronized 优化是很到位的。

 

推荐几篇不错的文章:

https://blog.youkuaiyun.com/fjse51/article/details/55260493

https://crossoverjie.top/2018/07/23/java-senior/ConcurrentHashMap/

http://www.cnblogs.com/chengxiao/p/6842045.html

 

觉得有收获的,可以来一波赞赏!

ConcurrentHashMap 学习+面试 ConcurrentHashMap面试 阅读详情

相关推荐

从扇束到平行束:等角重排算法在CT重建中的核心原理与MATLAB实践

本文深入解析了CT图像重建中等角扇束重排算法的核心原理与MATLAB实现。通过将实际采集的扇束投影数据,利用几何映射和两次关键插值,转换为适用于经典滤波反投影算法的平行束数据,打通了高效重建的关键路径。文章结合Shepp-Logan模型仿真,提供了完整的MATLAB代码实践,并分析了源-物距、采样率等关键参数对重建质量的影响。

cnn8visionary的博客 647

细说ConcurrentHashMap计数规则

对于ConcurrentHashMap而言,需要保证的是任何操作的线程安全,包括对集合元素个数的统计。 一般在多线程下要统计一个全局数量大小,可以通过cas+循环(或者直接用Atomic相关的类)的方式实现,但是ConcurrentHashMap作者却并不是这样实现的。 先看看如何获取集合中的元素个数,通过调用size()方法: public int size() { long n = sumCount(); return ((n < 0L) ? 0 : (n

ljcgit的博客 1929

基于IMU的纯惯性导航轨迹绘制实践与优化

本文深入探讨了基于IMU的纯惯性导航轨迹绘制实践。通过修改开源组合导航算法KF-GINS,屏蔽GPS更新并简化地球参数,实现了仅依赖IMU数据的轨迹解算。文章详细介绍了代码改造、轨迹可视化方法,并分析了误差累积的根本原因,为深入理解惯性导航原理与传感器融合的必要性提供了宝贵的实践经验。

ff678的博客 395

认真研究ConcurrentHashMap中的元素统计策略

这里我们想研究的是jdk1.8中ConcurrentHashMap的`addCount(long x, int check)`方法。如下所示在put方法的最后会触发`addCount(long x, int check)`方法进行元素个数的统计。 ![在这里插入图片描述](https://img-blog.csdnimg.cn/910b40b954824bceb3a9cc4d61b6f8d1.png) 我们再回顾一下另一个参数binCount : * 在操作链表的分支if (fh >= 0)中 用于统计

小小默:进无止境 1352

嵌入式学习之QT学习---14 QT跨平台运行之把QT程序交叉编译到ARM开发板

想要把qt工程放到开发板上运行,就需要用到交叉编译。由于qt是跨平台的,所以只需要换个编译器编译一下就可以。 以“定时器”的例子为例,在移植之前还需要进行一个准备工作,在windows下运行的时候,电脑屏幕很大,但是运行的窗口只有一点点大,开发板也有外接屏幕,如何让运行窗口自动适配开发板的外接屏幕呢?令其占满屏幕显示,而不是一小块。 第一步:需要设置一下,先给ui布局,如果不布局,控件就不会随着屏幕的大小的变化而变化。 第二步:利用代码来获取屏幕的大小,给widget.cpp文件下添加如下代码 #inclu

qq_42822743的博客 5457

Proteus仿真实战:ADC0832时序解析与51单片机精准电压采集

本文详细解析了ADC0832模数转换芯片在Proteus仿真环境中的时序控制与51单片机驱动实现。通过实战代码示例和精度优化技巧,帮助开发者掌握电压采集的关键技术,包括时序配置、数据校验和噪声抑制等核心要点,提升嵌入式系统设计的精准度与可靠性。

weixin_29172963的博客 873

java ConcurrentHashMap的实现及原理

本文是咕泡学院的上课笔记,如果你喜欢欢迎加入 1、在多线程环境下,使用HashMap进行put操作会引起死循环,导致CPU利用率接近100%,所以在并发情况下不能使用HashMap。 2、HashTable容器使用synchronized来保证线程安全,但在线程竞争激烈的情况下HashTable的效率非常低下。 3、为了解决上述问题ConcurrentHashMap应用而生 jdk1.7采...

lbx1314ybfq的专栏 684

把 SAP Activate 六个阶段看透:从项目落地到 SAP BTP 扩展与 AI 运营的一体化实践

摘要: SAP Activate 方法论常被误解为简单的项目阶段划分,实则是一套将业务目标、标准流程、系统配置和持续运营串联的实施控制体系。其六个阶段(Discover至Run)构成价值递进的实施通道,核心交付集中在Prepare到Deploy阶段。Discover阶段通过DDA评估确立项目方向与范围,Prepare阶段聚焦可执行性准备,Explore阶段采用Fit-to-Standard工作坊进行需求分层,Realize阶段基于前期决策进行配置与扩展开发。该方法论强调标准化优先,差异化需求通过SAP BT

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 2332

ConcurrentHashMap源码分析之计数:addCount、fullAddCount、size

ConcurrentHashMap(以下简称CHM)的计数比较有特色,跟很多实现不同的是,CHM并没有一个专门的属性数据,在实现上也没有用锁来同步。那么它到底是怎么实现的呢? CHM计数的总体原理 CHM在实现计数时,主要借助的是baseCount和counterCells(数组)两个属性。 baseCount是原生类型long,默认值0L baseCount在首次添加元素的时候设置为1 视并发情况的不同,可能在addCount中赋值,也可能在fullAddCount中赋值,且仅赋值一次 counterC

大数据时代的狂欢 1093

10分钟搞定manim安装与vscode配置

manim安装与vscode配置

帅帅de三叔 3413

【异常】DeepSeek API HTTP 401 认证失败错误完整排查与解决方案

摘要:本文针对DeepSeek API开发中的HTTP 401认证失败错误进行深度解析,指出该错误属于不可重试的认证类问题。文章首先拆解错误日志关键字段,区分401与其他API错误的本质差异。随后提供优先级排序的全链路解决方案:1)检查API密钥有效性;2)规范请求头认证格式;3)排查账户权限状态;4)验证请求环境配置。最后建议通过新建测试密钥、使用官方示例代码或联系技术支持进行兜底处理。全文采用技术脱敏处理,为开发者提供系统性的401错误排查指南。(149字)

奶爸的编程之路,也就一周冷个三天 1531

ConcurrentHashMap原理分析

1. 实现原理 ConcurrentHashMap使用分段锁技术,将数据分成一段一段的存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据的时候,其他段的数据也能被其他线程访问,能够实现真正的并发访问。如下图是ConcurrentHashMap的内部结构图:   从图中可以看到,ConcurrentHashMap内部分为很多个Segment,每一个Segment拥有一把锁,

TinnnnnnY 461

069、PCIE属性字段:缓存、顺序与安全

上个月调试一块自研的PCIE采集卡,遇到了一个诡异的问题:主机通过DMA从设备读取图像数据,大部分帧正常,但偶尔会出现局部数据错位,像是缓存没刷干净。用逻辑分析仪抓链路层报文,发现TLP(事务层包)本身完好,但内存中的数据就是不对。排查三天后,终于锁定在设备端TLP的**属性字段(Attribute Field)**配置上——那几位看似不起眼的缓存、顺序控制位,差点让项目延期。今天我们就拆解PCIE事务头中的这个关键区域,看看它如何影响系统性能与数据安全。

z534437748的博客 50

ConcurrentHashMap 并发扩容骚操作

上期问题 少年,老衲看你骨骼清奇,眉宇之间透露着一股王者的气息。来吧,跟我讲讲 ConcurrentHashMap 是如何进行管理它的容量的,也就是当我们调用它的 size 方法的时候发生了什么故事?(前面我们介绍了 ConcurrentHashMap 的实现原理,但是扩容和容量大小留了个小尾巴,今天来割一下这个小尾巴,嘿嘿) 我的答案 毕竟是要支持并发,ConcurrentHashMap 的扩容...

SuperStonne的专栏 2429

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

复分析 阿尔福斯(Ahlfors) 第三版答案 英文

答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案

并发编程之ConcurrentHashMap源码分析

1. 存在线程竞争的table初始化、赋值以及扩容、数据转移处采用细粒度的CAS操作提升并发效率,整体主要是CAS机制和同步代码块结合使用2. 多线程并发协助扩容和数据转移,在数据转移处,采用多线程并发协助转移各个不同的分段区间,来提升table扩容时数据迁移的效率3.数据迁移时的链表采用高低位快速迁移的方法提升效率。

still_five_Days的博客 711

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

扩容原理_ConcurrentHashMap 并发扩容骚操作,你了解吗?

原创: 毛毛虫 毛毛虫流鼻涕 昨天Photo By Instagram juig.yyn上期问题 少年,老衲看你骨骼清奇,眉宇之间透露着一股王者的气息。来吧,跟我讲讲 ConcurrentHashMap 是如何进行管理它的容量的,也就是当我们调用它的 size 方法的时候发生了什么故事?(前面我们介绍了 ConcurrentHashMap 的实现原理,但是扩容和容量大小留了个小尾巴,今天来割一下这...

weixin_30496999的博客 1092

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

从源码分析ConcurrentHashMap

介绍 作为线程安全的HashMap,Java提供了Hashtable和ConcurrentHashMap两种实现,而Hashtable控制线程安全的方式仅仅是用synchronized对方法加锁,这种低效且过时的方法已经不适合如今的开发 在JDK5中,就已经出现了ConcurrentHashMap作为Hashtable的高效替代品。在JDK7及之前,ConcurrentHashMap还是使用分段锁...

Ekmr的博客 177

ConcurrentHashMap底层详解(图解扩容)(JDK1.8)

数据结构 使用数组+链表+红黑树来实现,利用 CAS + synchronized 来保证并发更新的安全 源码分析 put方法 public V put(K key, V value) { return putVal(key, value, false); } final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw

愿万事胜意 3万+

Java集合源码分析(六)——ConcurrentHashMap

简介 ConcurrentHashMap 是一个线程安全的散列表,存储的内容是键值对映射。 ConcurrentHashMap 继承于AbstractMap,实现了ConcurrentMap、Serializable接口。 ConcurrentHashMap 存储的键值对是无序的。 源码分析 父类 AbstractMap 接口 ConcurrentMap Serializable 字段 // 数组最大容量 private static final int MAXIMUM_CAPACITY

Think Different. 284

ConcurrentHashMap 并发扩容骚操作,你了解吗?

PhotoBy Instagramjuig.yyn上期问题少年,老衲看你骨骼清奇,眉宇之间透露着一股王者的气息。来吧,跟我讲讲 ConcurrentHashMap 是如何进行管理它...

SuperStonne的专栏 600

ConcurrentHashMap源码分析(jdk8)

前言 ​ 数组+链表+红黑树 CHM是一个线程安全的Map集合。 这里主要分析以下内容。 初始化Map 插入元素 扩容机制 链表转红黑树 元素统计 读前 ​ 首先了解一下用到的几个ConcurrentHashMap几个内部类。 Node 链表节点 TreeNode 红黑树节点 CounterCell 用于计算元素个数 ForwardingNode 用于扩容时占位 SIZECTL SIZECTL ==-1 表示有线程正在初始化Map SIZECTL < -1 表示有线程正在扩容

WangYangXiang的博客 279

ConcurrentHashMap的源码分析-addCount

在putVal最后调用addCount的时候,传递了两个参数,分别是1和binCount(链表长度),看看addCount方法里面做了什么操作 x表示这次需要在表中增加的元素个数,check参数表示是否需要进行扩容检查,大于等于0都需要进行检查 private final void addCount(long x, int check) { CounterCell[] as; long b, s; 判断counterCells是否为空, 1. 如果为空,就通过cas操作尝试修改baseCoun

Leon_Jinhai_Sun的博客 360

ConcurrentHashMap的源码分析-CounterCells解释

ConcurrentHashMap是采用CounterCell数组来记录元素个数的,像一般的集合记录集合大小,直接定义一个size的成员变量即可,当出现改变的时候只要更新这个变量就行。为什么ConcurrentHashMap要用这种形式来处理呢? 问题还是处在并发上,ConcurrentHashMap是并发集合,如果用一个成员变量来统计元素个数的话,为了保证并发情况下共享变量的的难全兴,势必会需要通过加锁或者自旋来实现,如果竞争比较激烈的情况下,size的设置上会出现比较大的冲突反而影响了性能,所以在Co

Leon_Jinhai_Sun的博客 876

ConcurrentHashmap核心源码分析(一)

以下内容为本人学习小刘老师的源码课程后(哔哩哔哩搜索,小刘讲源码),自己整理的笔记。仅供自己学习之用。 这里写目录标题一级目录二级目录常量Constants成员属性Fields静态代码块内部类NodeTreeNodeForwardingNode内部小方法源码分析static final int spread(int h)Node一级目录 二级目录     concurrenthashmap的扩容,数据迁移的动作是从下往上走的(以数组来看)。这样的好处是为了避免和迭代操作发生冲突。比如说,我在迭代访问conc

菼执的博客 668

ConcurrentHashMap1.8 最最最最最详细源码分析

声明:本文只有源码分析注释,提供正在研究ConcurrentHashMap源码的同学参考!!! 1、相关重要属性 /** * concurrentHash数组存放数组,默认为null,初始化默认为16 * table 存放要么是Node节点,表示链表元素,要么是TreeBin,表示红黑树 */ transient volatile Node<K,V>[] table; /** * 扩容时新生成的数组,其大小是原数组的两倍 */ private transient volat

贱男 853
上一篇: HTTP协议常见的状态码
下一篇: 浅谈Fork/Join框架
striveb
博客等级 码龄10年 242粉丝 117原创
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值