longadder 的 sum() 方法返回近似总和而非原子快照，因其遍历 base 和 cell[] 时无锁且不阻塞写入，导致结果弱一致；适用于监控、限流、埋点等写多读少场景，但不可用于库存扣减、余额校验等需强一致性的业务。
LongAdder 的 sum() 方法返回的不是某个精确时间点的快照值，而是一个近似总和——它在并发写入场景下天然具备弱一致性特征。这不是 bug，而是为换取高吞吐所作的明确设计取舍。
sum() 为什么不是原子快照？
调用 sum() 时，LongAdder 会做两件事：读取 base 值 + 遍历当前所有已创建的 Cell 并累加它们的 value。但这个过程本身不加锁、不阻塞写入线程：
- 遍历 Cell[] 是顺序进行的，期间其他线程可能正在向某个已被遍历过的 Cell 写入新值，也可能正往尚未遍历的 Cell 或新扩容的 Cell 中写入；
- base 值在读取瞬间可能刚被另一个线程通过 CAS 更新，也可能还没反映到当前线程缓存中；
- Cell[] 数组本身可能动态扩容（例如从 2 扩到 4），sum() 只看到调用开始时的数组引用，不会等待扩容完成。
弱一致性的具体表现
在高并发持续写入过程中，多次连续调用 sum() 可能出现以下现象：
- 数值非单调递增：比如前一次 sum() 返回 1005，后一次反而返回 1003（因中间有 Cell 被 reset 或统计遗漏）；
- 相邻两次结果差值不等于实际增量：100 次 increment() 后，sum() 差值可能是 97 或 102；
- sumThenReset() 后立即再调用 sum()，可能仍返回非零值——因为 reset 发生时，其他线程的写入可能尚未落地到该 Cell，或已写入但未被本次 sum() 捕获。
哪些场景能接受这种弱一致性？
只要业务逻辑不要求“严格计数”或“实时扣减”，sum() 的结果就足够可靠：
- 监控大盘上的 QPS 曲线：波动几百分之一不影响趋势判断；
- 限流器中的请求计数：允许短时略超阈值，配合滑动窗口或令牌桶可平滑误差；
- 日志打点或埋点统计：用于分析用户行为路径，不要求单次精准；
- 批处理任务的进度汇报：显示“已完成约 87%”，无需精确到个位数。
绝对不能用 sum() 的地方
一旦涉及状态变更依赖准确数值，LongAdder 就不再适用：
- 库存扣减：sum() 返回 99 不代表真剩 99 件，可能已有其他线程刚写入但未汇总；
- 账户余额更新：不能靠 sum() 判断是否足够支付；
- 分布式幂等校验：不能用它生成唯一序列号或版本号；
- 需要 compareAndSet 语义的条件更新：LongAdder 根本不提供这类 API。
