为什么需要JMM

我就是我 2023-05-28 05:20 1阅读 0赞

Java语言在设计之初就引入了线程的概念，以充分利用现代处理器的计算能力，这既带来了强大、灵活的多线程机制，也带来了线程安全等令人混淆的问题，而Java内存模型（Java Memory Model，JMM）为我们提供了一个在纷乱之中达成一致的指导准则。

## 为什么需要JMM，它试图解决什么问题？ ##

Java是最早尝试提供内存模型的语言，这是简化多线程编程、保证程序可移植性的一个飞跃。早期类似C、C++等语言，并不存在内存模型的概念（C++11中也引入了标准内存模型），其行为依赖于处理器本身的内存一致性模型，但不同的处理器可能差异很大，所以一段C++程序在处理器A上运行正常，并不能保证其在处理器B上也是一致的。

即使如此，最初的Java语言规范仍然是存在着缺陷的，当时的目标是，希望Java程序可以充分利用现代硬件的计算能力，同时保持“书写一次，到处执行”的能力。但是，显然问题的复杂度被低估了，随着Java被运行在越来越多的平台上，人们发现，过于泛泛的内存模型定义，存在很多模棱两可之处，对synchronized或volatile等，类似指令重排序时的行为，并没有提供清晰规范。这里说的指令重排序，既可以是编译器优化行为，也可能是源自于现代处理器的乱序执行等。

换句话说：

*  既不能保证一些多线程程序的正确性，例如最著名的就是双检锁（Double-Checked Locking，DCL）的失效问题，双检锁可能导致未完整初始化的对象被访问，理论上这叫并发编程中的安全发布（Safe Publication）失败。
 *  也不能保证同一段程序在不同的处理器架构上表现一致，例如有的处理器支持缓存一致性，有的不支持，各自都有自己的内存排序模型。

所以，Java迫切需要一个完善的JMM，能够让普通Java开发者和编译器、JVM工程师，能够清晰地达成共识。换句话说，可以相对简单并准确地判断出，多线程程序什么样的执行序列是符合规范的。

Happen-before关系，是Java内存模型中保证多线程操作可见性的机制，也是对早期语言规范中含糊的可见性概念的一个精确定义。它的具体表现形式，包括但远不止是我们直觉中的synchronized、volatile、lock操作顺序等方面，例如：

*  线程内执行的每个操作，都保证happen-before后面的操作，这就保证了基本的程序顺序规则，这是开发者在书写程序时的基本约定。
 *  对于volatile变量，对它的写操作，保证happen-before在随后对该变量的读取操作。对于一个锁的解锁操作，保证happen-before加锁操作。
 *  对象构建完成，保证happen-before于finalizer的开始动作。
 *  甚至是类似线程内部操作的完成，保证happen-before其他Thread.join()的线程等。

这些happen-before关系是存在着传递性的，如果满足A happen-before B和B happen-before C，那么A happen-before C也成立。

对于编译器、JVM开发者，关注点可能是如何使用类似内存屏障（Memory-Barrier）之类技术，保证执行结果符合JMM的推断。对于Java应用开发者，则可能更加关注volatile、synchronized等语义，如何利用类似happen-before的规则，写出可靠的多线程应用，而不是利用一些“秘籍”去糊弄编译器、JVM。

我画了一个简单的角色层次图，不同工程师分工合作，其实所处的层面是有区别的。JMM为Java工程师隔离了不同处理器内存排序的区别，这也是为什么我通常不建议过早深入处理器体系结构，某种意义上来说，这样本就违背了JMM的初衷。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70]

JMM是怎么解决可见性等问题的呢？

在这里，有必要简要介绍一下典型的问题场景。JVM内部的运行时数据结构虽然划分得很清晰，但是真正程序执行，实际是要跑在具体的处理器内核上。你可以简单理解为，把本地变量等数据从内存加载到缓存、寄存器，然后运算结束写回主内存。注意线程读取数据的顺序优先级是：寄存器－高速缓存－内存。有些书例如《Java并发编程的艺术》里提到JVM线程拥有本地内存，本地内存中存储了主内存中共享变量的副本，这里的“本地内存”其实自己造出来的抽象概念，并不是真实存在的，涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

你可以从下面示意图，看到这两种模型的对应。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 1]

看上去很美好，但是当多线程共享变量时，情况就复杂了。试想，如果处理器对某个共享变量进行了修改，可能只是体现在该内核的缓存里，这是个本地状态，而运行在其他内核上的线程，可能还是加载的旧状态，这很可能导致一致性的问题。这就是《Java并发编程的艺术》里提到的线程本地内存中共享变量值刷新了，如何让其他线程知晓的问题）。从理论上来说，多线程共享引入了复杂的数据依赖性，不管编译器、处理器怎么做重排序，都必须尊重数据依赖性的要求，否则就打破了正确性！这就是JMM所要解决的问题。

JMM内部的实现通常是依赖于所谓的**内存屏障**，通过禁止某些重排序的方式，提供内存可见性保证，也就是实现了各种happen-before规则。与此同时，更多复杂度在于，需要尽量确保各种编译器、各种体系结构的处理器，都能够提供一致的行为。

对于一个volatile变量：

*  对该变量的写操作之后，编译器会插入一个写屏障。
 *  对该变量的读操作之前，编译器会插入一个读屏障。

内存屏障能够在类似变量读、写操作之后，保证其他线程对volatile变量的修改对当前线程可见，或者本地修改对其他线程提供可见性。换句话说，某个线程写volatile变量之后，写屏障会通过类似强迫刷出处理器缓存的方式，让其他线程能够拿到最新数值。

从应用开发者的角度，JMM提供的可见性，体现在类似volatile上，具体行为是什么样呢？我想举Brian Goetz提供的一个经典用例，使用volatile作为守卫对象，实现某种程度上轻量级的同步，请看代码片段：

Map configOptions;
    char[] configText;
    volatile boolean initialized = false;
     
    // Thread A
    configOptions = new HashMap();
    configText = readConfigFile(fileName);
    processConfigOptions(configText, configOptions);
    initialized = true;
     
    // Thread B
    while (!initialized)
      sleep();
    // use configOptions

JSR-133重新定义的JMM模型，能够保证线程B获取的configOptions是更新后的数值。也就是说volatile变量的可见性发生了增强，能够起到守护其上下文的作用。线程A对volatile变量的赋值，会强制将该变量自己和当时其他变量的状态都刷出缓存，为线程B提供可见性。当然，这也是以一定的性能开销作为代价的，但毕竟带来了更加简单的多线程行为。

我们经常会说volatile比synchronized之类更加轻量，但轻量也仅仅是相对的，volatile的读、写仍然要比普通的读写要开销更大，所以如果你是在性能高度敏感的场景，除非你确定需要它的语义，不然慎用。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70]: /images/20230528/da89cb202c804db69db51d676c00c458.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/acf2bd64e74b452983cc894f95a09a7e.png