LongAdder在高并发写场景下性能优于AtomicLong，因其采用分段计数减少CAS争用，适合写多读少场景，但sum()不保证强一致性。
为什么不用AtomicLong而选LongAdder
在高并发写场景下，AtomicLong.incrementAndGet() 会因大量线程争抢同一个CAS变量导致严重自旋，吞吐量急剧下降。而 LongAdder 采用“分段计数 + 最终汇总”策略，把竞争分散到多个内部单元（Cell[]）上，写操作几乎不冲突。
它适合「写多读少」的计数场景（如QPS统计、请求计数器），但不适合需要严格实时一致性的场合——因为 sum() 不是原子快照，中间可能有未合并的增量。
如何正确初始化和使用LongAdder
直接构造即可，无需额外配置：
LongAdder counter = new LongAdder();
常用操作只有三个，语义清晰：
-
counter.increment()：+1，最常用 -
counter.add(10)：加任意long值 -
counter.sum()：获取当前总和（非强一致性）
注意：counter.longValue() 和 sum() 行为一致；不要用 toString() 做数值判断，它调用的是 sum() 后再转字符串，无额外收益。
sum() 的性能与一致性代价
sum() 需遍历所有 Cell 并加上 base 值，当并发写入频繁时，Cell[] 可能动态扩容，遍历开销略增；但相比 AtomicLong 在高争用下的退化，这点开销几乎可忽
关键限制：
- 它不保证调用
sum()时已合并所有待写值（例如某个线程刚写进本地Cell还没参与 Striped64 的竞争合并逻辑） - 不能替代
compareAndSet()类操作——LongAdder根本没有提供 CAS 接口 - 如果业务依赖“精确到某次调用的瞬时值”，必须换回
AtomicLong或加锁
和AtomicLong的实测差异在哪
在 32 线程、持续 increment 的压测中（JDK 17，Linux x86_64）：
-
AtomicLong吞吐约 8~12M ops/sec，随线程数增加快速饱和 -
LongAdder吞吐可达 40~60M ops/sec，扩展性明显更好
但若混入大量 sum() 调用（比如每 10 次 increment 就 sum 一次），LongAdder 优势会收窄——因为 sum() 是唯一需要全局遍历的操作，别把它当成廉价读。
真正要警惕的不是语法或初始化，而是误以为 sum() 是“强一致读”：它只是尽力而为的近似和，这个边界一旦模糊，监控指标就可能漏数或重复。
