LongAdder 比 AtomicLong 快，是因为采用分段计数（base + cells 数组）减少线程争抢，而非更强原子性；低并发用 base，高并发自动扩容 cells，配合 @Contended 防伪共享提升多核性能。
LongAdder 为什么比 AtomicLong 快？不是“更原子”，而是“少争抢”
它快，是因为根本没让所有线程去抢同一个内存地址。AtomicLong 的 incrementAndGet() 底层死磕一个 value 字段，10 个线程一起调，9 个大概率 CAS 失败、立刻自旋重试——CPU 白转，缓存行反复失效，吞吐量反而暴跌。
LongAdder 换了思路：用一个 base 值 + 一组独立的 Cell（数组），每个线程通过哈希尽量固定写入某个 Cell。Thread-1 写 cells[2]，Thread-2 写 cells[5]，互不干扰。最后 sum() 时才把它们加起来。
- 低并发时只用
base，零额外开销 - 竞争加剧时自动扩容
cells数组（2 的幂次），直到冲突缓解 - JDK 8+ 中
Cell类加了@Contended，防伪共享——这点常被忽略，但直接影响多核性能
什么时候该用 LongAdder？别在错误场景硬套
它专为「写多读少、允许最终一致」的统计类场景设计，比如 QPS 计数、请求总量、耗时累加器。不是所有“要加数字”的地方都适合它。
- ✅ 适合：
LongAdder用于埋点上报、监控指标聚合、批处理任务计数 - ❌ 不适合：需要瞬时强一致读写的逻辑，比如信号量实现、库存扣减、状态机跳转判断
- ⚠️ 警惕：
sum()不是快照——调用瞬间可能有线程刚写进本地Cell还没参与合并，结果略低于真实值（通常差几个数量级） - ⚠️ 切勿用
toString()取值，它内部调的是sum()，纯属多套一层，无收益
sum() 和 longValue() 有区别吗？怎么取值才安全
没有本质区别。longValue() 就是 sum() 的包装，二者行为完全一致。关键不在函数名，而在你对“一致性”的预期是否合理。
立即学习“Java免费学习笔记（深入）”；
-
sum()遍历所有cells并加上base，开销随 cell 数量线性增长，但高并发下这点开销远小于 AtomicLong 的自旋成本 - 如果业务要求“某次 increment 后立刻能被读到”，
sum()满足不了——这不是 bug，是设计契约 - 真需要强一致读写，回退到
AtomicLong或加锁；想兼顾性能又需近似实时，可考虑定期调用sum()+ 缓存，但别指望它替代 CAS 语义
初始化和线程数多少才触发分段？别猜，看实际表现
LongAdder 是懒加载的：初始只有 base，第一个发生竞争的线程才会创建首个 Cell；后续竞争持续存在，才逐步扩容。所以“启动就配 16 个 cell”毫无意义，JVM 会按需分配。
- 单线程或极低并发下，
LongAdder和AtomicLong性能几乎一样，甚至略慢一点（因多一层分支判断） - 实测拐点通常在 4–8 线程并发递增时出现；超过 16 线程后，
AtomicLong吞吐量可能跌到单线程的 1/3，而LongAdder仍接近线性增长 - 别依赖线程 ID 做哈希映射（如
id % N），LongAdder 用的是Thread.probe，更均匀且避免哈希冲突集中
最常被绕过的点：它不提供 compareAndSet()，也没有 getAndIncrement() 这类带返回值的原子操作。如果你代码里写着 if (counter.sum() > 100) fireAlert();，那这个告警阈值本身就是模糊的——它只是某一时刻尽力而为的估算值。
