LongAdder Cell 动态扩容提升计数器性能

LongAdder通过动态扩容cells数组来应对高并发计数场景，其扩容并非按写入次数触发，而是由线程在Cell上CAS失败且满足“数组未满（≤CPU核数）、未被占用、引用未变更”等条件时启动，采用2的幂次增长并加锁保障线程安全；但实际使用中需警惕三大隐形性能陷阱：线程频繁创建销毁、sum()被高频调用导致遍历开销激增，以及base值在扩容期间可能引发的少量重复计数——这些细节决定了LongAdder是否真正适配你的业务场景，尤其在强一致性要求（如精准限流）下，它反而可能成为性能与正确性的双刃剑。

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 ... < NCPU：正在逐步扩容，竞争温和
• cells.length == NCPU 且 sum() >> base：多 Cell 已充分参与，吞吐压榨到位

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

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

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

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。