原子类怎么用？无锁操作原理详解

Java中的AtomicInteger、AtomicReference等原子类并非万能的线程安全“银弹”，而是一种依托CPU级CAS指令实现的无锁优化手段，仅在单变量、逻辑简单的读-改-写场景下真正安全高效；一旦涉及复合判断、多步操作或可变对象共享，不仅无法保证线程安全，还可能因掩盖竞态、引发ABA问题、加剧CPU自旋或导致GC压力而适得其反——理解其边界与代价，比盲目替换synchronized更重要。

AtomicInteger 等原子类不是“线程安全的替代品”，而是特定场景下的无锁优化手段

直接说结论：Java 的 AtomicInteger、AtomicReference 等原子类，**只在单变量读-改-写（read-modify-write）且逻辑简单时才真正安全高效**。它们不是 synchronized 的平替，更不能覆盖复合操作。用错反而掩盖竞态，比加锁还难排查。

compareAndSet 是原子类的核心，不是“自动加锁”而是 CPU 级 CAS 指令

compareAndSet 的行为是：检查当前值是否等于预期值，是则更新为新值并返回 true；否则不修改，返回 false。它依赖底层 CPU 的 CAS（Compare-And-Swap）指令，无需操作系统介入，所以叫“无锁”。但这也意味着——

• 它不阻塞线程，失败后需由你决定重试（比如用 getAndIncrement 内部的自旋循环）
• 它只保证一次操作的原子性，if (i.get() 这种判断+更新仍是竞态
• 在高争用下，自旋可能浪费大量 CPU（尤其多核竞争同一变量时）

int expected;
do {
    expected = counter.get();
} while (!counter.compareAndSet(expected, expected + 1)); // 手动实现 increment

AtomicReference 适合封装不可变状态，但注意 ABA 问题和引用泄漏

AtomicReference 常用于无锁栈、队列或状态机，比如用一个 volatile Node 记录头节点。但它不解决 ABA 问题：某个值从 A → B → A，compareAndSet 会误认为没变过。JDK 提供了 AtomicStampedReference 用版本号缓解，但代价是额外字段和内存开销。

• 不要把可变对象塞进 AtomicReference（如 AtomicReference），外部仍可并发修改 List 内容
• 若用它存 Builder 或临时对象，注意 GC 压力——每次 set 都可能丢弃旧引用，导致短生命周期对象暴增
• 初始化必须用 new AtomicReference<>(initialValue)，空构造器初始值为 null，容易 NPE

性能不是绝对优势，要测真实场景下的吞吐与延迟拐点

原子类快，但快多少取决于争用程度和操作粒度。在低并发（AtomicInteger 通常比 synchronized 快 2–5 倍；但一旦线程数超过核心数，或操作涉及多个字段（比如账户余额+冻结金额同步更新），AtomicLongFieldUpdater 或 VarHandle 可能比全量锁更复杂，而直接上 ReentrantLock 反而更稳。

• JDK 9+ 推荐优先用 VarHandle 替代原子类，API 更统一，支持更多内存模型语义
• DoubleAdder / LongAdder 在高并发计数场景明显优于 AtomicLong，因内部用了分段累加+最终合并
• 别迷信“无锁=高性能”，LLC（末级缓存）伪共享（false sharing）会让多个原子变量在同一条 cache line 上互相踢出，大幅降速

无锁真正的门槛不在 API 调用，而在对内存模型、CPU 缓存一致性协议（MESI）、以及业务逻辑是否真能拆解成原子步骤的理解。写错的 CAS 循环，比写错的 synchronized 更难定位。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《原子类怎么用？无锁操作原理详解》文章吧，也可关注golang学习网公众号了解相关技术文章。