JDK1.8 ConcurrentHashMap扩容函数注释

本文深入剖析了ConcurrentHashMap的扩容过程,详细解释了transfer方法如何实现节点的迁移和复制,以及如何确保多线程环境下的高效和安全性。通过源码分析,展示了扩容策略、冲突解决和线程同步机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转自:https://www.jianshu.com/p/2829fe36a8dd

/**
 * Moves and/or copies the nodes in each bin to new table. See
 * above for explanation.
 * 
 * transferIndex 表示转移时的下标,初始为扩容前的 length。
 * 
 * 我们假设长度是 32
 */
private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {
    int n = tab.length, stride;
    // 将 length / 8 然后除以 CPU核心数。如果得到的结果小于 16,那么就使用 16。
    // 这里的目的是让每个 CPU 处理的桶一样多,避免出现转移任务不均匀的现象,如果桶较少的话,默认一个 CPU(一个线程)处理 16 个桶
    if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
        stride = MIN_TRANSFER_STRIDE; // subdivide range 细分范围 stridea:TODO
    // 新的 table 尚未初始化
    if (nextTab == null) {            // initiating
        try {
            // 扩容  2 倍
            Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1];
            // 更新
            nextTab = nt;
        } catch (Throwable ex) {      // try to cope with OOME
            // 扩容失败, sizeCtl 使用 int 最大值。
            sizeCtl = Integer.MAX_VALUE;
            return;// 结束
        }
        // 更新成员变量
        nextTable = nextTab;
        // 更新转移下标,就是 老的 tab 的 length
        transferIndex = n;
    }
    // 新 tab 的 length
    int nextn = nextTab.length;
    // 创建一个 fwd 节点,用于占位。当别的线程发现这个槽位中是 fwd 类型的节点,则跳过这个节点。
    ForwardingNode<K,V> fwd = new ForwardingNode<K,V>(nextTab);
    // 首次推进为 true,如果等于 true,说明需要再次推进一个下标(i--),反之,如果是 false,那么就不能推进下标,需要将当前的下标处理完毕才能继续推进
    boolean advance = true;
    // 完成状态,如果是 true,就结束此方法。
    boolean finishing = false; // to ensure sweep before committing nextTab
    // 死循环,i 表示下标,bound 表示当前线程可以处理的当前桶区间最小下标
    for (int i = 0, bound = 0;;) {
        Node<K,V> f; int fh;
        // 如果当前线程可以向后推进;这个循环就是控制 i 递减。同时,每个线程都会进入这里取得自己需要转移的桶的区间
        while (advance) {
            int nextIndex, nextBound;
            // 对 i 减一,判断是否大于等于 bound (正常情况下,如果大于 bound 不成立,说明该线程上次领取的任务已经完成了。那么,需要在下面继续领取任务)
            // 如果对 i 减一大于等于 bound(还需要继续做任务),或者完成了,修改推进状态为 false,不能推进了。任务成功后修改推进状态为 true。
            // 通常,第一次进入循环,i-- 这个判断会无法通过,从而走下面的 nextIndex 赋值操作(获取最新的转移下标)。其余情况都是:如果可以推进,将 i 减一,然后修改成不可推进。如果 i 对应的桶处理成功了,改成可以推进。
            if (--i >= bound || finishing)
                advance = false;// 这里设置 false,是为了防止在没有成功处理一个桶的情况下却进行了推进
            // 这里的目的是:1. 当一个线程进入时,会选取最新的转移下标。2. 当一个线程处理完自己的区间时,如果还有剩余区间的没有别的线程处理。再次获取区间。
            else if ((nextIndex = transferIndex) <= 0) {
                // 如果小于等于0,说明没有区间了 ,i 改成 -1,推进状态变成 false,不再推进,表示,扩容结束了,当前线程可以退出了
                // 这个 -1 会在下面的 if 块里判断,从而进入完成状态判断
                i = -1;
                advance = false;// 这里设置 false,是为了防止在没有成功处理一个桶的情况下却进行了推进
            }// CAS 修改 transferIndex,即 length - 区间值,留下剩余的区间值供后面的线程使用
            else if (U.compareAndSwapInt
                     (this, TRANSFERINDEX, nextIndex,
                      nextBound = (nextIndex > stride ?
                                   nextIndex - stride : 0))) {
                bound = nextBound;// 这个值就是当前线程可以处理的最小当前区间最小下标
                i = nextIndex - 1; // 初次对i 赋值,这个就是当前线程可以处理的当前区间的最大下标
                advance = false; // 这里设置 false,是为了防止在没有成功处理一个桶的情况下却进行了推进,这样对导致漏掉某个桶。下面的 if (tabAt(tab, i) == f) 判断会出现这样的情况。
            }
        }// 如果 i 小于0 (不在 tab 下标内,按照上面的判断,领取最后一段区间的线程扩容结束)
        //  如果 i >= tab.length(不知道为什么这么判断)
        //  如果 i + tab.length >= nextTable.length  (不知道为什么这么判断)
        if (i < 0 || i >= n || i + n >= nextn) {
            int sc;
            if (finishing) { // 如果完成了扩容
                nextTable = null;// 删除成员变量
                table = nextTab;// 更新 table
                sizeCtl = (n << 1) - (n >>> 1); // 更新阈值
                return;// 结束方法。
            }// 如果没完成
            if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {// 尝试将 sc -1. 表示这个线程结束帮助扩容了,将 sc 的低 16 位减一。
                if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)// 如果 sc - 2 不等于标识符左移 16 位。如果他们相等了,说明没有线程在帮助他们扩容了。也就是说,扩容结束了。
                    return;// 不相等,说明没结束,当前线程结束方法。
                finishing = advance = true;// 如果相等,扩容结束了,更新 finising 变量
                i = n; // 再次循环检查一下整张表
            }
        }
        else if ((f = tabAt(tab, i)) == null) // 获取老 tab i 下标位置的变量,如果是 null,就使用 fwd 占位。
            advance = casTabAt(tab, i, null, fwd);// 如果成功写入 fwd 占位,再次推进一个下标
        else if ((fh = f.hash) == MOVED)// 如果不是 null 且 hash 值是 MOVED。
            advance = true; // already processed // 说明别的线程已经处理过了,再次推进一个下标
        else {// 到这里,说明这个位置有实际值了,且不是占位符。对这个节点上锁。为什么上锁,防止 putVal 的时候向链表插入数据
            synchronized (f) {
                // 判断 i 下标处的桶节点是否和 f 相同
                if (tabAt(tab, i) == f) {
                    Node<K,V> ln, hn;// low, height 高位桶,低位桶
                    // 如果 f 的 hash 值大于 0 。TreeBin 的 hash 是 -2
                    if (fh >= 0) {
                        // 对老长度进行与运算(第一个操作数的的第n位于第二个操作数的第n位如果都是1,那么结果的第n为也为1,否则为0)
                        // 由于 Map 的长度都是 2 的次方(000001000 这类的数字),那么取于 length 只有 2 种结果,一种是 0,一种是1
                        //  如果是结果是0 ,Doug Lea 将其放在低位,反之放在高位,目的是将链表重新 hash,放到对应的位置上,让新的取于算法能够击中他。
                        int runBit = fh & n;
                        Node<K,V> lastRun = f; // 尾节点,且和头节点的 hash 值取于不相等
                        // 遍历这个桶
                        for (Node<K,V> p = f.next; p != null; p = p.next) {
                            // 取于桶中每个节点的 hash 值
                            int b = p.hash & n;
                            // 如果节点的 hash 值和首节点的 hash 值取于结果不同
                            if (b != runBit) {
                                runBit = b; // 更新 runBit,用于下面判断 lastRun 该赋值给 ln 还是 hn。
                                lastRun = p; // 这个 lastRun 保证后面的节点与自己的取于值相同,避免后面没有必要的循环
                            }
                        }
                        if (runBit == 0) {// 如果最后更新的 runBit 是 0 ,设置低位节点
                            ln = lastRun;
                            hn = null;
                        }
                        else {
                            hn = lastRun; // 如果最后更新的 runBit 是 1, 设置高位节点
                            ln = null;
                        }// 再次循环,生成两个链表,lastRun 作为停止条件,这样就是避免无谓的循环(lastRun 后面都是相同的取于结果)
                        for (Node<K,V> p = f; p != lastRun; p = p.next) {
                            int ph = p.hash; K pk = p.key; V pv = p.val;
                            // 如果与运算结果是 0,那么就还在低位
                            if ((ph & n) == 0) // 如果是0 ,那么创建低位节点
                                ln = new Node<K,V>(ph, pk, pv, ln);
                            else // 1 则创建高位
                                hn = new Node<K,V>(ph, pk, pv, hn);
                        }
                        // 其实这里类似 hashMap 
                        // 设置低位链表放在新链表的 i
                        setTabAt(nextTab, i, ln);
                        // 设置高位链表,在原有长度上加 n
                        setTabAt(nextTab, i + n, hn);
                        // 将旧的链表设置成占位符
                        setTabAt(tab, i, fwd);
                        // 继续向后推进
                        advance = true;
                    }// 如果是红黑树
                    else if (f instanceof TreeBin) {
                        TreeBin<K,V> t = (TreeBin<K,V>)f;
                        TreeNode<K,V> lo = null, loTail = null;
                        TreeNode<K,V> hi = null, hiTail = null;
                        int lc = 0, hc = 0;
                        // 遍历
                        for (Node<K,V> e = t.first; e != null; e = e.next) {
                            int h = e.hash;
                            TreeNode<K,V> p = new TreeNode<K,V>
                                (h, e.key, e.val, null, null);
                            // 和链表相同的判断,与运算 == 0 的放在低位
                            if ((h & n) == 0) {
                                if ((p.prev = loTail) == null)
                                    lo = p;
                                else
                                    loTail.next = p;
                                loTail = p;
                                ++lc;
                            } // 不是 0 的放在高位
                            else {
                                if ((p.prev = hiTail) == null)
                                    hi = p;
                                else
                                    hiTail.next = p;
                                hiTail = p;
                                ++hc;
                            }
                        }
                        // 如果树的节点数小于等于 6,那么转成链表,反之,创建一个新的树
                        ln = (lc <= UNTREEIFY_THRESHOLD) ? untreeify(lo) :
                            (hc != 0) ? new TreeBin<K,V>(lo) : t;
                        hn = (hc <= UNTREEIFY_THRESHOLD) ? untreeify(hi) :
                            (lc != 0) ? new TreeBin<K,V>(hi) : t;
                        // 低位树
                        setTabAt(nextTab, i, ln);
                        // 高位数
                        setTabAt(nextTab, i + n, hn);
                        // 旧的设置成占位符
                        setTabAt(tab, i, fwd);
                        // 继续向后推进
                        advance = true;
                    }
                }
            }
        }
    }
}
<think>好的,用户想了解JDK1.7和JDK1.8ConcurrentHashMap扩容机制,并生成流程图进行对比分析。首先,我需要回忆这两个版本的不同实现。 JDK1.7的ConcurrentHashMap使用的是分段锁(Segment),每个Segment相当于一个小的HashMap,扩容时只针对单个Segment进行,这样可以减少锁的粒度。扩容的时候,需要重新计算所有元素的位置,并将它们转移到新的数组中。这个过程可能需要加锁,确保线程安全。而JDK1.8中,ConcurrentHashMap摒弃了分段锁,改用CAS和synchronized关键字来保证并发安全,数据结构也改成了数组+链表+红黑树的组合。扩容机制方面,1.8引入了多线程协助扩容的功能,当一个线程在扩容时,其他线程可以帮忙迁移数据,提高效率。 接下来,用户需要流程图对比。我需要分别画出1.7和1.8扩容流程。对于1.7,重点在于Segment的锁机制和单线程扩容;而1.8则需要体现多线程协助和树化处理。此外,两者的触发条件可能不同,比如负载因子和扩容阈值的计算方式是否有变化。 可能需要注意的点包括:1.7中每个Segment的扩容是独立的,而1.8中整个数组一起扩容。迁移数据时,1.8使用高低位链表拆分,可能更高效。另外,1.8在链表长度超过阈值时会转换为红黑树,这可能影响扩容时的处理方式。 用户还可能关心两者的性能差异,比如在高并发环境下,1.8的优化如何提升吞吐量。同时,需要确保流程图的正确性,比如步骤的顺序和条件判断是否正确。可能还需要解释关键概念,如CAS、synchronized在1.8中的具体应用,以及sizeCtl字段的作用。 最后,生成相关问题时要围绕扩容机制、并发处理、性能优化等方面,帮助用户深入理解两者的区别和设计思路。</think>### JDK 1.7 与 JDK 1.8 ConcurrentHashMap 扩容机制对比分析 --- #### **一、JDK 1.7 扩容机制** 1. **数据结构** - 使用 **分段锁(Segment)** 结构,每个 Segment 是独立的哈希表,包含一个 `HashEntry` 数组[^1]。 - 扩容单位为 **单个 Segment**,锁粒度较粗。 2. **触发条件** - 当 Segment 内的 `HashEntry` 数量超过阈值(容量 × 负载因子)时触发扩容。 3. **扩容流程** ```mermaid graph TD A[开始扩容] --> B[创建新数组(原容量×2)] B --> C[遍历旧数组节点] C --> D{是否需迁移?} D -->|是| E[计算新位置并插入新数组] D -->|否| F[保留旧数组位置] E --> G[更新Segment的数组引用] G --> H[完成扩容] ``` 4. **特点** - 单线程执行扩容,其他线程访问需阻塞等待[^2]。 - 迁移时通过 `rehash()` 重新计算哈希值。 --- #### **二、JDK 1.8 扩容机制** 1. **数据结构** - 使用 **数组+链表+红黑树**,锁粒度细化到单个桶(`synchronized` 关键字)[^3]。 - 引入 `ForwardingNode` 标记迁移状态。 2. **触发条件** - 总元素数超过 `sizeCtl` 阈值时触发全局扩容。 - 链表长度 ≥8 时树化,≤6 时退化为链表。 3. **扩容流程** ```mermaid graph TD A[开始扩容] --> B[计算步长,分配迁移区间] B --> C{是否多线程协助?} C -->|是| D[多个线程并行迁移数据] C -->|否| E[当前线程独立迁移] D/E --> F[迁移完成桶标记为ForwardingNode] F --> G{所有桶迁移完成?} G -->|否| B G -->|是| H[更新table为新数组] H --> I[完成扩容] ``` 4. **特点** - **多线程协作迁移**:通过 `transferIndex` 分配迁移任务区间[^4]。 - **高低位拆分**:利用哈希值的高位差快速定位新位置。 - **无锁化查询**:通过 `ForwardingNode` 允许读操作并行。 --- #### **三、关键差异对比** | **维度** | JDK 1.7 | JDK 1.8 | |-------------------|----------------------------------|----------------------------------| | **锁粒度** | Segment 级别(粗粒度) | 桶级别(细粒度) | | **扩容执行者** | 单线程 | 多线程协作 | | **迁移效率** | 全量 `rehash`,效率较低 | 高低位拆分,无重复计算 | | **并发性能** | 写竞争高 | CAS + synchronized 优化竞争 | | **数据结构** | 数组+链表 | 数组+链表+红黑树 | --- #### **四、流程图对比** 1. **JDK 1.7 扩容流程** ![JDK1.7-ConcurrentHashMap扩容流程图](https://via.placeholder.com/400x200?text=JDK1.7+扩容流程图示例) 2. **JDK 1.8 扩容流程** ![JDK1.8-ConcurrentHashMap扩容流程图](https://via.placeholder.com/400x250?text=JDK1.8+扩容流程图示例) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值