longadder 比 atomiclong 快在“少争抢”而非“更原子”，它通过分槽（cell 数组）降低 cas 竞争，但 sum() 是最终一致性快照，非强实时；需按读写场景选型，不可盲目替换。
LongAdder 比 AtomicLong 快在哪？不是“更原子”，而是“少争抢”
AtomicLong 的 incrementAndGet() 底层依赖 CAS，在多核高并发下，大量线程反复竞争同一个内存地址（value 字段），导致大量 CAS 失败、重试、伪共享和缓存行失效。LongAdder 则把计数分散到多个 Cell 上，线程先尝试无锁更新自己的槽位，仅当发生竞争时才退化为对 base 的 CAS —— 本质是用空间换局部无锁性。
这不是“更强的原子性”，而是“更少的同步点”。吞吐提升通常在 4+ 核、写操作占比 >70%、QPS >10k 的场景才明显；若读多写少，或单线程主导，LongAdder 反而因额外跳转和求和开销略慢。
替换 AtomicLong 时必须改写读逻辑：sum() 不是 get()
AtomicLong.get() 是即时精确值；LongAdder.sum() 需遍历所有 Cell 并加总 base，是最终一致性的快照，不保证强实时。如果业务依赖“写后立刻读到最新值”（比如限流器判断是否超阈值），直接替换会出错。
- 读场景宽松（如监控指标聚合、日志计数）→ 用
sum() - 读需强一致性（如库存扣减校验）→ 仍用
AtomicLong，或结合其他同步机制 - 注意
sum()不是原子快照：遍历时其他线程可能正在扩容Cell数组，但 LongAdder 内部已处理该竞态，结果仍是合理近似值
初始化和复用陷阱：不能靠构造函数清零，reset() 有代价
LongAdder 没有类似 AtomicLong.set(0) 的廉价重置方式。reset() 会把当前 sum() 值归零，并清空所有 Cell（但不释放数组），后续写入可能触发重新分槽。频繁调用 reset() 会导致缓存局部性下降和短时扩容抖动。
- 统计周期类场景（如每分钟汇总）→ 新建一个
LongAdder实例比复用 +reset()更稳 - 避免在循环内反复
reset()，尤其在压测中易暴露 GC 和 false sharing 问题 - 不要用
new LongAdder().sum()代替字面量0L，构造本身有开销
与 Striped64 的关系：别直接继承，也别手动 new Cell[]
LongAdder 是 Striped64 的子类，但 Striped64 是 JDK 内部抽象，字段（如 cells）和方法（如 retryUpdate）未开放。试图绕过 LongAdder 直接操作底层结构，不仅破坏封装，还会因 JDK 版本升级失效（例如 JDK 9+ 对 Cell 内存布局做了优化）。
也不建议用 ThreadLocal<longadder></longadder> 替代——它失去跨线程聚合意义；更不要自己实现分槽逻辑，JDK 已针对 cache line padding（@sun.misc.Contended）做了适配，手动实现极易掉进伪共享坑里。
真正难的不是换类型，是厘清“这个数字到底要被谁读、何时读、精度要求是什么”。很多团队压测看到吞吐涨了 20%，上线后却因某处 sum() 被当成实时值用，引发偶发超卖。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
