LongAdder优化高并发计数详解

LongAdder是Java中专为高并发写密集场景优化的计数器，通过分段计数（Cell数组）显著降低CAS争用，相比AtomicLong在32线程压测下吞吐提升近5倍，特别适合QPS统计等“写多读少”场景；但其sum()方法仅提供尽力而为的近似和，不保证强一致性，无法满足实时精确值需求——理解这一关键边界，才能避免监控漏数、重复等线上隐患。

为什么不用AtomicLong而选LongAdder

在高并发写场景下，AtomicLong.incrementAndGet() 会因大量线程争抢同一个CAS变量导致严重自旋，吞吐量急剧下降。而 LongAdder 采用“分段计数 + 最终汇总”策略，把竞争分散到多个内部单元（Cell[]）上，写操作几乎不冲突。

它适合「写多读少」的计数场景（如QPS统计、请求计数器），但不适合需要严格实时一致性的场合——因为 sum() 不是原子快照，中间可能有未合并的增量。

如何正确初始化和使用LongAdder

直接构造即可，无需额外配置：

LongAdder counter = new LongAdder();

常用操作只有三个，语义清晰：

• counter.increment()：+1，最常用
• counter.add(10)：加任意long值
• counter.sum()：获取当前总和（非强一致性）

注意：counter.longValue() 和 sum() 行为一致；不要用 toString() 做数值判断，它调用的是 sum() 后再转字符串，无额外收益。

sum() 的性能与一致性代价

sum() 需遍历所有 Cell 并加上 base 值，当并发写入频繁时，Cell[] 可能动态扩容，遍历开销略增；但相比 AtomicLong 在高争用下的退化，这点开销几乎可忽略。

关键限制：

• 它不保证调用 sum() 时已合并所有待写值（例如某个线程刚写进本地 Cell 还没参与 Striped64 的竞争合并逻辑）
• 不能替代 compareAndSet() 类操作——LongAdder 根本没有提供 CAS 接口
• 如果业务依赖“精确到某次调用的瞬时值”，必须换回 AtomicLong 或加锁

和AtomicLong的实测差异在哪

在 32 线程、持续 increment 的压测中（JDK 17，Linux x86_64）：

• AtomicLong 吞吐约 8~12M ops/sec，随线程数增加快速饱和
• LongAdder 吞吐可达 40~60M ops/sec，扩展性明显更好

但若混入大量 sum() 调用（比如每 10 次 increment 就 sum 一次），LongAdder 优势会收窄——因为 sum() 是唯一需要全局遍历的操作，别把它当成廉价读。

真正要警惕的不是语法或初始化，而是误以为 sum() 是“强一致读”：它只是尽力而为的近似和，这个边界一旦模糊，监控指标就可能漏数或重复。

理论要掌握，实操不能落！以上关于《LongAdder优化高并发计数详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！