volatile仅保证标志位读写可见性与禁止重排序，不保证复合操作原子性；适用于单写多读的状态通知，禁用于读-改-写等非原子场景。
在状态标记位（Flag）场景下，volatile 的核心作用是**禁止编译器和处理器对读/写操作进行重排序，并确保变量修改对其他线程可见**——但它**不保证复合操作的原子性**。因此，规范使用的关键在于：只用它修饰“单纯读、单纯写”的布尔或整型标志位，且不依赖其完成“读-改-写”逻辑（如 flag++ 或 if(flag) flag = false）。
适用场景：纯状态通知（如启动/停止信号）
当 Flag 仅作为线程间“单向通知”的开关（例如“是否应停止运行”），且由一个线程写、多个线程读时，volatile 是恰当且轻量的选择。
- 典型例子：
private volatile boolean shutdownRequested = false; - 写线程调用
shutdownRequested = true;（单纯写） - 工作线程循环中检查
while (!shutdownRequested) { ... }（单纯读） - 此时
volatile能保证写入立即对读线程可见，避免因指令重排或寄存器缓存导致“永远读不到新值”
必须避免的误用：非原子的复合操作
volatile 不能替代同步机制来保护多步逻辑。以下写法即使加了 volatile 仍是线程不安全的：
-
if (flag) flag = false;—— 读和写是两个独立操作，中间可能被其他线程插入修改 -
flag = !flag;—— 非原子的“读取旧值→取反→写入”，存在竞态 -
flag++或counter++（哪怕只是计数）—— 涉及读-改-写三步，volatile无法保证整体原子性 - 用
volatile修饰引用类型并修改其内部状态（如volatile List<string> list = new ArrayList(); list.add("x");</string>）——volatile只保证引用本身可见，不保证对象内部操作线程安全
与 synchronized / AtomicInteger 的分工边界
明确什么该交给 volatile，什么该交给更重的同步工具：
- 用
volatile：只需“最新值可见”，无中间状态依赖，无条件竞争，如生命周期标志（running/stopped）、初始化完成标识（initialized） - 用
synchronized或ReentrantLock：需保护临界区、实现读-改-写逻辑、或协调多个变量的一致性（如if (count > 0) { count--; return true; }） - 用
AtomicBoolean/AtomicInteger：需要原子性布尔切换（compareAndSet）、原子计数、或带返回值的原子更新（如getAndIncrement）
补充实践建议
提升可维护性和安全性：
- 命名体现语义：用
isRunning、isInitialized、shutdownSignalReceived等清晰表达“只读状态”，避免flag1、status等模糊名 - 配合 final 修饰符：若 Flag 初始化后只写一次（如双重检查锁中的 instance），声明为
private volatile static SomeClass instance;，且构造过程无逸出 - 不用于性能敏感的高频轮询：虽然
volatile比锁轻量，但频繁读仍可能引发总线流量压力；高吞吐场景优先考虑事件驱动（如BlockingQueue、CountDownLatch） - 注意 JVM 版本差异：Java 5+ 的
volatile内存语义已严格定义（JSR-133），无需额外内存屏障指令；旧版本（Java 4 及之前）不推荐依赖
