变量操作是‘单次读 / 写’（非复合操作），且需要可见性或禁止重排序，比如线程状态标记（isRunning）、配置参数（configFlag）；如果涉及原子性操作（如计数），则用 synchronized 或原子类，避免 volatile 的局限性。”

前言

网友上周面字节后端一面，之前面腾讯时栽过volatile的坑——当时被问DCL 单例为什么加volatile，只说了 “防重排序”，没讲清底层原理，直接挂了。

这次特意补了内存屏障、MESI 协议的细节，连x86和ARM的屏障差异都查了。还好提前把“作用+项目场景”捋顺了，这次总算能稳着答，顺利进入二面。

面试现场

面试官：“好，我们接下来聊 volatile。首先，你能先说说 volatile 关键字的核心作用是什么吗？”

候选人：“volatile 主要有两个核心作用：一是保证变量的内存可见性，二是禁止指令重排序，但它不保证原子性。实际项目中，我们常用来修饰状态标记（比如线程停止信号），但会结合 CAS 或 synchronized 解决原子性问题（埋点）。”

面试官：“那你提到的‘内存可见性’具体怎么理解？volatile 是如何保证可见性的？”(追问 1)

候选人：“可见性是指一个线程修改 volatile 变量后，其他线程能立刻看到最新值。底层依赖 CPU 的MESI 缓存一致性协议：当线程修改 volatile 变量时，CPU 会将该变量所在的缓存行标记为‘修改态’，并通过总线嗅探机制通知其他 CPU，让它们缓存的该变量副本失效，后续读取必须从主存重新加载，从而保证可见性。”

面试官：“OK，那‘禁止指令重排序’又是怎么实现的？底层涉及到什么关键技术？”(追问 2)

独白：“应该是说清楚啦”

候选人：“靠内存屏障（Memory Barrier）实现。JVM 会为 volatile 变量的读写操作插入特定的内存屏障，阻止屏障前后的指令重排序。比如写 volatile 变量后，会插入 StoreLoad 屏障，确保写操作先刷新到主存，再执行后续指令；读 volatile 变量前，会插入 LoadLoad 和 LoadStore 屏障，确保先读完主存最新值，再执行后续读 / 写操作，避免重排序导致的逻辑错乱。”

面试官：“你刚才说 volatile 不保证原子性，能举个具体例子说明吗？为什么会出现原子性问题？”(追问 3)

候选人：“比如经典的volatile int i = 0;，多线程执行i++操作，最终结果会小于预期。因为i++拆成‘读 i→加 1→写 i’三个指令，volatile 只能保证读和写的可见性；

但中间的‘加 1’操作没有被保护 —— 线程 A 读 i=0 后，线程 B 可能也读 i=0，两者都加 1 后写回主存，最终 i=1 而非 2。这就是原子性缺失，所以我们会用 AtomicInteger 这类原子类解决，它底层是 CAS 机制（埋点引导）。”

面试官：“那tomicInteger和volatile的核心区别是什么？为什么 AtomicInteger 能保证原子性？”(追问 4)

候选人:“核心区别是 AtomicInteger 通过CAS（Compare and Swap）机制保证原子性，而 volatile 只保证可见性和禁止重排序。AtomicInteger 的incrementAndGet()方法，会调用 Unsafe 类的compareAndSwapInt()，底层是 CPU 的原子指令（比如 x86 的 cmpxchg），能把‘读 - 改 - 写’三个操作打包成一个原子操作，不会被线程打断；而 volatile 没有这个机制，所以处理复合操作时会出问题。”

面试官：“回到内存屏障，JVM 为 volatile 变量插入的内存屏障具体有哪些规则？比如读操作和写操作分别插入什么屏障？”(追问 5)

独白：“应该是说清楚啦”

候选人：“JVM 有明确的内存屏障插入规则，核心是‘四屏障两操作’：

这样就能完全禁止读写操作与其他指令的重排序，同时保证可见性。”

面试官：“那你有没有了解过，不同 CPU 架构（比如 x86、ARM）对内存屏障的支持不一样，JVM 是怎么适配这种差异的？”(追问 6)

候选人：“JVM 会根据 CPU 架构做‘屏障优化’，因为不同 CPU 的内存模型（比如 x86 的 TSO、ARM 的弱内存模型）对重排序的限制不同。比如 x86 架构本身禁止‘写 - 读’重排序，且支持缓存一致性；

所以 JVM 在 x86 上对 volatile 写操作，只需要插入StoreLoad屏障（唯一需要显式指令的屏障），其他屏障（如 StoreStore）可以省略；而 ARM 架构更弱，需要插入更多屏障指令，JVM 会通过底层的Unsafe类或汇编指令适配，保证跨架构的一致性。”

面试官：“我们聊个实际场景 —— 双重检查锁（DCL）单例模式中，为什么 instance 要加 volatile？如果不加会出现什么问题？”(追问 7)

候选人：“因为instance = new Singleton()会被 JVM 重排序成‘1. 分配内存→2. 赋值 instance→3. 初始化对象’。如果不加 volatile，线程 A 执行到步骤 2 时，instance 已非 null，但对象还没初始化；

此时线程 B 进入 DCL 的第一层检查（if (instance == null)），会直接返回未初始化的 instance，导致空指针异常。加 volatile 后，禁止‘赋值’和‘初始化’的重排序，同时保证可见性，线程 B 能看到要么是 null，要么是完全初始化的对象。”

面试官：“最后一个问题，volatile 的开销和 synchronized 比起来怎么样？在什么场景下会优先选 volatile 而非 synchronized？”(追问 8)

候选人：“volatile 开销更低，因为它不需要加锁（无锁操作），也没有 synchronized 的‘偏向锁→轻量级锁→重量级锁’的锁升级过程，仅通过内存屏障和缓存一致性协议保证语义，执行速度接近普通变量。

优先选 volatile 的场景是：变量操作是‘单次读 / 写’（非复合操作），且需要可见性或禁止重排序，比如线程状态标记（isRunning）、配置参数（configFlag）；如果涉及原子性操作（如计数），则用 synchronized 或原子类，避免 volatile 的局限性。”