volatile仅解决变量可见性，不保证原子性；适用于单写多读且写不依赖当前值的场景，如状态标志位；禁止指令重排序，但不保证long/double在32位JVM上的原子写；不延伸至引用对象内部。
volatile 不是用来替代 synchronized 或锁的，它只解决变量的可见性问题，不保证原子性。如果你需要“读-改-写”这类复合操作线程安全（比如 i++），volatile 无效。
volatile 变量必须满足“单次读或单次写”场景
它适用于一个线程写、多个线程读，且写操作不依赖当前值的场景。典型例子是状态标志位：
public class TaskRunner {
private volatile boolean running = true;
public void stop() {
running = false; // 单次写，无依赖
}
public void run() {
while (running) { // 多线程读，每次读都看到最新值
// do work
}
}
}
常见错误是误用于计数器：
❌ volatile int count = 0; 然后在多线程里执行 count++ —— 这会丢失更新，因为 count++ 包含读、加1、写三步，volatile 不保证这三步整体原子。
✅ 正确做法：用 AtomicInteger 或加锁。
volatile 如何禁止指令重排序
JVM 和 CPU 可能对指令重排以优化性能，但 volatile 写操作会插入“StoreStore”屏障，读操作插入“LoadLoad”和“LoadStore”屏障，确保：
- 写 volatile 变量前的所有普通写，不会被重排到该写之后
- 读 volatile 变量后的所有普通读/写，不会被重排到该读之前
这个特性常用于双重检查锁定（DCL）单例模式中防止对象未初始化完成就被其他线程看到：
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
public class Singleton {
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton(); // 非原子：分配内存 → 初始化 → 赋值给 instance
}
}
}
return instance;
}
}
没有 volatile，JVM 可能把“赋值给 instance”提前到“初始化”之前（只要语义合法），导致其他线程拿到一个未构造完的对象。
volatile 不能保证 long/double 的原子写（仅限 32 位 JVM）
Java 规范允许对 64 位变量（long、double）的读写拆成两个 32 位操作，即所谓“非原子性更新”。虽然现代 64 位 JVM 默认已保证原子性，但若目标环境明确是 32 位 JVM（如某些嵌入式或旧 Android 版本），且变量未声明为 volatile，就可能出现“半个 long 值”的问题。
所以：如果变量是 long 或 double，又需跨线程安全读写，必须加 volatile（或用 AtomicLong 等）。
注意：volatile 在这里的作用不是“让写变原子”，而是强制使用原子的读写指令，并禁用重排序——JVM 对 volatile long 的读写总是当作单个不可分割的操作来实现。
真正容易被忽略的是：volatile 的内存语义只作用于它修饰的变量本身，不延伸到该变量引用的对象内部。比如 volatile List，只保证 list 引用的可见性，不保证 list.add() 的线程安全。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
