说起来，

写在前面

Day05 讲 AQS 的时候提到过一句“非公平锁直接 CAS 抢”。Day06 讲读写锁的 state 时也说“通过对 state 做 CAS 设置完成”——CAS 这个词已经出现好几次了但一直没有展开讲。这篇就正式把它讲透：java.util.concurrent.atomic 包是怎么不用 synchronized 加锁、纯靠 CAS 就实现线程安全的，还有 CAS 绕不开的经典坑——ABA 问题。

再看使用者痛点。高并发下频繁出现锁竞争、CPU 占用飙升，却找不到替代方案？

：atomic 包提供的无锁线程安全

java.util.concurrent.atomic 提供的是无锁的线程安全操作。底层依赖 CPU 的 CAS 指令，不需要像 synchronized/Lock 那样挂起线程，开销更小。说到它主要分四类，

选型原则：

• 纯计数累加 → 首选 LongAdder
• C​AS 判断并读取旧值 → AtomicLong/AtomicInteger
• 更新对象引用 → AtomicReference
• A​BA 风险 → 用带版本戳的 AtomicStampedReference
• A​BA 只需标记 → 用 AtomicMarkableReference

二、为什么：不加锁怎么保证线程安全

C​ode 示例:

AtomicInteger ai = new AtomicInteger;ai.get，// 读取当前值
ai.incrementAndGet;// ++i，返回新值
ai.getAndIncrement;
// i++，返回旧值
ai.compareAndSet;// 当且仅当当前值为5时设为10，返回是否成功
// JDK8+ 函数式写法
ai.updateAndGet;

L​ook at simplified implementation:

public class AtomicInteger {
private static final Unsafe unsafe = Unsafe.getUnsafe;private volatile int value;// volatile 保证可见性
public final boolean compareAndSet {
return unsafe.compareAndSwapInt;}
}

The volatile field guarantees that every read sees latest write。The call to Unsafe.compareAndSwapInt

再看使用者痛点，仍然担心 volatile 带来的“可见性”不足导致错误结果？这里通过硬件级别的原子指令解决掉。

B{执行
compareAndSet}
B -->|成功| C
B -->|失败
被别的线程抢先改了| A
-->