volatile解决可见性和有序性问题：确保线程修改对其他线程立即可见，并禁止指令重排序；但不保证原子性，无法用于i++等复合操作。
volatile能解决什么问题？——不是锁，但能破“看不见”的僵局
volatile在Java并发中只干两件事：让一个线程对变量的修改，其他线程能“立刻看到”（可见性）；阻止编译器和CPU把读写这个变量的指令乱序执行（有序性）。它不保证原子性，所以别指望用它搞定 i++ 这种操作。
为什么普通变量会“看不见”修改？——缓存+重排序双坑
多核CPU下，每个线程有自己的工作内存（缓存），变量读写默认走缓存不直连主内存。线程A改了 flag = true，可能只写进自己缓存，线程B还在读自己缓存里的 false，死循环就来了。更糟的是，JIT或CPU还可能把 number = 42 和 ready = true 调换顺序执行，导致线程B看到 ready == true 却读到 number == 0。
- 常见错误现象：
while (!flag) { }无限卡住，即使主线程已设flag = true - 根本原因：工作内存未同步、指令重排破坏逻辑先后
- volatile一招破局：写时强制刷主内存，读时强制从主内存加载
怎么用才有效？——修饰对象引用、布尔开关、状态标志
volatile必须用于共享的实例变量或静态变量，局部变量加了也没用。典型场景是状态标志、单例双重检查锁中的实例引用、轻量级信号量。
public class Singleton {
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // volatile 防止构造过程被重排序
}
}
}
return instance;
}
}
- 必须修饰
instance字段本身，不能修饰方法或参数 - 适用于
boolean、int、long（注意：64位long/double在32位JVM上非原子，volatile可保其读写原子） - 不适用于复合操作：如
counter++、list.add()，仍需synchronized或AtomicInteger
容易踩的坑有哪些？——以为加了就万事大吉
最常犯的错，是把volatile当万能锁用。它只保单次读/写可见和有序，不保操作序列的原子性。比如两个线程同时执行 if (count ，就算 count 是volatile，依然可能超限。
立即学习“Java免费学习笔记（深入）”；
- 误用场景：用
volatile int count替代AtomicInteger做计数器 - 性能误解：volatile读比普通变量略慢（要清缓存行），但远快于synchronized；写则有明显开销（需内存屏障）
- 兼容性注意：Java 5+ 才真正规范volatile语义，老版本行为不可靠
真正需要volatile的地方，往往藏在“等待某个条件成立”的边界逻辑里——比如关闭信号、初始化完成标记、配置热更新开关。这时候它轻、快、准；一旦涉及“读-改-写”链条，就得换更重的工具了。
