volatile能避免多线程读取陈旧数据，核心是强制读写直通主内存、禁用工作内存缓存，并通过LoadLoad/StoreLoad屏障+MESI协议实现立即刷新与失效广播，同时禁止重排序保障初始化完成后再赋值。

volatile 能避免多线程读取到陈旧数据，核心在于它强制变量的读写直通主内存，绕过线程私有的工作内存（如 CPU 缓存），从而打破“缓存不一致”这个根源问题。

强制每次读都从主内存加载

普通变量可能被线程缓存在本地工作内存中，修改后未必立刻写回主内存，其他线程读的仍是旧值。而 volatile 变量每次被读取时，JVM 会插入 LoadLoad 屏障，要求线程必须丢弃本地缓存副本，直接从主内存重新加载最新值。

• 比如一个 volatile boolean running = true；多个线程在 while(running) 循环中轮询，只要某一线程将 running 设为 false，其余线程下一次读取时一定看到 false，不会卡在旧的 true 中
• 这背后依赖硬件级的 MESI 缓存一致性协议：当一个 CPU 修改 volatile 变量所在缓存行，会广播“失效”信号，其他 CPU 收到后自动作废该缓存行，下次读就必须去主内存取

写操作立即刷新到主内存

线程对 volatile 变量的写入，不是先存本地再异步刷出，而是执行完写操作后，立刻通过 StoreLoad 屏障 将新值同步到主内存，并确保该动作对其他线程可见。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 例如：thread1 执行 flag = true（flag 是 volatile），这一赋值完成后，主内存中的 flag 就已是 true；thread2 紧接着读 flag，就不会读到初始化时的 false 或未更新的中间状态
• 这种“写即发”机制，配合“读即取”，构成了完整的可见性闭环

禁止编译器和 CPU 的重排序干扰

重排序可能导致“变量已写但逻辑上还没就绪”的假象。volatile 通过内存屏障禁止特定方向的指令重排，保障读写顺序符合代码意图。

立即学习“Java免费学习笔记（深入）”；

• 典型场景是单例双重检查锁（DCL）：instance = new Singleton() 这一行实际包含三步（分配内存、初始化对象、instance 指针赋值）。若无 volatile，后两步可能被重排序，导致其他线程拿到一个尚未初始化完成的对象引用
• 加上 volatile 后，JMM 确保“初始化完成”一定在“指针赋值”之前发生，杜绝了陈旧或半初始化状态的暴露

它不靠锁、不阻塞线程，而是用内存访问语义的硬性约束来保证所有线程看到的是同一份实时数据。