一文梳理Java内存模型JMM：可见性、happens-before与volatile

面试时被问到“Java内存模型”，十个人里有八个会脱口而出：堆、栈、方法区、程序计数器。这个答案对吗？如果面试官问的是“JVM内存区域划分”，那没问题；但在多数中高级Java岗位面试里，当对方说“讲讲Java内存模型（JMM）”时，这其实是在问并发编程层面的内存抽象、可见性规则和happens-before。这两个概念名字太像，导致很多人在第一题就答偏，后面哪怕volatile和synchronized背得再熟，也总觉得和JMM对不上。这篇内容的目标就是帮你把JMM这条主线彻底捋清：它到底是什么、解决了什么问题、和JVM内存结构有什么区别、happens-before怎么用、volatile和synchronized在JMM里的真实语义是什么，最后用DCL单例把这些概念串起来。

这篇文章适合准备Java基础面试的人、刚学并发编程不久的新人，以及写了好几年代码但始终对“多线程数据不一致”解释不清楚的同学。我会尽量少讲贴规范层面的枯燥定义，多用能复现的代码和反例说话，毕竟JMM这种东西，真正理解之后会比死记硬背牢固得多。

1. 先分清JMM和JVM内存布局：这个坑让多少人面试第一题就凉了

1.1 JMM是规范，不是那几张“内存结构图”

Java内存模型（Java Memory Model）是一个规范，它回答的问题是：在多线程环境下，共享变量在什么时候对另一个线程可见？一个线程对共享变量的修改，在什么条件下能安全地被其他线程看到？以及编译器和处理器可以在多大程度上对指令进行重排序？

之所以需要这样一套规范，是因为Java的跨平台特性。同一个Java程序可能跑在x86服务器上，也可能跑在ARM手机上，这两类处理器架构对缓存一致性、指令乱序执行的支持完全不一样。如果Java不做统一，程序员写的并发代码在不同的硬件上表现可能完全不同。JMM相当于在Java语言层面定义了一层“内存访问契约”，无论底层是哪种处理器，只要JVM遵守JMM，开发者看到的并发行为就是一致且可预期的。

JMM关心的是变量如何在线程的“工作内存”和“主内存”之间流动，而不是严格指内存区域里某个对象放在堆还是栈。所以你把“堆、方法区、程序计数器”这串东西背得再熟，也只是回答了“JVM运行时数据区”，那不是JMM。

1.2 JVM内存布局再怎么说也替代不了JMM

很多Java八股文列表里，把“JVM内存模型”和“JMM”混在一起讲，导致很多人以为JMM只是在讲JVM把内存分成几块、每块存什么。这种理解对应用开发来说不算致命，但一到真正排查并发问题或者深入看volatile实现时，就会发现很吃力。

打个不严谨但好记的比方：JVM内存区域划分像一栋大楼的楼层和房间布局，哪个房间放什么由谁管理，那是JVM规范的事；JMM则更像这栋大楼里人与人之间传递纸条的规则。比如，谁写的字要贴到公告栏才算“公开”？别人什么时候必须去公告栏抄一遍而不是继续看自己手里的旧纸条？多个人改同一张海报时怎么保证同步？JMM讨论的是这种规则，而不是大楼到底有几层。

说到这，也可以理解为什么JSR-133（在Java 5中正式引入的JMM规范修订）这么重要。它重新梳理了volatile、synchronized、final的内存语义，让整个并发模型从过去“受硬件摆布”变得更加规范清晰。不只是面试，你日常写并发代码时真正依赖的，就是这套语义。

2. JMM到底在解决什么：缓存一致性、指令重排序和三大特性

2.1 一个能直接复现的可见性实验

先看一段很经典的代码，体会下“可见性”问题有多隐蔽。

java复制public class VisibilityDemo {

    private static boolean flag = true;

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            long count = 0;
            while (flag) {
                count++;
            }
            System.out.println("线程结束，count = " + count);
        });

        worker.start();
        Thread.sleep(1000);

        flag = false;
        System.out.println("主线程已将 flag 改为 false");
    }
}

如果你在普通笔记本电脑上直接跑，很多时候主线程改了flag之后，worker线程几秒钟都不退出，甚至永远不会退出。原因就是worker线程可能一直在自己的工作内存或者说CPU缓存里读取flag的旧值，没有及时看到主内存中flag的最新值。把flag用volatile修饰之后，main线程的修改会立即对其他线程可见，worker循环才能及时退出。

