ConcurrentHashMapTransferIndex作用与扩容解析

本文深入解析了 ConcurrentHashMap 中关键的并发扩容机制核心——TransferIndex 变量，揭示其作为 volatile 整型如何通过 CAS 原子递减实现多线程间无锁、互斥、动态的任务分片：每个线程从 transferIndex 向前领取固定步长（stride）的桶区间（如 [nextBound, nextIndex)），既彻底避免重复迁移与遗漏风险，又支持线程动态加入与扩容过程随时中断恢复；它与 sizeCtl 紧密协同——前者管“干哪块”，后者管“谁在干”，共同构建出高效、可扩展、可感知进度的协作式扩容模型，是理解 ConcurrentHashMap 高并发设计精髓不可绕过的关键一环。

TransferIndex 是什么，它在扩容中起什么作用

transferIndex 是一个 volatile int 变量，用于记录当前尚未分配给任何线程的、待迁移桶位的起始索引。它不是“当前正在迁移的下标”，而是“下一个可被抢走的任务边界”。每次有线程成功争到一批迁移任务，就会用 CAS 原子地将 transferIndex 减去该批大小（stride），从而为其他线程划出新的工作区间。

它的核心价值在于：避免多线程重复处理同一段桶，也不需要加锁同步任务分配。只要每个线程都从 transferIndex 向前取 stride 个桶，就能天然形成互斥的迁移区域。

为什么不能直接用 for 循环遍历整个旧数组

如果所有线程都从头开始遍历 tab.length，会出现严重问题：

• 多个线程反复尝试迁移同一个桶（比如桶 0），造成 CAS 失败、自旋浪费
• 无法感知“谁已处理完哪一段”，导致部分桶被遗漏或重复迁移
• 无法动态适应线程数变化——新加入的线程不知道该从哪继续

transferIndex 配合 stride（每线程处理步长）和 sizeCtl（记录参与线程数），让扩容变成一个“按需领取、边界清晰、可中断可续”的协作过程。

TransferIndex 如何与 sizeCtl 协同控制扩容状态

sizeCtl 和 transferIndex 是一对搭档：sizeCtl 管“谁在干”，transferIndex 管“干哪块”。

常见组合含义：

• 当 sizeCtl == -(1 + N)：表示有 N 个线程正在扩容，此时 transferIndex > 0 才有意义
• 当 transferIndex ：说明所有桶都已被划出任务区间，后续线程进来会检测到“无任务可领”，转而协助其他线程或检查是否完成
• 主线程初始化新表后，会先设置 sizeCtl = -(1 + NCPU)，再设初始 transferIndex = oldTab.length，然后才启动迁移

容易忽略的关键细节：transferIndex 的递减方向与迁移方向相反

这是最常被误解的一点：transferIndex 是从高索引向低索引递减的，而实际迁移是从高桶往低桶进行（即从 transferIndex - stride 到 transferIndex - 1）。源码中类似：

int nextIndex = transferIndex;  
int nextBound = (nextIndex > stride) ? nextIndex - stride : 0;  
if (U.compareAndSwapInt(this, TRANSFERINDEX, nextIndex, nextBound)) {  
    // 成功抢到 [nextBound, nextIndex) 这段桶  
}

也就是说，线程拿到的是一个闭区间 [nextBound, nextIndex)，迁移顺序是倒着扫的。这种设计能保证最后几个桶（索引小）留给最后抢到任务的线程处理，也便于主线程通过检查 transferIndex == 0 快速判断是否全部分发完毕。

终于介绍完啦！小伙伴们，这篇关于《ConcurrentHashMapTransferIndex作用与扩容解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！