sizeCtl == -1 表示table正在初始化；sizeCtl

sizeCtl 为负数时，怎么区分「正在初始化」和「正在扩容」

关键看值的具体构成：sizeCtl == -1 表示 table 正在初始化；sizeCtl 才表示正在扩容。但不能直接用 <code>sizeCtl == -1 做唯一判断——因为扩容启动时第一线程会把 sizeCtl 设为 (rs ，而 <code>RESIZE_STAMP_SHIFT 是 16，所以这个值一定是远小于 -1 的负数（比如 -2147483646），绝不会是 -1。

常见误判点：有人看到 sizeCtl 就认为“一定在扩容”，结果在 initTable() 里漏掉对 <code>sizeCtl == -1 的单独处理，导致自旋逻辑出错。

• sizeCtl == -1：仅出现在 initTable() 中 CAS 成功后、table 还未赋值前的瞬时状态
• sizeCtl == (rs ：扩容开始，<code>rs 是 resize stamp，由 resizeStamp(n) 计算得出，确保不同容量扩容互不干扰
• sizeCtl == (rs （n ≥ 1）：已有 n 个线程加入扩容，每次 <code>helpTransfer() 或 transfer() 都会 CAS 自增 1

为什么扩容时 sizeCtl 要用位移加法而不是直接存线程数

因为要同时编码两个信息：扩容事件标识（stamp）和参与线程数。JDK 用高 16 位存 stamp，低 16 位存线程计数（+2 是起始偏移，避免和 -1 冲突）。这样 sizeCtl 一个 int 就能承载完整上下文。

如果只存线程数，就无法区分「同样是 -5，是 4 个线程在扩容容量为 16 的表，还是在扩容容量为 32 的表」——而 stamp 正是用来唯一标记某次扩容动作的。

• stamp 由 resizeStamp(int n) 生成，核心是 Integer.numberOfLeadingZeros(n) | (1 ，保证不同 <code>n 得到不同 stamp
• 低 16 位最大能记 65535 个线程，实际受限于 NCPU，几乎不可能溢出
• 直接用 AtomicInteger 存线程数看似简单，但丢失了扩容意图的语义，无法安全终止或校验迁移进度

transfer() 中 sizeCtl 减 1 的时机和风险点

每个线程完成自己负责的一段数据迁移后，都要执行一次 U.compareAndSwapInt(this, SIZECTL, sc, sc - 1)。但这里容易踩两个坑：

• 减之前没做 sc == (rs 的校验，可能把其他线程刚写入的 stamp 覆盖掉（CAS 失败是常态，必须循环重试）
• 减完发现 sizeCtl == (rs ，说明自己是最后一个线程，此时要检查是否全部迁移完毕（<code>nextTable == null 或 transferIndex ），再把 <code>table 指向新表、nextTable = null、sizeCtl = sc（即新阈值）
• 没有在 finally 块里执行减操作，一旦迁移中途抛异常，sizeCtl 永远卡在高位，后续所有 put 都会阻塞在 helpTransfer() 自旋里

initTable() 里 sizeCtl 从 -1 变成 0.75n 的那步为什么必须用 finally

因为初始化过程可能被中断（比如 OOM、线程被 kill），如果只在 try 块末尾赋值 sizeCtl = sc，一旦出错，sizeCtl 就永远卡在 -1，后续所有线程进 initTable() 都会 Thread.yield() 空转，CPU 拉满但无进展。

源码中 finally { sizeCtl = sc; } 是兜底保障：哪怕 new 数组成功但后续赋值失败，至少让 sizeCtl 恢复成正数，下一轮自旋就能跳过初始化逻辑，直接走 put 流程。

这个细节暴露了 ConcurrentHashMap 对「状态终态一致性」的强要求——它不依赖 JVM 安全点或 GC 回收来清理中间态，所有关键状态变更都靠 volatile + CAS + finally 三重保险。