[面试题] volatile 的底层语义是什么？它能保证原子性吗？适用于哪些场景？

📖 版块 A：知识讲解版 (温故知新)

• volatile 的两大核心语义：

  1. 可见性：一个线程修改了 volatile 变量后，会立刻刷新到主内存；其他线程读取时，也会强制从主内存重新读取。
  2. 有序性：volatile 会通过内存屏障禁止特定类型的指令重排序，保证它前后的代码执行顺序满足并发语义。

• 不能保证原子性：

  • volatile 只能保证一次读或一次写本身是可见的。
  • 对于 i++、count = count + 1 这种“读-改-写”复合操作，它无法保证中间不被其他线程打断。

• 底层实现思路：

  1. JMM 层面：对 volatile 变量的写，会建立“写 happens-before 读”的关系。
  2. 编译器/CPU 层面：在读写前后插入内存屏障，限制重排序并配合缓存一致性协议传播最新值。

• 典型适用场景：

  1. 状态标志位：如任务停止标记、配置开关。
  2. 双重检查锁中的单例实例引用：防止对象初始化过程发生指令重排。
  3. 一个线程写、多个线程读，且不存在复合更新 的轻量共享变量场景。

• 不适用场景：

  • 高并发计数器。
  • 涉及多个变量一致性的业务逻辑。
  • 需要“判断并更新”原子语义的场景。

🎤 版块 B：面试实战版 (高手逐字稿)

Q：volatile 的底层语义是什么？它能保证原子性吗？适用于哪些场景？

💬 高手逐字稿：

volatile 本质上不是锁，而是 Java 内存模型里一个专门解决可见性和有序性的关键字。

它的第一层语义是可见性。正常情况下，线程读写共享变量时，值可能先停留在 CPU 缓存里，不会立刻同步到主内存。这样就会导致一个线程已经改了值，另一个线程还看不到。volatile 的作用就是让写线程修改完之后，最新值马上对其他线程可见；读线程每次读取时，也不能只看自己工作内存里的旧值，而是要重新去拿最新结果。

第二层语义是有序性。编译器和 CPU 为了性能会做指令重排，但在并发场景下，某些重排会直接把逻辑搞错。volatile 会在读写前后插入内存屏障，禁止关键位置的重排序。比如双重检查锁单例里，如果实例引用先赋值、对象初始化后完成，就可能让别的线程拿到一个“半初始化对象”，这就是为什么单例里的实例变量必须加 volatile。

但它有一个边界必须说清楚：volatile 不保证原子性。像 i++ 这种操作，底层其实分三步：读、改、写。即使 i 是 volatile，也只能保证每一步都可见，不能保证这三步打包成一个不可分割的整体。所以多个线程一起做 i++，结果照样可能丢失更新。

因此在实际使用上，我一般只在三类场景下用 volatile：

第一类是状态标志位，比如线程停止开关、配置刷新标志；第二类是DCL 单例，用来防止重排；第三类是单写多读的轻量共享变量。如果一旦涉及计数、自增、库存扣减这类复合更新，我就不会再用 volatile 了，而是会切到 CAS 原子类或者直接加锁。

一个比较容易被面试官追问的点是：为什么 volatile 写对后续线程读可见？ 本质上是因为 JMM 规定了对同一个 volatile 变量的写，happens-before 后续对它的读，这个规则再往下才会落到内存屏障和缓存一致性协议上。