TransferIndex 是 volatile int 变量，用于记录待迁移桶的起始索引，线程通过 CAS 原子递减它来领取互斥的迁移区间（如 [nextBound, nextIndex)），避免重复或遗漏迁移，与 sizeCtl 协同实现无锁、可扩展、可中断的并发扩容。
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 快速判断是否全部分发完毕。
