DoubleAdder和LongAccumulator通过Striped64的base+Cell[]分段结构及@Contended注解隔离缓存行，将集中竞争分散为多点独立写入，从而避免伪共享导致的cache line bouncing；其高效前提是正确预热、纯函数accumulatorFunction和弱一致性sum()使用。
DoubleAdder 和 LongAccumulator 在超高并发下能显著缓解缓存行竞争，但前提是正确使用——它们本身不自动消除伪共享，而是依赖 @sun.misc.Contended 注解 + 分段 Cell 数组结构来隔离竞争。直接替换 AtomicLong 或 AtomicDouble 并不能“开箱即用”地解决所有问题，关键在初始化时机、线程绑定方式和读取语义。
为什么 DoubleAdder 的 add() 不会引发跨核缓存行失效
根本原因不是它“更快”，而是它把原本集中更新的单个 volatile long 拆成了多个物理隔离的写入点：
-
DoubleAdder继承自Striped64，内部有base字段 +Cell[] cells数组 - 每个
Cell类都加了@sun.misc.Contended，JVM 会在该对象前后填充 128 字节（默认），确保其独占一个缓存行（通常 64 字节） - 线程通过
ThreadLocalRandom.getProbe()计算哈希，映射到cells中某个槽位，绝大多数更新只发生在自己专属的Cell.value上 - 不同 CPU 核心写不同
Cell→ 不同缓存行 → 避免 false sharing 导致的 cache line bouncing
LongAccumulator 的 accumulatorFunction 如何影响竞争分布
LongAccumulator 的构造函数接受一个 LongBinaryOperator，这个函数不仅决定计算逻辑，还会影响竞争路径：
- 当调用
accumulate(x)时，若当前线程映射的Cell为空或 CAS 失败，会 fallback 到casBase：此时执行的是r = function.applyAsLong(b = base, x)，而非简单加法 - 如果
function是非幂等或耗时操作（如(a,b) -> a * b + System.nanoTime()），会导致casBase路径变慢，增加 fallback 频率，反而加剧 base 竞争 - 推荐仅使用纯函数、无副作用、O(1) 时间复杂度的操作，例如
(a,b) -> a + b（等价于LongAdder）、(a,b) -> Math.max(a,b)、(a,b) -> a & b - 注意：
identity值参与初始化，但不参与 CAS 比较；若设为非零值（如100L），sum()结果恒含该偏移，需业务侧明确知晓
超高并发下必须避开的三个初始化与读取陷阱
即便用了 DoubleAdder 或 LongAccumulator，以下操作仍会瞬间拉垮性能或导致结果错乱：
- 在多线程环境下首次调用
add()或accumulate()前，未预热cells数组：首次竞争触发的longAccumulate()内部要获取cellsBusy自旋锁 + 初始化数组（长度=2），此时所有线程阻塞等待，形成“初始化风暴” - 频繁调用
sum()并期望强一致性：该方法无锁遍历cells，返回的是弱一致快照；若在每轮循环中都调用sum()做条件判断（如while (adder.sum() ），会因重复遍历和不可预测的中间态造成逻辑错误或死循环 - 将
DoubleAdder用于需要精确浮点累加的场景：它的sum()返回double，但内部Cell存储的是volatile double，不保证 IEEE 754 运算顺序，多次add(0.1)后sum()可能出现0.30000000000000004——这不是 bug，是设计使然；如需精确小数，应改用BigDecimal+ 锁，或接受误差容忍
真正决定是否消除缓存行竞争的，从来不是类名里有没有 “Adder”，而是线程是否被稳定分散到互不干扰的内存位置。DoubleAdder 和 LongAccumulator 提供了这个能力，但不会替你做哈希均匀性校验、不会阻止你在 sum() 上做同步假设、也不会让 JVM 忽略 -XX:-RestrictContended 的存在——这些都得自己盯住。
