java中volatile与cas需协同工作：volatile保障状态可见性与禁止重排序，为cas提供前提；cas实现原子状态跃迁，二者组合构成无锁单例与状态机的核心机制。
Java 中在多线程环境下实现高性能无锁单例或状态机转换，关键不是“用 volatile 或 CAS”，而是让两者各司其职、协同工作：volatile 保障状态可见与顺序，CAS 承担原子跃迁。脱离这个配合关系，单独强调任一机制都容易误入歧途。
volatile 解决“读得准”和“写得稳”
它不负责原子性，但为 CAS 提供前提条件：
- 所有线程每次读 state 或 instance 都强制从主内存加载，避免因 CPU 缓存不一致导致“以为没初始化/以为锁空闲”
- 禁止编译器和处理器对 volatile 写操作之前的指令重排序——比如 DCL 单例中，new Singleton() 的三步（分配内存、初始化对象、赋值引用）不会被重排成“分配→赋值→初始化”，否则其他线程可能拿到未初始化完成的对象
- volatile 字段本身不能保护集合、数组或复合结构，但它可作为“就绪开关”：先完成数据构造，最后写 volatile 标志；读线程先检查标志，再安全读取关联数据
CAS 实现“试一次，成则走，不成再试”
它是无锁推进的核心引擎，典型用于初始化竞争或状态流转：
- DCL 单例中，synchronized 块内第二次判空后，实际无需 CAS —— 因为已加锁，直接 new 赋值即可；真正需要 CAS 的场景是完全无锁路径，如 AtomicReference.compareAndSet(null, new Singleton())
- AQS 中 compareAndSetState(0, 1) 是标准加锁入口：只在 state 为 0（无人占用）时才设为 1，失败即说明有竞争，进入队列等待
- 状态机如 CountDownLatch，countDown() 调用 compareAndSetState(current, current - 1)，成功即减一，失败说明已被其他线程抢先修改，循环重试直到成功或归零触发唤醒
组合落地：两个典型模式
不是堆砌语法，而是按语义分工设计：
-
无锁单例（AtomicReference 版）：
private static final AtomicReferenceINSTANCE = new AtomicReference();
public static Singleton getInstance() {
Singleton inst = INSTANCE.get();
if (inst == null) {
inst = new Singleton();
if (INSTANCE.compareAndSet(null, inst)) {
return inst;
} else {
return INSTANCE.get(); // 竞争失败，取别人设好的
}
}
return inst;
} -
带版本的状态机（防 ABA）：
使用 AtomicStampedReference，把状态值 + 时间戳/版本号打包更新。
比如连接池中“可用连接数”变更时，不仅要校验当前值是否匹配，还要确认版本未被回绕，避免旧值覆盖新状态
注意事项：别踩这些坑
高性能的前提是正确，而正确依赖对边界的理解：
- CAS 不是万能的——高争用下自旋会浪费 CPU，应结合退避策略（如 Thread.yield()、短暂停顿）或兜底锁
- volatile 不能替代 synchronized 处理复合逻辑，比如“判断+修改+日志”必须整体同步，不能只给其中某个变量加 volatile
- 不要对非基本类型或非引用类型字段滥用 volatile，它只保证该字段本身的读写可见，不递归保护其内部字段
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
