volatile在多线程状态机中确保状态变量的可见性与有序性，适用于单纯状态切换；它不保证原子性，需配合锁或cas处理复合操作及关联副作用。
volatile 在多线程共享状态机设计中，核心作用是确保状态变量的**可见性**和**有序性**，让所有线程能及时、一致地感知状态变更，同时防止因指令重排序导致的状态错乱。它不解决原子性问题，所以适合用于“单纯切换状态”这类简单操作，而非复合修改。
状态标志位：最典型也最实用的应用
状态机往往由几个离散状态组成（如 INIT → RUNNING → PAUSED → STOPPED），用一个枚举或整型变量表示。当多个线程需要根据该状态做不同行为时，必须保证状态更新对所有线程立即可见。
- 不加 volatile 的风险：一个线程调用了 setState(RUNNING)，另一个线程可能仍在读取旧值 INIT，继续执行初始化逻辑，造成重复初始化或逻辑跳过。
- 加 volatile 后：写入新状态时，JMM 会插入写屏障，强制刷新到主内存；读取时插入读屏障，强制从主内存加载最新值。线程间状态同步不再依赖锁，轻量高效。
- 示例代码中，state 字段声明为 private volatile State state = State.INIT;，后续所有 setState() 方法只需直接赋值（如 state = State.RUNNING），无需 synchronized —— 因为赋值本身是原子的，且 volatile 保障了可见与有序。
配合双重检查锁，避免状态机初始化阶段的竞态
状态机实例本身常采用懒加载单例模式（尤其在框架中作为全局状态管理器）。此时 volatile 不是对状态变量，而是对状态机实例引用本身起作用。
- 例如：private static volatile StateMachine instance;
- 若不用 volatile，线程 A 在 new StateMachine() 过程中可能发生重排序（先赋地址、后调构造），线程 B 可能拿到一个未完成初始化的 instance，并调用其 getState() —— 返回 null 或默认值，引发 NPE 或状态误判。
- volatile 确保 instance 引用的写入与读取构成 happens-before 关系，B 线程看到非 null 的 instance 时，一定能看到其完全初始化后的内部状态（包括内部的 volatile state 字段）。
状态流转的边界控制：用 volatile 配合 CAS 实现无锁状态跃迁
对于要求强一致性的状态变更（比如只允许从 RUNNING → PAUSED，禁止跨步到 STOPPED），可结合 AtomicInteger 或 AtomicReference + volatile 实现安全跃迁。
- volatile 本身不提供 compare-and-set，但它是 AtomicXxx 类底层内存语义的基础——AtomicXxx 的 get/set 方法本质上就是带 volatile 语义的读写。
- 推荐写法：使用 AtomicReference
stateRef = new AtomicReference(INIT); 然后通过 stateRef.compareAndSet(RUNNING, PAUSED) 控制流转。这里的 volatile 语义已内建，无需额外修饰。 - 若坚持用普通字段，则必须搭配 synchronized 或 Lock，否则即使有 volatile，也无法阻止两个线程同时成功执行 state = PAUSED（因为赋值不是原子比较+赋值）。
注意边界：volatile 不能替代锁来保护状态关联逻辑
状态变更常常伴随副作用：比如从 RUNNING 切到 STOPPED 时，需关闭连接、清空队列、通知监听器。这些操作无法靠 volatile 保证原子性或互斥性。
- volatile 只管“状态字段本身”的读写，不管它背后的业务动作。
- 正确做法：用 volatile 标记状态，用 synchronized 或 ReentrantLock 包裹状态变更及关联操作，形成“状态+行为”原子块。
- 例如：synchronized (this) { if (state == RUNNING) { state = STOPPED; closeResources(); notifyListeners(); } }
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
