LongAdder 比 AtomicLong 更快，因其采用分段累加+最终合并策略，通过 base 值与 cells 数组分散线程竞争，降低 CAS 自旋开销，吞吐量近似随 CPU 核心数线性增长。
在高并发场景下，用 LongAdder 替代 AtomicLong 能显著提升计数性能，核心在于它用“分段累加 + 最终合并”的思路，避免了多线程竞争同一变量带来的 CAS 自旋开销。
为什么 LongAdder 比 AtomicLong 更快？
AtomicLong 所有线程都争抢更新同一个 volatile 变量，高并发时大量 CAS 失败、重试，CPU 浪费严重；LongAdder 则内部维护一个 base 值 + 一个 cells 数组，每个线程优先尝试更新自己绑定的 cell，冲突概率大幅降低。
只有当 cells 初始化失败或扩容失败时，才退化为更新 base —— 这种“尽量分散、必要时兜底”的设计，让吞吐量随 CPU 核心数近似线性增长。
怎么正确使用 LongAdder？
用法极简，但要注意语义差异：
立即学习“Java免费学习笔记（深入）”；
- 初始化：
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，基本就这些。
