concurrenthashmap在jdk 1.8中通过helptransfer实现多线程协助扩容：当put发现forwardingnode（hash=-1）时，线程主动参与迁移，基于transferindex原子抢段、分桶加锁、rehash到新表，避免重复迁移且保障线程安全。
为什么需要 helpTransfer？
ConcurrentHashMap 的扩容不是由单一线程独占完成的，而是允许多个线程并发参与迁移。这样能加快扩容速度、减少单线程阻塞时间，也避免写操作长时间等待。`helpTransfer` 就是让“路过”的 `put` 线程临时变成“搬运工”，分担一部分迁移任务。
helpTransfer 怎么知道该搬哪部分？
它不盲目全量迁移，而是基于当前线程看到的 `ForwardingNode` 和全局状态协同推进：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- `ForwardingNode` 本身不存数据，只保存对 `nextTable` 的引用和一个 `sizeCtl` 相关的扩容进度标识；
- 真正决定“搬哪段”的是 `transferIndex` —— 这是一个原子整数，记录**下一个待分配的迁移区间起始下标**（从旧表末尾向前划分）；
- 线程通过 `cas` 尝试递减 `transferIndex`，成功抢到一个区间（如 `[i, i-1]` 或 `[i, i-32)`）后，就负责把旧表中对应桶位的数据逐个 rehash 搬到新表；
- 每个桶的迁移逻辑与 `transfer` 主方法一致：遍历链表/红黑树，按 `(hash & (n-1))` 和 `(hash & n)` 判断归属新表的低位（`lo`) 或高位（`hi`）桶，分别构建两个子链/子树，再一次性 CAS 设置到新表对应位置。
协助过程是否安全？如何避免重复迁移？
安全靠三重保障：
- 桶级锁：迁移前先对旧表中目标桶加锁（`synchronized(f)`），确保同一桶不会被多个线程同时处理；
- 节点标记：迁移完成后，原桶被设为 `ForwardingNode`，后续线程看到它会继续调 `helpTransfer` 或直接跳转到新表查找；
- 幂等设计：`ForwardingNode` 的 `find` 方法会直接在 `nextTable` 上查找，即使迁移未完成，读操作也不阻塞；而写操作遇到已迁移桶，会直接写入新表对应位置，不会重复写旧表。
当前线程什么时候停止协助？
不是无限制帮下去：
- 一旦发现 `nextTable == null` 或 `transferIndex
- 如果自己抢到的迁移区间已空（如对应桶为 `null`），就继续尝试获取下一个区间；
- 若协助过程中发现 `sizeCtl` 变成正数（表示扩容已结束），也会立即返回；
- 协助只是“尽力而为”，不保证完成全部，主扩容线程（触发扩容的那个线程）仍会兜底收尾。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
