登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  java教程

Java LongAdder 计数高并发时为什么比 AtomicLong 更适合

来源:17golang原创

时间:2026-09-09 03:06:37 243浏览 收藏

Java 里把多个线程的事件累加到一个总数时,LongAdder 通常比 AtomicLong 更适合“统计计数”场景。原因不是它让每次读取都更精确,而是高竞争更新时可以分散维护计数,再在读取时汇总。若这个数字本身是序列号、库存、额度或状态机的一部分,仍应优先保留 AtomicLong 的原子读改写语义。

一句话选择:只关心吞吐较高的累计统计,用 LongAdder;需要精确的原子当前值、比较并交换或每次更新的返回值,用 AtomicLong。不要把 LongAdder.sum() 当作并发期间的原子快照。
要点速览
  • 高竞争公共计数是 LongAdder 的主要用武之地,代价是更多空间和非原子快照读取。
  • AtomicLong 适合序列号、额度和需要精确读改写的状态,不只是“速度较慢的计数器”。
  • 迁移前先核对读取、重置和返回值语义,再做同负载压测,不要只替换类名。

先看升级范围:统计数字还是业务状态

两者都能表达一个不断增加的 long,但业务契约不同。Oracle 的 API 文档明确建议:多个线程更新同一个、主要用于收集统计信息的总数时,LongAdder 通常更合适;低竞争时二者特征接近,高竞争时 LongAdder 预期吞吐更高,但会消耗更多空间。

问题更适合 LongAdder更适合 AtomicLong
数字用途请求数、命中数、事件频次序列号、额度、状态版本
读取要求允许读取时有并发更新偏差需要原子读取当前值
更新要求主要是 increment/add需要 compareAndSet、addAndGet 等读改写
主要代价内部计数占用更多空间高竞争时共享更新位置更容易成为热点

为什么高竞争计数会让 AtomicLong 变成共享热点

AtomicLong.incrementAndGet() 适合需要返回更新后值的场景,但所有线程都围绕同一个原子值更新。当写入远多于读取,线程会频繁争用这个共享位置。LongAdder 则允许内部维护多个计数位置,更新时尽量分散,调用 sum() 时再把它们合并。因此它换来的是更新吞吐,而不是每一次读取都获得一个锁定时刻的快照。

Java 高竞争计数中 AtomicLong 单一共享位置与 LongAdder 分散内部计数后汇总的结构对比
图1:AtomicLong 的单一共享计数位置与 LongAdder 分散维护内部计数位置的结构对比。

旧代码如果依赖“更新后立刻拿到唯一值”,不能仅因为压力变大就直接换成 LongAdder。例如发号器必须知道本次拿到的序列号,扣减额度也常常要根据成功与否继续执行业务,这些都不是普通统计计数。

迁移到 LongAdder 的最小写法

对于只记录次数的代码,迁移通常只涉及字段类型和读取方法。下面的示例把请求完成数作为统计指标,不把读取结果用于并发控制:

import java.util.concurrent.atomic.LongAdder;

public final class RequestMetrics {
    private final LongAdder completed = new LongAdder();

    public void recordCompleted() {
        // 统计事件次数,不依赖本次更新后的唯一序号。
        completed.increment();
    }

    public long completedCount() {
        // 读取当前汇总值;并发更新期间不承诺原子快照。
        return completed.sum();
    }
}

如果一次要增加多个数量,使用 add(delta);如果要做减一,则使用 decrement()。当每个 key 都需要一个频次计数时,官方文档给出的组合方式是 ConcurrentHashMap.computeIfAbsent(key, k -> new LongAdder()).increment()。这里的 key 初始化是并发安全的,但频次读取仍应接受统计语义。

private final ConcurrentHashMap frequencies = new ConcurrentHashMap();

public void record(String name) {
    // 每个名称独立累加,避免用普通 Long 做先读后写。
    frequencies.computeIfAbsent(name, key -> new LongAdder()).increment();
}

迁移前要检查的读取与重置边界

sum() 返回的是当前合计,但官方契约特别说明:并发更新在计算过程中发生时,结果可能没有包含全部更新。因此它适合监控面板、周期统计和趋势数据,不适合拿来判断“余额是否足够后再扣减”。reset() 也只有在确定没有线程更新时才安全;sumThenReset() 同样不能保证并发更新时拿到重置前的最终值。

Java LongAdder 统计读取与 AtomicLong 精确状态之间的 sum 非原子快照和 reset 边界
图2:选择 LongAdder 前需要核对的精确状态、统计读取和 reset 并发前提。

可以按下面清单做一次回归:

  • 业务是否只需要累计结果,而不需要本次更新后的返回值?
  • 读取期间允许少量并发更新尚未反映在本次结果中吗?
  • 是否真的存在高写入竞争,额外空间是否值得?
  • 调用 resetsumThenReset 时,能否建立无并发更新的时间点?

相关问题

LongAdder 能完全替代 AtomicLong 吗?

不能。它面向可伸缩的统计累加,不提供 AtomicLong 那组精确读改写语义。

低并发时还要换成 LongAdder 吗?

不一定。低竞争下二者特征接近,优先按读取语义和代码可读性选择。

LongAdder 的 sum 是线程安全的吗?

调用本身可以并发执行,但返回值不是并发更新期间的原子快照;这两个概念要分开。

参考文档

Java SE 25 LongAdder APIJava SE 25 AtomicLong API

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>