volatile 通过读写内存屏障保证运行时变量的即时可见性，final 通过构造器末尾写屏障保障对象初始化后 final 字段的正确可见性；二者机制、时机与适用场景不同，常协同用于安全发布。
volatile 和 final 都能保证多线程下的可见性，但机制不同、适用场景不同、内存屏障插入位置和类型也不同。理解它们的差异，关键不在于“谁更强”，而在于“各自解决什么问题”。
volatile 的可见性靠写-读链路 + 内存屏障强制同步
volatile 保证的是“一个线程写完，其他线程立刻能读到最新值”，依赖三重保障：
- 写操作插入 StoreStore + StoreLoad 屏障：确保前面所有普通写已刷新到主内存，并强制将 volatile 变量值立即写入主内存，同时使其他 CPU 缓存中该变量副本失效（MESI 协议下触发 Invalid）；
- 读操作插入 LoadLoad + LoadStore 屏障：禁止后续读/写重排到该读之前，并强制从主内存（或一致性协议保证的最新缓存行）重新加载值，不复用寄存器或本地缓存旧值；
- 构成 happens-before 链：volatile 写 happens-before 后续任意线程对该 volatile 变量的读，从而把写前的操作“传递”给读线程（如 JSR-133 示例中 x=42 在 v=true 前执行，reader 看到 v==true 就一定能看见 x==42）。
final 的可见性靠构造完成时的写屏障 + 安全发布约束
final 不是为“运行时反复修改”设计的，它保证的是“对象构建完成后，其他线程看到的 final 字段一定是初始化后的正确值”，核心在构造过程：
- 构造器末尾插入 StoreStore 屏障（针对 final 字段）：JMM 要求，在构造器结束前，所有 final 字段的写入必须完成，并且这些写不能被重排序到构造器外；
- 仅对“安全发布”的对象生效：即该对象引用不能在构造完成前“逸出”（this 引用未溢出）。一旦通过正确方式发布（如 static final 引用、volatile 写、锁保护、构造后才赋值给共享变量），其他线程读到该引用时，就能看到 final 字段的初始化值；
- 不提供运行期可见性保障：final 字段一旦初始化完成就不能再改，所以它不涉及“多次写 → 多次读”的同步问题，也就无需读屏障；它的屏障只在写端（构造器内）起作用。
两者内存屏障规则的关键区别
对比本质在于“时机”和“方向”：
立即学习“Java免费学习笔记（深入）”；
- volatile 屏障是双向、动态、运行期持续生效的：每次读/写都插屏障，适用于需要频繁更新并要求即时可见的标志位、状态开关等；
- final 屏障是单向、静态、仅在构造完成点生效的：只在构造器结尾插入一次写屏障，用于固化对象初始状态，不支持后续修改；
- volatile 不保证构造安全：即使字段是 volatile，若 this 溢出，仍可能让其他线程看到部分初始化的对象；
- final 不保证非 final 字段可见：如示例中 final int x 一定可见，但普通 int y 可能为 0 或 4（取决于是否安全发布）。
典型协同使用场景：双重检查锁定中的 volatile + final
以单例模式为例，二者配合体现语义互补：
- volatile instance：防止 instance 引用赋值与对象构造指令重排，确保其他线程拿到非 null 引用时，对象已完全初始化；
- 类内部 final 字段：如单例类中定义 final Helper helper = new Helper();，保证 helper 字段本身在构造完成后对所有线程可见；
- 组合效果：volatile 解决“引用发布”的有序性，final 解决“字段初始化”的可见性，共同构成安全的对象发布链条。
