Java 面试：JVM 内存模型与 volatile 关键字

一、JVM 内存模型（Java Memory Model, JMM）

JMM 定义了多线程环境下共享变量的访问规则，核心目标是解决可见性、有序性和原子性问题。其结构分为两层：

1. 主内存（Main Memory）
   所有共享变量的存储区域，线程间数据交互的枢纽。
2. 工作内存（Working Memory）
   每个线程独享的本地副本，存储当前操作所需的变量。

数据交互流程：

• 线程修改共享变量时，需先将数据从主内存加载到工作内存（load操作）
• 修改后写回主内存（store操作）
• 此过程隐含可见性问题：若线程A修改后未及时写回，线程B可能读取旧值。

二、volatile 关键字的作用

volatile 通过 JMM 的内存屏障（Memory Barrier） 实现两大特性：

1. 可见性保证
   当线程修改 volatile 变量时：

   • 强制立即将工作内存的值刷新到主内存
   • 使其他线程工作内存中的该变量副本失效，需重新从主内存加载

   volatile boolean flag = false; // 声明 volatile 变量
   
   // 线程A
   flag = true; // 修改后对所有线程立即可见
   
   // 线程B
   while (!flag) { /* 循环直到检测到 flag 变化 */ } 
   

2. 禁止指令重排序
   编译器/CPU 可能优化指令顺序（如：$a=1; b=a+1$ 可能重排为 $b=a+1; a=1$）。
   volatile 通过插入内存屏障：

   • 写屏障：确保 volatile 写操作前的指令不会重排到其后
   • 读屏障：确保 volatile 读操作后的指令不会重排到其前

   volatile int resource = 0;
   int config = 0;
   
   void init() {
       config = 10;         // 步骤1（普通写）
       resource = 1;        // 步骤2（volatile 写，屏障阻止步骤1重排到此处之后）
   }
   

三、volatile 的局限性

1. 不保证原子性
   复合操作（如 count++）仍需 synchronized 或 AtomicInteger：

   volatile int count = 0;
   
   void unsafeIncrement() {
       count++; // 实际分为"读-改-写"三步，多线程可能覆盖结果
   }
   

2. 适用场景
   • 状态标志（如开关控制）
   • 单次写入多次读取的变量
   • 双重检查锁（Double-Checked Locking）中修饰实例

四、面试要点总结

关键理解：volatile 本质是轻量级同步机制，通过 JMM 的内存屏障控制变量访问顺序，适用于特定并发场景，但非万能锁替代方案。实际开发中需结合 java.util.concurrent.atomic 包或显式锁使用。