LongAdder通过Cell数组与@Contended注解实现缓存行隔离，天然缓解False Sharing；其add()分层降级策略将写操作分散至独立缓存行，sum()弱一致性适合写多读少场景。
直接用 AtomicLongAdder（实际应为 LongAdder，Java 标准库中无 AtomicLongAdder 类）就能天然缓解 False Sharing，关键不在“怎么用”，而在于理解它如何通过结构设计绕开缓存行争用。
Cell 数组 + @Contended 是防伪共享的核心机制
False Sharing 的本质是多个变量被 CPU 缓存行（通常 64 字节）一并加载，当不同线程频繁修改同一缓存行内的不同变量时，即使逻辑上互不干扰，也会因 MESI 协议反复使缓存失效，拖慢性能。
LongAdder 的 Cell 类被 @jdk.internal.vm.annotation.Contended 注解标记。该注解会触发 JVM 在对象头与 value 字段之间插入大量填充字节（padding），确保每个 Cell.value 独占一个缓存行，彼此物理隔离。
这意味着：即使两个线程哈希到相邻的 Cell 槽位，它们更新的 value 也绝不会落在同一个缓存行里——从根源上切断了 False Sharing 的通路。
写多读少场景下，add() 的执行路径天然避开热点
在高并发写入时，LongAdder.add() 不会死磕单个变量。它的策略是分层降级：
- 第一步：尝试 CAS 更新
base。若无竞争，快速完成； - 第二步：一旦失败（说明已有竞争），立即转向线程本地映射的
Cell； - 第三步：若该
Cell为空或更新失败，才触发cells初始化或扩容。
这个过程让写操作迅速从全局变量（base）分散到多个独立缓存行的 Cell.value 上。写多时，压力被摊薄；读少时，sum() 的遍历开销可忽略——这正是为写多读少量身定制的权衡。
避免手动创建 Cell 或误用 volatile long 数组
有人试图自己模拟类似结构，比如定义 volatile long[] counters，这是危险的：
- 数组元素在内存中连续布局，相邻
counters[i]和counters[i+1]极大概率落入同一缓存行； - 没有
@Contended填充，False Sharing 无法规避； - 缺乏
cellsBusy锁和哈希映射逻辑，扩容和线程绑定不可靠。
正确做法就是直接使用 LongAdder 实例，不暴露、不继承、不重写其内部结构。它的初始化、扩容、哈希分配、@Contended 布局全部由 JDK 封装完成，且经过长期验证。
sum() 的弱一致性不影响写多读少的实用性
sum() 是无锁遍历：base + cells[i].value 累加。过程中其他线程可能正在修改某个 Cell，所以结果不是严格实时的。
但在写多读少的统计类场景（如 QPS 计数、请求总量、错误计数器）中，这种毫秒级延迟完全可接受。比起用 synchronized 或 ReentrantLock 强一致性带来的吞吐骤降，LongAdder 提供的是更高吞吐 + 合理精度的组合。
