17370845950

LongAdder 比 AtomicLong 更快，因其采用分段累加+最终合并策略，通过 base 值与 cells 数组分散线程竞争，降低 CAS 自旋开销，吞吐量近似随 CPU 核心数线性增长。

在高并发场景下，用 LongAdder 替代 AtomicLong 能显著提升计数性能，核心在于它用“分段累加 + 最终合并”的思路，避免了多线程竞争同一变量带来的 CAS 自旋开销。

为什么 LongAdder 比 AtomicLong 更快？

AtomicLong 所有线程都争抢更新同一个 volatile 变量，高并发时大量 CAS 失败、重试，CPU 浪费严重；LongAdder 则内部维护一个 base 值 + 一个 cells 数组，每个线程优先尝试更新自己绑定的 cell，冲突概率大幅降低。

只有当 cells 初始化失败或扩容失败时，才退化为更新 base —— 这种“尽量分散、必要时兜底”的设计，让吞吐量随 CPU 核心数近似线性增长。

怎么正确使用 LongAdder？

用法极简，但要注意语义差异：

• 初始化：LongAdder counter = new LongAdder();
• 累加：counter.increment(); 或 counter.add(5);
• 读取总和：counter.sum();（不是 get()！）
• 重置计数：counter.reset();（清空 base 和所有 cell，比反复 new 更轻量）

⚠️ 注意：sum() 是非原子快照，不适合做严格条件判断（如“是否达到阈值”需额外同步）；若需强一致性读写，仍应回归 AtomicLong。

底层结构与关键细节

LongAdder 继承自 Striped64，核心字段包括：

• transient volatile Cell[] cells;：哈希表式数组，长度为 2 的幂，每个元素是一个带 @Contended 的 long 单元，防伪共享（false sharing）
• transient volatile long base;：基础值，cells 未初始化或争用激烈时的备用累加位置
• transient volatile int cellsBusy;：自旋锁，控制 cells 初始化和扩容（仅用 0/1 表示是否被占用）

线程通过 ThreadLocalRandom.getProbe() 计算 hash，再与 cells.length-1 取模定位 cell；probe 值由线程私有且延迟初始化，天然具备隔离性。

适用场景与避坑提醒

适合：监控指标统计（QPS、错误数）、批量任务计数、限流器中的请求计数等——对实时性要求不高、但对吞吐敏感的累加场景。

不适合：

• 需要原子读-改-写（如 compareAndSet）
• 计数值要作为同步条件（如 while(counter.sum()
• 极低并发（单线程或 2~3 线程），此时 AtomicLong 更轻量

小技巧：如果应用已用 AtomicLong，只需改三处 —— new、add、sum，基本就这些。