AtomicLongAdder缓存竞争优化解析

LongAdder 通过 Cell 数组与 @Contended 注解实现缓存行级物理隔离，从根本上规避了多线程写入引发的伪共享（False Sharing）性能陷阱；其 add() 方法采用“base 快速路径 → 线程本地 Cell 分散写入 → 懒扩容”的分层降级策略，将高并发写压力自然摊薄到多个独立缓存行，而 sum() 的弱一致性设计则以毫秒级延迟换取极高吞吐，完美适配 QPS 统计、请求计数等写多读少的核心场景——不必手动造轮子，直接使用 JDK 原生 LongAdder，就是对缓存友好并发编程最简洁有力的回答。

直接用 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 提供的是更高吞吐 + 合理精度的组合。

今天关于《AtomicLongAdder缓存竞争优化解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！