counterCells数组在首次CAS竞争失败时初始化为长度2，后续按需翻倍扩容（2→4→8…），上限为CPU核心数，由写冲突频次和空槽位缺失共同触发，而非固定阈值驱动。
counterCells 数组什么时候会扩容
它不会像 table 那样按固定阈值自动扩容，而是「按需懒扩容」：只有当前线程尝试更新 baseCount 失败（CAS 竞争失败），且 counterCells 为 null 或当前线程探针（ThreadLocalRandom.getProbe()）映射的槽位为 null 时，才会触发初始化或扩容逻辑。
关键判断在 fullAddCount 方法中：cellsBusy == 0 && cells == cs（即无锁且数组未被其他线程修改），才允许 CAS 设置 cellsBusy = 1 进入扩容/初始化流程。
-
counterCells初始为null，首次竞争失败后初始化为长度 2 的数组 - 后续扩容是「翻倍」：2 → 4 → 8 → 16… 最大不超过 CPU 核心数（
NCPU），因为再多线程也难同时写不同槽位 - 扩容不是由元素总数驱动，而是由「写冲突频次」和「空槽位缺失」共同触发
为什么扩容代价比 table 扩容更隐蔽但更值得警惕
table 扩容是显式、集中、可监控的（比如日志打点、JFR 事件），而 counterCells 扩容发生在 addCount 内部，不抛异常、不打日志、不阻塞主线程，但每次扩容都意味着：
- 要分配新数组并逐个拷贝非空
CounterCell（虽然通常只拷贝几个有效值） - 要重置所有线程的探针映射关系（旧槽位失效，新线程可能又撞到同一槽）
- 扩容期间
cellsBusy被设为 1，其他线程写计数会短暂退回到低效的baseCount重试路径 - 如果并发写压力持续，可能陷入「扩容 → 槽位仍不够 → 再扩容」的抖动循环
这种抖动不会让程序崩溃，但会让 put 的平均耗时上浮 5%~20%，尤其在 QPS 突增、线程数远超 CPU 核数的场景下明显。
如何观测 counterCells 是否在高频扩容
没有公开 API 直接暴露扩容次数，但可通过反射或 JMX 获取关键字段观察行为模式：
- 定期读取
counterCells.length：若从 2 → 4 → 8 变化频繁（如 1 秒内多次），说明计数热点严重 - 检查
cellsBusy是否长期为 1：表示扩容/初始化卡住（罕见，但可能因死锁或 GC STW 导致） - 对比
baseCount增量与实际size()差值：差值越大，说明越多计数落在counterCells，且其分布越稀疏（意味着槽位利用率低）
注意：size() 本身是遍历累加，结果只是快照；真正反映计数压力的是 addCount 中进入 fullAddCount 分支的频率 —— 这需要字节码插桩或 Async-Profiler 抓取热点方法调用栈。
容易被忽略的两个底层细节
一是 @sun.misc.Contended 注解：每个 CounterCell 都被缓存行填充，避免伪共享（false sharing）。如果 JVM 启动没加 -XX:-RestrictContended，这个优化就失效，多个线程写相邻 CounterCell 会互相踢出缓存行，反而放大性能损耗。
二是探针（probe）的生成逻辑：它基于线程本地的随机种子计算，但**不会随 counterCells 扩容自动重哈希**。扩容后，原 probe % oldLength 映射的槽位内容被复制到新数组对应位置，但新线程的 probe 仍按新长度取模 —— 这导致扩容后初期槽位分布不均，部分新槽长期为空，而旧热槽仍拥挤。
