LongAdder类：高并发计数器性能优化详解

LongAdder并非靠“更强原子性”取胜，而是通过分段计数（base + 动态扩容的cells数组）巧妙规避多线程对同一内存地址的激烈争抢，结合@Contended防伪共享显著提升高并发下的吞吐量；它专为写多读少、允许最终一致的统计场景（如QPS监控、埋点计数）而生，却不适用于需瞬时强一致的业务逻辑（如库存扣减或状态判断），理解其设计契约——尤其是sum()的估算本质、懒加载机制和缺失CAS语义——才是正确落地的关键。

LongAdder 为什么比 AtomicLong 快？不是“更原子”，而是“少争抢”

它快，是因为根本没让所有线程去抢同一个内存地址。AtomicLong 的 incrementAndGet() 底层死磕一个 value 字段，10 个线程一起调，9 个大概率 CAS 失败、立刻自旋重试——CPU 白转，缓存行反复失效，吞吐量反而暴跌。

LongAdder 换了思路：用一个 base 值 + 一组独立的 Cell（数组），每个线程通过哈希尽量固定写入某个 Cell。Thread-1 写 cells[2]，Thread-2 写 cells[5]，互不干扰。最后 sum() 时才把它们加起来。

• 低并发时只用 base，零额外开销
• 竞争加剧时自动扩容 cells 数组（2 的幂次），直到冲突缓解
• JDK 8+ 中 Cell 类加了 @Contended，防伪共享——这点常被忽略，但直接影响多核性能

什么时候该用 LongAdder？别在错误场景硬套

它专为「写多读少、允许最终一致」的统计类场景设计，比如 QPS 计数、请求总量、耗时累加器。不是所有“要加数字”的地方都适合它。

• ✅ 适合：LongAdder 用于埋点上报、监控指标聚合、批处理任务计数
• ❌ 不适合：需要瞬时强一致读写的逻辑，比如信号量实现、库存扣减、状态机跳转判断
• ⚠️ 警惕：sum() 不是快照——调用瞬间可能有线程刚写进本地 Cell 还没参与合并，结果略低于真实值（通常差几个数量级）
• ⚠️ 切勿用 toString() 取值，它内部调的是 sum()，纯属多套一层，无收益

sum() 和 longValue() 有区别吗？怎么取值才安全

没有本质区别。longValue() 就是 sum() 的包装，二者行为完全一致。关键不在函数名，而在你对“一致性”的预期是否合理。

• sum() 遍历所有 cells 并加上 base，开销随 cell 数量线性增长，但高并发下这点开销远小于 AtomicLong 的自旋成本
• 如果业务要求“某次 increment 后立刻能被读到”，sum() 满足不了——这不是 bug，是设计契约
• 真需要强一致读写，回退到 AtomicLong 或加锁；想兼顾性能又需近似实时，可考虑定期调用 sum() + 缓存，但别指望它替代 CAS 语义

初始化和线程数多少才触发分段？别猜，看实际表现

LongAdder 是懒加载的：初始只有 base，第一个发生竞争的线程才会创建首个 Cell；后续竞争持续存在，才逐步扩容。所以“启动就配 16 个 cell”毫无意义，JVM 会按需分配。

• 单线程或极低并发下，LongAdder 和 AtomicLong 性能几乎一样，甚至略慢一点（因多一层分支判断）
• 实测拐点通常在 4–8 线程并发递增时出现；超过 16 线程后，AtomicLong 吞吐量可能跌到单线程的 1/3，而 LongAdder 仍接近线性增长
• 别依赖线程 ID 做哈希映射（如 id % N），LongAdder 用的是 Thread.probe，更均匀且避免哈希冲突集中

最常被绕过的点：它不提供 compareAndSet()，也没有 getAndIncrement() 这类带返回值的原子操作。如果你代码里写着 if (counter.sum() > 100) fireAlert();，那这个告警阈值本身就是模糊的——它只是某一时刻尽力而为的估算值。

终于介绍完啦！小伙伴们，这篇关于《LongAdder类：高并发计数器性能优化详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！