LongAdder替代AtomicLong，Java8性能优化攻略

Java 8 引入的 LongAdder 通过分段计数（cell 分片）巧妙分散高并发写操作的竞争压力，显著缓解了 AtomicLong 在多线程频繁更新时因单点 CAS 自旋导致的性能瓶颈和 CPU 浪费；它在监控计数、请求统计、限流器等弱一致性场景中吞吐更高、延时更稳，但不适用于要求严格顺序与强一致读取的序列号生成等关键逻辑——读懂它的适用边界，往往就是突破系统性能瓶颈的关键一步。

LongAdder 比 AtomicLong 快在哪？

不是“一定快”，而是在高并发、多线程频繁更新的场景下，LongAdder 通过分段计数（cell 分片）把竞争从一个变量压到多个变量上，避免了 AtomicLong 单点 CAS 自旋带来的大量失败重试。简单说：写得多、读得少时，LongAdder 明显占优；但如果你只是偶尔 increment，甚至单线程用，AtomicLong 反而更轻量。

常见错误现象：AtomicLong.get() 很快，但压测时吞吐卡在几千 QPS 上不去，CPU 跑满却没干多少事——大概率是 CAS 争抢导致的自旋风暴。

• 适用场景：监控计数器、请求总量、滑动窗口统计、限流器中的 token 消耗量
• 不适用场景：需要强一致读的场合（比如作为序列号生成器，要求每次 incrementAndGet() 返回严格递增且无跳变）
• LongAdder 的 sum() 是最终一致性读，期间可能有微小延迟（但通常 AtomicLong 的原子读-改-写语义

怎么安全地替换 AtomicLong 为 LongAdder？

不能直接把 AtomicLong 声明换成 LongAdder 就完事——它们 API 不兼容。最常踩的坑是误用 get() 方法：后者不存在，必须调用 sum() 或 longValue()。

实操建议：

• 写操作统一用 increment() / add(long x)，和 AtomicLong.incrementAndGet() 行为类似，但不返回值
• 读操作必须改用 sum()（推荐）或 longValue()，注意它不保证实时性，也不加锁
• 如果旧逻辑依赖 compareAndSet(old, new) 这类原子条件更新，LongAdder 不支持——别硬换，保留 AtomicLong 或改用 Striped64 子类定制
• 初始化别用 new LongAdder() 后立刻 sum()：首次调用前值恒为 0，但内部 cell 数组是懒加载的，不影响正确性

sum() 和 sumThenReset() 的性能与语义差异

sum() 是只读聚合，遍历所有 cell 累加，开销随并发线程数增长（但仍是 O(线程数)，远好于 CAS 自旋）；sumThenReset() 则会清零所有 cell，适合做周期性指标采集（如每秒请求数），避免手动 reset 引发竞态。

容易忽略的细节：

• sumThenReset() 不是原子快照：它一边累加一边清零，结果可能略小于真实累计值（尤其在高写入速率下），但误差可控（一般差几个量级以内）
• 不要在循环里高频调用 sum()——比如在日志中每毫秒打一次值，这会放大遍历开销；应降频或缓存结果
• 如果业务允许“近似准确”，sum() 完全够用；若需精确 delta，优先考虑 sumThenReset() + 外部同步采集周期

和 ConcurrentHashMap 配合使用时要注意什么？

很多人用 ConcurrentHashMap 做多维度计数（如按接口名统计调用量），这时容易忽视 key 的生命周期管理：如果 key 长期不访问又不清理，map 会无限膨胀。

关键点：

• 别让 LongAdder 实例长期闲置却保留在 map 中；可结合 computeIfAbsent() 懒创建，再配合定时任务或 LRU 清理冷 key
• ConcurrentHashMap 的 compute() 系列方法传入的 lambda 里，不要对 LongAdder 做非幂等操作（例如重复 increment()），否则可能因重试导致多计
• 如果维度爆炸（比如用户 ID 级别计数），LongAdder + ConcurrentHashMap 仍可能 GC 压力大，此时该考虑采样或预聚合（如先按分钟聚合再进 map）

真正难的不是换类型，而是想清楚“这个数到底要多准”——LongAdder 给你的是高吞吐下的实用精度，不是数据库事务级别的确定性。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~