这个现象放到现代CPU上，本质是每个核心都有自己的缓存，线程被调度到不同核心时，读到的可能是缓存副本而不是最新主内存值。JMM中的“工作内存”就是对寄存器、缓存、写缓冲等等的抽象；主内存则是所有线程共享的物理内存的抽象。JMM要做的事情，就是把这种硬件层面的不可控差异，转换成可控的、符合语言规范的语义。

2.2 为什么需要禁止重排序

除了可见性，JMM还要面对重排序问题。现代编译器和CPU为了提升性能，可能不按程序代码的原始顺序执行指令，只要单线程语义不变就行，这个叫as-if-serial。比如：

java复制int a = 1;
int b = 2;
int c = a + b;

把第2行和第1行顺序换个位置，单线程下结果没有区别。但在多线程中，另一个线程可能正在观察a和b的赋值顺序。如果这个线程依赖“先看到a=1，再看到b=2”，那一旦a和b被重排序，外部看到的结果和预期就不一致。

JMM通过happens-before规则和内存屏障来约束重排序。编译器层面会做静态分析，能保守地保证某些类型的代码不会被重排；处理器层面则通过插入内存屏障指令来控制。对Java开发者来说，你不需要手写屏障，但你要知道关键字背后做了什么：volatile、synchronized、final都会在不同程度上禁止特定类型的重排序。

2.3 并发三大特性：各自靠什么机制保证

Java并发编程常说的原子性、可见性、有序性，放到JMM里都有对应机制：

面试时问到“三大特性分别靠什么保证”，不要只回答“volatile保证可见性和有序性，synchronized保证原子性”。更完整的说法是：JMM通过限制happens-before关系和特定屏障，给volatile和synchronized提供了可见性和有序性保证；而原子性主要是由锁、原子类或者CPU提供的比较并交换原语来保证。volatile不能保证i++这类复合操作的原子性，这正好引出后面要说的重点场景。

3. 主内存与工作内存的抽象模型：JMM描述并发起源的地方

3.1 主内存与工作内存的职责划分

JMM规定所有共享变量（实例字段、静态字段、数组元素，不包括局部变量与方法参数）都存储在主内存中。每个线程还有一个私有的工作内存，里面保存该线程使用到的变量的主内存副本拷贝。注意，不是每个线程都复制一份完整变量，而是该线程用到的部分变量的副本。

线程对变量的所有读写操作，都必须在工作内存中进行，不能直接读写主内存变量。不同线程之间也没法直接访问对方的工作内存，只能通过主内存来间接传递。这条规则是理解可见性的总纲。看到这里你应该明白，工作内存不是某个具体的缓存或寄存器，而是一个抽象概念，包括CPU缓存、写缓冲、寄存器，甚至编译器优化产生的临时状态。

如果一个变量在某个线程内根本没有被工作内存“缓存”，那它每次读值都从主内存拿吗？理论上可以，但现实中几乎不会这么干，性能太差。JMM允许JVM和硬件在遵守规则的前提下做各种优化，包括缓存变量副本。所以不加同步时，一个线程“看不到”另一个线程的修改，是很自然的事情。

3.2 八个基本操作：看着多，记一个模型就够了

为了描述主内存与工作内存之间的交互，JMM定义了八个原子操作：read（从主内存读取变量）、load（把读取到的变量载入工作内存）、use（工作内存中把变量值传给执行引擎）、assign（把执行引擎的值赋给工作内存中的变量）、store（把工作内存中的变量传到主内存）、write（把store传来的变量写入主内存中的变量）、lock（锁定主内存变量，其他线程无法访问）和unlock（解除锁定）。这些操作之间有一些规则，例如不允许read和load单独出现、不允许use和assign单独出现、线程assign之后必须经过store与write把变化同步回主内存等。

说实话，除非你去深入研究JMM规范原文，否则这些操作名不必死记。它们的作用就是告诉我们：线程每次使用共享变量前应该尽力获取最新值，每次修改共享变量后应该尽快同步回主内存。真正推动这个模型运转的，是volatile、synchronized这些关键字所附带的内存屏障与锁语义。

3.3 我处理过的一个“工作内存副本”误判案例

我以前帮同事排查过一个性能问题，现象是压测时某段统计代码偶尔少计数。代码大致长这样：

java复制if (service.getCount() == 0) {
    process();
}

service内部维护一个volatile的count，所以读取本身没问题。问题出在process方法里先修改了一个本地缓存结构，同时把service的某个boolean状态由true改成了false。另一个线程判断到状态变成false后去读count，读到的仍是旧值。原因是修改boolean状态和修改count对象内部字段之间没有建立happens-before关系，线程只保证看到boolean的新值，不保证看到count内部结构的新值。

