LongAdder数据分散存储原理与优化方法

LongAdder 并非“万能加速器”，其真正优势在于通过分段计数（base + cells数组）将单点竞争拆解为多槽位并发更新，结合@Contended缓存行隔离显著缓解高并发下的CAS自旋风暴，但仅在写多读少、允许最终一致性且JVM正确启用缓存行填充的场景下才能发挥实效；盲目替换AtomicLong不仅无法提升性能，反而可能因sum()非原子性、内存膨胀、伪共享失效或返回值语义缺失引发线上毛刺、吞吐下降甚至性能反降，理解其设计边界与硬约束才是落地关键。

直接换 LongAdder 并不能自动解决性能退化——它只在写多读少、允许最终一致性的场景下才真正起效；盲目替换反而可能引入精度丢失、内存膨胀或伪共享失效等新问题。

为什么 AtomicLong 在高竞争下会卡死在 CAS 自旋

AtomicLong 所有线程都抢同一个 value 字段，底层调用的是 unsafe.getAndAddLong(this, valueOffset, 1L)。一旦线程数超过 CPU 核心数，CAS 失败率指数上升，线程只能空转重试，CPU 占用拉满但吞吐几乎不涨。

常见错误现象包括：

• 监控看到 CPU usage 飙升，但 QPS 不升反降
• 线程 dump 出现大量 Unsafe.park 或自旋循环栈帧（如 AtomicLong.incrementAndGet 内部循环）
• GC 日志正常，但 RT 毛刺剧烈且不可预测

LongAdder 的 cells[] 是怎么分散热点的

它用「base + cells[]」双层结构替代单点变量：

• 低并发时：所有操作走 base，开销和 AtomicLong 几乎一致
• 首次 CAS 失败后：触发 cells 初始化，默认长度为 2
• 后续线程通过 ThreadLocalRandom.getProbe() 计算哈希，再用位运算 hash & (cells.length - 1) 映射到某个 Cell 槽位，只更新自己那一格
• 某个 Cell 持续冲突时，会尝试 rehash 到其他槽位，而非死等

这相当于把“一个收银台排队”变成“多个窗口分流”，本质是用空间换并发吞吐。

必须注意的三个硬约束条件

不是所有计数场景都适合 LongAdder：

• 写远大于读：比如请求计数、QPS 统计、限流桶填充；如果每写一次就要 sum() 一次做 if 判断，就违背设计初衷
• 不要求强一致性：sum() 是遍历累加，过程中其他线程可能正在改某个 Cell，结果只是最终一致，不是原子快照
• 运行环境支持 @Contended：JVM 必须开启 -XX:-RestrictContended（JDK8u20+ 默认开启），否则 Cell 类的缓存行填充失效，多核下伪共享反而更严重

容易踩的坑：

• 在循环里反复调用 sum() 做条件分支，导致逻辑错乱
• 替换了已有 AtomicLong，但业务依赖 incrementAndGet() 的返回值（LongAdder 没有该方法）
• 在小内存容器（如 512MB JVM）中大量创建 LongAdder 实例，每个 Cell 至少占 128 字节，16 槽就是 ~2KB

伪共享不是理论问题，而是上线即爆的性能雷区

Cell 数组里相邻元素若落在同一缓存行（64 字节），一个线程写 cells[0].value，会导致另一个线程的 cells[1].value 所在缓存行失效，强制回写——这就是伪共享。而 @Contended 就是用来让每个 Cell 独占一整行的。

但在以下情况它会失效：

• JVM 启动没加 -XX:+UseContended（旧 JDK 版本需显式开启）
• 用了 GraalVM 或某些裁剪版 JRE，@Contended 被忽略
• 自己手写了类似 Cell 的结构但没加注解，误以为“分段”就够了

实测表明：在 32 核机器上，未正确启用 @Contended 的 LongAdder，性能可能比单个 AtomicLong 还差。

到这里，我们也就讲完了《LongAdder数据分散存储原理与优化方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！