volatile变量的可见性取决于写操作是否实际执行，而非是否在try块中；只要volatile赋值完成，即使后续抛异常，新值也对其他线程可见。
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; // 显式回退，对所有线程可见
}
}
注意：可见性 ≠ 线程安全的完整保障
volatile 仅确保单次读/写的可见性和有序性，不提供原子性或临界区保护：
- 多个线程同时在 try 块中修改同一 volatile 变量，不会导致数据竞争（因为每次写都可见），但无法防止逻辑上的竞态（如“检查-然后-执行”场景）；
- 若需“修改并确认其他线程已响应”，仍要配合 wait/notify、LockSupport 或 CountDownLatch 等机制；
- 异常本身不破坏 volatile 语义，但可能掩盖状态不一致问题（例如资源部分初始化 + volatile 标志设为 true）。