解决方式不是简单给count加volatile，而是把整个状态切换动作放到synchronized块里，或者把count和状态封装成一个不可变对象后用volatile引用整体发布。这个经历让我意识到，工作内存的副本失效是按变量维度来的，不是一次“全量清空”。所以用锁同步时也不要理所当然认为所有共享变量都跟着最新了，只要没有happens-before边界的传递，某个变量仍可能读到旧值。

4. happens-before规则：面试官最爱问的那几行规则

4.1 happens-before八条规则一句话记忆法

JMM规定，如果操作A happens-before操作B，那么A的执行结果对B可见，并且A的执行顺序排在B之前。这个关系是JMM给程序员的“承诺”：你按这些规则写并发代码，就不用担心可见性和有序性问题。最重要的八条规则可以这样快速记忆：

不少面试题会隐含这规则。比如：“一个线程修改了普通变量，另一个线程通过volatile变量读取，能看见吗？”答案未必，要看两个线程之间是否形成了volatile规则加传递性链条。

4.2 从一段代码看happens-before的传递性

java复制class SyncDemo {

    private int value = 0;
    private boolean ready = false;

    public void writer() {
        value = 42;          // 1
        ready = true;        // 2
    }

    public void reader() {
        if (ready) {         // 3
            System.out.println(value);  // 4
        }
    }
}

如果writer线程和reader线程通过普通变量直接通信，reader可能看到ready为true时，value还是0。因为1和2之间没有happens-before关系，2和3之间也没有。但假如把ready换成volatile，写线程先写value再写ready，读线程先读ready再读value，此时：1 happens-before 2，2 happens-before 3（volatile规则），3 happens-before 4。基于传递性，1 happens-before 4，所以value=42一定能被看到。

这个例子就是面试常见题“volatile变量为什么能保证前面普通变量的写入可见”的底层答案。它不是让每个变量都变成volatile，而是因为在写volatile之前对普通变量的写入，通过程序顺序规则与volatile写形成了happens-before边界，再通过传递性作用于读线程。

4.3 happens-before与as-if-serial的区别和联系

happens-before主要是面向多线程的规则，判断两个操作之间有没有内存可见性保障。as-if-serial则是面向单线程的规则：不管怎么重排序，单线程程序执行结果不能被改变。JMM既允许编译器和处理器充分优化，又不让优化破坏程序员依赖的正确性，所以用happens-before来划定“哪些优化不能越过”。

通俗点说，as-if-serial保护的是“每个线程自己看到自己执行顺序没问题”，happens-before保护的是“线程之间需要看到彼此结果时不能乱”。两个概念经常在并发面试中一起出现，能讲清楚区别，基本能证明你对JMM的理解不是靠背出来的。

5. volatile：可见性与有序性归它管，原子性它真管不了

5.1 为什么volatile不满足原子性

volatile修饰的变量有三个性质：可见性、禁止重排序、不保证原子性。很多人在学过之后会对“不保证原子性”产生困惑：既然volatile能保证每次读到最新值，为什么多个线程同时i++还是结果不对？

看i++的本质，它不是一个原子操作，而是“读取变量值、加1、写回变量值”三步。两个线程都读取到i=1后，各自加1，再写回，最终i=2，丢了其中一次增加。volatile只保证读取时看到的是最新值，但无法把“读-改-写”这三步合并成一个不可分割的完整动作。所以对volatile变量执行自增操作，在并发下依然不安全。

正确的做法是用AtomicInteger或加锁。面试时能说出这和“volatile不能替代锁”的边界，往往比只背结论更有说服力。永远不要用volatile修饰计数器，这是最容易被拿来当反例的坑。

5.2 volatile的实现原理

volatile在底层靠内存屏障实现。写volatile变量时，JMM要求在写操作前后插入适当的StoreStore屏障和StoreLoad屏障，确保之前对普通变量的写入已经刷新到主内存，并且写volatile本身不会和后续操作重排。读volatile变量时，则插入LoadLoad屏障和LoadStore屏障，使后续读操作从主内存中重新获取而不是在自己的缓存里找旧数据。

从性能角度看，volatile不会像synchronized那样引起线程阻塞和上下文切换，比锁轻量。但它屏蔽了缓存和寄存器优化，并不是完全零成本。访问volatile变量的开销仍比普通变量高，高频热点路径上大量使用volatile时需要做压测验证。

体现到机制里，x86处理器上volatile写会在指令层面触发一次内存屏障效果，而ARM等弱内存模型架构需要更严格的屏障指令。这也是为什么JMM要在语言层面统一语义、不让程序员直接面对平台差异。

5.3 场景使用建议和反例

