longadder 的 sum() 方法返回近似值而非原子快照，因其遍历 cells 时无锁且不阻塞写入，导致结果仅为调用时刻可见部分的累加和；适用于监控统计等弱一致性场景，不适用于库存扣减等强一致需求。

LongAdder 的 sum() 方法在并发环境下返回的是一个近似值，不具备强一致性，这是它设计上的明确取舍，而非缺陷。

为什么 sum() 不是原子快照？

sum() 的执行过程是：先读取 base 值，再遍历 cells 数组中所有非 null 的 Cell，并累加它们的 value。这个过程不加锁、不阻塞写入——也就是说，其他线程可能正在：

• 往某个已存在的 Cell 中执行 add()，更新其值；
• 触发扩容，新建 Cell 并插入数组；
• 甚至刚完成 CAS 更新，但该新值尚未被当前 sum() 遍历到。

因此，sum() 返回的结果只是调用时刻“可见部分”的累加和，无法反映某一精确时间点的全局状态。

近似值在哪些场景下可接受？

它的弱一致性恰恰匹配了多数监控与统计类需求的真实语义：

• 每秒请求数（QPS）指标：允许毫秒级延迟或少量偏差，重点是趋势和量级；
• 错误计数、日志打点频次：只要最终收敛、不丢数据，中间瞬时值无需精确；
• 限流器中的粗粒度计数器（如分钟级阈值判断）：只要周期内总量可控，单次读取误差不影响策略有效性。

这类场景关注的是最终一致性和高吞吐写入能力，而非实时精确快照。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

什么情况下不能用 sum()？

一旦业务逻辑依赖严格顺序或瞬时精确值，sum() 就不再适用：

• 库存扣减：必须确保“读-判-扣”原子性，否则超卖风险极高；
• 分布式幂等令牌生成：需要唯一且不可重复的递增值；
• 金融类余额变更：任何中间态误差都可能导致账务不平。

这些场景应回归 AtomicInteger、AtomicLong 或数据库行锁等强一致机制。

sumThenReset() 也不能替代强一致

尽管 sumThenReset() 把求和与清零封装为一次调用，但它仍不保证对其他线程的排他性：

• 它只对当前线程看到的 cells 状态求和并重置；
• 若另一线程正往某个已被 reset 的 Cell 写入，该增量不会丢失，但也不会计入本次 sumThenReset() 的结果中；
• 它不是事务性操作，也不提供 happens-before 保障来约束其他线程行为。

所以它适合做周期性汇总+清零（如每分钟采集指标），但不能用于需严格因果关系的业务逻辑。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南