异常处理与内存模型：分析 volatile 变量在 try 块内修改后发生异常时的可见性保证-Java面试题-PHP中文网

volatile变量的可见性取决于写操作是否实际执行，而非是否在try块中；只要volatile赋值完成，即使后续抛异常，新值也对其他线程可见。

异常处理与内存模型：分析 volatile 变量在 try 块内修改后发生异常时的可见性保证

volatile 变量在 try 块中被修改后若发生异常，其可见性依然成立——只要写操作实际执行完成，新值就对其他线程可见；但若写操作因异常未执行（如发生在赋值前），则无可见性可言。关键不在于代码是否在 try 中，而在于 volatile 写操作是否真正发生。

volatile 的可见性由写动作触发，与异常无关

Java 内存模型（JMM）规定：对 volatile 变量的每次成功写入（assign 操作），都会触发两个动作：

立即刷新该值到主内存；
插入 Store 屏障，禁止其前面的普通写操作重排序到它之后。

这些动作在 JVM 执行到该赋值语句时即刻发生，不依赖 try 块是否正常结束、也不受 catch 或 finally 影响。只要这行 volatile 赋值被执行了（例如 flag = true;），无论后续是否抛出 NullPointerException 或 ArithmeticException，该写操作带来的可见性保障已经生效。

常见误区：把“语句执行”等同于“赋值完成”

以下情况不会产生可见性效果：

volatile 写操作本身被异常中断（极罕见，如 OOM 导致赋值未开始）；
写操作位于异常发生点之后（例如 try 块中先抛异常，再写 volatile）；
volatile 变量是复合操作的一部分（如 counter++），而 ++ 不是原子操作，即使变量声明为 volatile，自增过程仍可能被中断，且中间状态不对外可见。

例如：

volatile boolean done = false;
try {
  doSomething(); // 抛出异常
  done = true; // 这行根本没执行 → 其他线程看不到 true
} catch (Exception e) {
  done = false; // 这行执行了 → false 对其他线程可见
}

finally 中的 volatile 写入仍具完全可见性

即使 try 块抛异常，只要 finally 块中执行了 volatile 写操作，它同样满足 JMM 的可见性要求：

JVM 保证 finally 块在控制流离开 try/catch 后必然执行（除非 System.exit 或线程中断）；
其中的 volatile 赋值仍会触发内存屏障和主内存同步；
其他线程读取该变量时，将看到 finally 中写入的最新值。

这是安全发布状态或清理标记的常用模式，例如：

volatile boolean initialized = false;
try {
  initResource(); // 可能失败
  initialized = true; // 成功路径
} finally {
  if (!initialized) {
    cleanup();
    initialized = false; // 显式回退，对所有线程可见
  }
}