volatile通过内存屏障保证有序性与可见性，但不保证原子性及多变量协同一致性，需配合锁、原子类或happens-before传递性实现数据一致性。
volatile 本身不保证多线程数据一致性，它只负责解决其中两个关键环节：可见性与有序性。数据一致性是结果，需要开发者结合语义、操作粒度和配套机制共同达成。
volatile 如何落实有序性规范
有序性不是靠“加个关键字”自动生效的，而是通过内存屏障（Memory Barrier）在编译器和 CPU 层面强制约束指令执行顺序：
- 写 volatile 变量时，插入 StoreStore 和 StoreLoad 屏障：确保该变量之前的写操作全部完成，且之后的读写不能被重排到它前面；
- 读 volatile 变量时，插入 LoadLoad 和 LoadStore 屏障：确保该变量之后的读写不会被提前到它前面执行；
- 这种屏障组合，使 volatile 变量成为代码逻辑中的“同步点”，形成 happens-before 关系——即对它的写操作先行发生于后续对它的读操作。
仅靠有序性无法保障数据一致性
有序性解决的是“执行顺序错乱”问题，但不解决“操作本身是否完整”或“多个变量是否协同更新”的问题：
- 比如 flag = true 被 volatile 修饰后，能确保 x = 42 一定在它之前执行（若按代码顺序写在前面），但无法保证 x 的赋值本身是原子的（x 是 long 或 double 时可能有字长撕裂）；
- 更关键的是，volatile 不绑定其他变量——即使你先设 x=1、再设 volatile ready=true，也不能自动让其他线程看到 x=1 的最新值，除非它也读取 x 且 x 的读取发生在 ready 为 true 之后（依赖 happens-before 传递性）；
- 若涉及多个状态变量（如 status、data、timestamp），仅用一个 volatile 标志位无法保证它们整体一致；此时需用锁、原子引用（AtomicReference）封装对象，或使用 volatile + final 字段配合安全发布。
典型可靠配合模式：DCL 单例中的有序性落地
双重检查锁（DCL）是 volatile 体现有序性价值最经典的场景：
立即学习“Java免费学习笔记（深入）”；
- new Singleton() 实际包含三步：① 分配内存；② 初始化对象；③ 将 instance 引用指向该内存地址；
- JVM 和 CPU 可能将②和③重排序，导致 instance 非空但对象尚未初始化完成；
- 用 volatile 修饰 instance 后，禁止了②③重排，并确保初始化完成后的所有字段写入对其他线程可见（借助 StoreLoad 屏障）；
- 这样，当线程读到 instance != null，就能安全使用该实例——有序性 + 可见性共同支撑了“安全发布”这一数据一致性前提。
实际编码中需注意的边界
有序性规范要真正起作用，必须满足 JVM 内存模型的约束条件：
- volatile 变量必须是共享的、非局部的（只能修饰成员变量或静态变量）；
- 读写操作必须是直接对 volatile 变量本身进行的，不能通过反射绕过，也不能混用非 volatile 访问；
- 复合操作（如 i++、list.add()）即使目标字段是 volatile，依然不具原子性，仍需额外同步；
- volatile 不能替代锁来保护临界区——它不提供互斥，只提供“通知+顺序锚点”能力。
