volatile不能替代锁，仅适用于单写多读、无复合操作、仅需可见性与禁止重排序的场景，如状态标志位、DCL单例中的instance声明；涉及原子性或互斥时必须用锁。
volatile 不能替代锁机制，但可以在特定场景下避免使用锁。关键不是“能不能替代”，而是“该不该用”——这取决于你要解决的是原子性、可见性，还是有序性问题。
先看 volatile 能做什么
它只做三件事：
- 保证可见性：一个线程修改 volatile 变量后，其他线程能读到最新值（通过 StoreBarrier 和 LoadBarrier 强制刷主存、重加载）；
- 禁止部分指令重排序：编译器和 CPU 不会把 volatile 写之前的普通写，重排到它之后；也不会把 volatile 读之后的普通读，重排到它之前；
-
不提供互斥，也不保证原子性：比如
counter++这种“读-改-写”操作，volatile 完全无法保证线程安全。
再看锁能做什么
synchronized 或 ReentrantLock 是完整同步方案：
- 互斥访问：同一时刻最多一个线程执行临界区代码；
- 保证原子性：整个临界区逻辑不可分割；
- 同时保障可见性与有序性：进入锁时从主内存重读变量，退出锁时强制写回主内存。
怎么评估是否该用 volatile 替代锁
问自己三个问题：
立即学习“Java免费学习笔记（深入）”；
-
这个变量是否只被单个线程写、多个线程读？比如状态标志
volatile boolean isRunning = true;—— 适合 volatile； -
有没有“复合操作”要保护？如
if (list.isEmpty()) list.add(x);或value = value * 2 + 1;—— 必须用锁，volatile 无效； - 是否需要防止指令重排影响逻辑正确性？例如双重检查锁定（DCL）单例中，volatile 能禁止 new 操作的重排，这是它不可替代的价值点。
典型误用场景
这些情况用 volatile 就是错的：
- 计数器累加（
i++）、集合增删、对象引用更新后还需调用其方法； - 多个 volatile 变量之间存在依赖关系（如先设 flag = true，再设 data = xxx），volatile 无法保证它们之间的执行顺序；
- 把 volatile 当成“性能更好的 synchronized”，试图靠它保护一段业务逻辑。
本质上，volatile 是内存访问契约，锁是执行权契约。契约不同，用途自然不同。