volatile真正的典型场景有两个。一个是状态标志位，比如前面的while(flag)循环，用它作为线程是否继续运行的开关。另一个是安全发布不可变对象，比如把一个对象引用声明成volatile，其他线程通过这个引用读到的对象内部字段，只要对象构造期间没有this逸出问题，就可以认为是完整发布的对象。

不适合volatile的场景也很多。除了刚才说的计数器，还有需要基于当前值做判断的复合操作，例如“check-then-act”：先判断某个volatile状态再执行动作，如果判断和动作之间状态被别的线程改了，就出问题。这类场景应该用锁或者原子类，而不是试图通过加更多的volatile来“救火”。

6. synchronized与final的JMM语义：锁和不可变对象的线程安全底层逻辑

6.1 synchronized的加锁前后内存语义

很多开发只知道synchronized能保证互斥，却说不清它和JMM的关系。从JMM角度看，synchronized基于锁机制实现了一种更强的一致性语义：加锁时，线程会清空工作内存中相关共享变量的副本，之后从主内存重新读取；解锁时，必须把工作内存中该线程修改过的共享变量刷新回主内存。也就是说，进入synchronized块之后读到的共享变量是相对新鲜的，退出之前对共享变量的修改会在其他线程拿到同一把锁后可见。

一个线程解锁之前写入的变量，对后来获取同一把锁的线程可见。这正是监视器锁规则。反过来说，如果两个线程不是用同一把锁，哪怕它们操作的是同一个类里的变量，也不存在这种内存保证。面试题经常用“A线程改完普通变量后，B线程加锁读，能看到吗”这样的变体来考察锁的范围，不要被绕进去：需要保证的是同一把锁、同一个临界区或者满足happens-before传递边界。

6.2 final字段安全发布的边界条件

final在JMM里不只是“赋值后不能改”，它还有一条隐藏保障：在构造函数中正确初始化final字段，并且避免在构造函数中把this引用逸出，那么其他线程看到该对象的引用时，无需同步也能保证看到final字段的初始化值。这一保障是通过在构造函数返回前插入内存屏障实现的，防止构造函数内对final字段的写入与对外发布对象引用的操作发生重排序。

这里有个非常关键的边界：不要在构造函数里启动新线程并把this传给新线程，也不要在构造函数里通过方法间接把this发布出去。一旦this逸出，别人可能在构造还没完成前就看到一个半初始化的对象，final的保证也就失效了。正确做法是在构造函数外发布“已经构造完成的对象”，比如静态工厂中先new对象再返回，或放入线程安全的容器中。

可以把final和不可变对象一起理解。String、Long、BigDecimal这些不可变类的线程安全，通常并不需要额外的synchronized。因为它们一旦被安全发布，内部所有关键字段都是final，不存在被修改的可能，也就不存在可见性竞争。但不要忘了，不可变对象的“引用”本身还是要安全发布的，比如通过volatile、静态常量或锁保护的集合来发布，否则别人可能因为引用拷贝问题看不到它。

7. 从DCL单例说起：一个把JMM所有概念串起来的例子

7.1 经典DCL为什么还会出问题

双重检查锁定（Double-Checked Locking，DCL）是面试中出现频率最高的Java并发案例。它的错误版本如下，使用synchronized和普通静态变量：

java复制public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {                    // 第一次检查
            synchronized (Singleton.class) {
                if (instance == null) {            // 第二次检查
                    instance = new Singleton();    // 问题可能出在这
                }
            }
        }
        return instance;
    }
}

这段代码看着逻辑完整：两次判空避免了重复创建，同步块保证了只有一个线程进入创建逻辑。问题出在instance = new Singleton()这一步。它不是在物理上不可能被拆散的过程，编译器和CPU可以把它看成三个步骤：分配内存、在内存上执行构造函数、把引用赋值给instance。如果重排序让第3步先于第2步执行，线程A执行完步骤1和步骤3时，另一个线程B恰好进入getInstance方法，第一次判空发现instance不等于null，直接返回。线程B拿到的instance引用的对象可能还没有执行构造函数，内部字段都还是默认值。真实项目中，这种bug会表现为对象偶尔返回null字段或抛出空指针，非常难排查。

当年很多Java版本的无volatileDCL代码能“神奇地工作”，是因为某些JVM或CPU架构不进行这类重排，或者概率太低。但在Java 5之后JMM明确了规则：这里必须让instance引用具备volatile的禁止重排序语义，才能保证对象初始化完成后再发布引用。

7.2 推荐写法与底层原因

最稳妥也是最容易解释的写法是给instance加volatile修饰：

