怎么利用 LongAdder 的 Cell 自动动态扩容机制在高核 CPU 环境下压榨计数器吞吐量上限-java教程-PHP中文网

LongAdder的cells数组扩容触发条件是：当前数组长度小于CPU核数且在Cell上CAS失败；此时先CAS设置cellsBusy为1加锁，再将数组扩容为原长2倍，并复制原有数据。

怎么利用 longadder 的 cell 自动动态扩容机制在高核 cpu 环境下压榨计数器吞吐量上限

LongAdder 的 cells 数组扩容触发条件是什么

扩容不是按写入次数，而是由线程竞争失败次数驱动的。当某个线程在尝试更新当前 Cell 时 CAS 失败（说明该 Cell 正被其他线程高频修改），且当前 cells 数组未满（长度 NCPU）、数组未被其他线程正在扩容、且 cells 引用未变更，就会触发扩容。

关键点：

NCPU 是 JVM 启动时读取的 Runtime.getRuntime().availableProcessors() 值，不可运行时修改
扩容是 2 的幂次增长（newCell[n ），初始为 2，最大到 NCPU
扩容本身不阻塞写操作：失败线程会 fallback 到 base 或重试其他 Cell，不会卡死

为什么高核 CPU 下 LongAdder 吞吐量能接近线性提升

核心在于 cells 数组长度上限与 CPU 核心数对齐，让每个物理核心（或超线程）大概率映射到独立 Cell，从而消除缓存行争用。

实操中要注意：

如果 NCPU = 64（如 AMD EPYC），cells 最多扩容到 64 个，但实际活跃 Cell 数取决于线程 probe 哈希分布，未必填满
线程数远超 NCPU（比如 200 个计数线程）时，probe 哈希冲突概率上升，部分 Cell 仍会成为热点
启用 -XX:+UseContended（JDK 8u60+ 默认开启）才能让 @Contended 注解生效，避免 Cell 数组内伪共享

如何确认你的 LongAdder 正在有效利用多 Cell

不能只看 sum() 结果，要观测内部状态。调用 cells.length 和 longValue() 对比可判断是否已走出单 base 阶段：

LongAdder adder = new LongAdder();
// …… 高并发写入后
System.out.println("cells length: " + getCellsLength(adder)); // 需反射或 JOL 工具
System.out.println("sum: " + adder.sum());

更实用的方式是用 JFR（Java Flight Recorder）抓取 jdk.LongAdderUpdate 事件，或通过 Unsafe 反射读取 cells 字段（仅限调试）：

cells == null：纯 base 模式，低并发或初始化阶段
cells.length == 2 || 4 || 8 ... ：正在逐步扩容，竞争温和
cells.length == NCPU 且 sum() >> base：多 Cell 已充分参与，吞吐压榨到位

容易被忽略的三个性能断点

即便开了 64 核，LongAdder 也可能卡在非预期环节：

线程创建/销毁开销远大于计数本身 —— 改用固定大小线程池，避免每请求 new Thread
频繁调用 sum()（尤其在循环里）会遍历整个 cells 数组，且每次都要 volatile 读 —— 若只需最终值，攒一批再读；若需监控，改用异步采样
base 值在扩容期间可能被多个线程同时更新（因为 fallback 路径未加锁），导致少量重复计数 —— 这属于设计允许的误差，但若业务强依赖精确中间态（如限流阈值判断），就不能用 LongAdder，得切回 AtomicLong 或加额外同步