java复制public class Singleton {

    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

加了volatile之后，instance的写操作不允许和new过程中的对象初始化步骤重排，因而其他线程不会读到“半初始化”的单例对象。同时，volatile也保证了写线程完成写后，其他线程能及时看到这个新引用。这是JMM中volatile规则和监视器锁规则结合后的结果。

如果你的项目没有历史包袱，我更推荐在枚举单例或静态内部类Holder上选择：

java复制public class Singleton {

    private Singleton() {}

    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

静态内部类的方式利用JVM的类初始化机制保证懒加载且线程安全，不用写synchronized或volatile，也不容易写错。枚举单例更简单，还天然防止反射和序列化破坏。作为面试回答，可以把DCL版本和静态内部类版本都讲一讲，能体现你在多种方案间做过权衡。真正的项目里，越简单的并发设计越好维护。

7.3 从DCL延伸出的“安全发布”思维

DCL单例本质是“发布一个对象引用”的过程。JMM中安全发布的常用方式包括：通过静态初始化保存对象引用、通过volatile或AtomicReference保存对象引用、通过被锁保护的字段保存、通过ConcurrentHashMap等并发容器保存。只要对象是安全发布的，普通字段的可见性也能得到保证；如果没有安全发布，就算对象内部都是final字段，也不一定能保证引用本身对其他线程可见。

我在技术评审中经常看到有人觉得自己把所有用到变量的地方都加volatile就能万无一失，结果代码变成一锅粥。真正安全的发布一定是结构性的：构造时不泄漏this，发布时确保引用通过volatile、静态初始化或锁保护。你可以把JMM理解成“为安全发布提供底层背书”的规则体系。

8. JMM高频考点自测与复习建议

8.1 高频题快问快答

这里整理一些常考题，方便你在简历上写了并发相关项目后自查。先看题，心里默答，再往下看答案。

第一题：“volatile能保证原子性吗？”答案是否定的。它保证可见性和有序性，但不能把读改写合并成一个原子操作。自增场景要用AtomicInteger或锁。

第二题：“synchronized锁的对象的什么状态和工作内存有什么关系？”进入锁时会把工作内存中共享变量失效并重新读取，释放锁时把修改刷新回主内存。这样才能让后获取锁的线程看到前一个线程的修改。

第三题：“重排序会导致哪些问题？”如果一个线程先写a再写flag，另一个线程先看flag再看a，在缺少限制的情况下可能读到flag已改但a没改的中间状态。volatile或锁可以在这种跨线程交互中建立happens-before边界。

第四题：“as-if-serial与happens-before的区别？”as-if-serial是单线程语义，重排序不能改变单线程结果；happens-before是多线程可见性/有序性的规则。

第五题：“final是不是绝对安全地保证并发可见？”final保证的是通过构造器正确完成初始化后的final字段的值，在对象安全发布后无需额外同步也能被看到。但如果构造期间this逸出，则可能被看到未初始化状态。

第六题：“你了解内存屏障有哪些类型吗？”常用的有LoadLoad、LoadStore、StoreStore、StoreLoad。volatile变量的读写会插入合适的屏障来阻止特定类型的重排。能把这个细节答出来，会让面试官觉得你对JMM不是停留在名字层面。

8.2 学习建议与后续切入点

如果你正在准备面试，不要把JMM当作孤立的知识点单独背。推荐的学习顺序是：先理解可见性、原子性、有序性这些基础概念，再学主内存与工作内存模型，接着啃happens-before规则，最后回到volatile和synchronized等关键字去验证这些规则。遇到不好理解的场景，就自己写段小代码去跑，例如一个普通变量在多线程下被修改后另一个线程迟迟看不见，或者用jstack看线程状态。实验产生的直觉往往比背讲义牢固得多。

学完JMM之后，完全可以继续把JUC包里的AQS、ConcurrentHashMap、ThreadLocal也串联进来。它们很多设计都是为了在JMM约束下达到更细粒度的并发控制。理解AQS中volatile状态变量的线程可见性、ConcurrentHashMap中Node数组用volatile维护弱一致性迭代，都和本文讲的模型直接相关。

我个人在这些年的排查经历中最深的体会是：并发bug的根源往往不是某一个代码片段写错了，而是缺少对happens-before边界的把握。某个变量从写入到被读取之间，到底有没有形成一条跨线程的可见性链路，把这条链路画清楚，很多棘手的问题都会自然消失。面试官追问JMM，本质上就是想看你有没有这种分析并发行为的能力，而不是让你表演记忆力。你能把这份对可见性和有序性的敏感带到实际编码中，才算真正看懂了Java内存模型。