《Java并发编程的艺术》第三章节Java内存模型

Ethan Yankang

已于 2024-09-28 21:25:49 修改

阅读量1.1k

点赞数 30

文章标签： java 开发语言

于 2024-09-17 23:30:10 首次发布

本文链接：https://blog.csdn.net/m0_68657832/article/details/142319937

版权

🌈hello，你好鸭，我是Ethan，西安电子科技大学大三在读，很高兴你能来阅读。

✔️目前博客主要更新Java系列、项目案例、计算机必学四件套等。
🏃人生之义，在于追求，不在成败，勤通大道。加油呀！

🔥个人主页：Ethan Yankang
🔥推荐：史上最强八股文||一分钟看完我的几百篇博客

🔥温馨提示：划到文末发现专栏彩蛋点击这里直接传送

🔥本篇概览：详细讲解了《Java并发编程的艺术》第三章节——JMM,定义了 Java 虚拟机（JVM）在多线程环境下如何处理内存可见性、原子性和有序性等问题。🌈⭕🔥

【计算机领域一切迷惑的源头都是基本概念的模糊，算法除外】

👉Java并发编程专栏

🌈章节速览：

JMM定义：定义了 Java 虚拟机（JVM）在多线程环境下如何处理内存可见性、原子性和有序性等问题。

Java线程之间的通信[计算机三大块之一]对程序员完全透明（不可见的，自动完成的），内存可见性问题很容易困扰Java程序员。本章揭开Java内存模型的神秘面纱。

主要分为四大部分：

1.基本概念

1.1并发编程的两个关键问题

在并发编程中，需要处理两个关键问题:线程之间如何通信及线程之间如何同步。

1.1.1.线程之间如何通信：

通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种:共享内存和消息传递。

在共享内存的并发模型里，线程之间共享程序的公共状态，通过写-读内存中的公共状态进行隐式通信。

在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过发发送消息来显式进行通信。

1.1.2.线程之间如何同步：

同步是指程序中用于控制不同线程间操作发生的相对顺序的机制。

在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。

显式同步代表语言：Java

Java 的并发采用的是共享内存模型，Java线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的Java 程序员不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。

隐式同步代表语言：Erlang、Go

Erlang 语言中，进程之间完全独立，通过发送和接收消息进行通信。每个进程都有自己的内存空间，不存在共享内存的情况，这使得并发编程更加安全和可靠。

Go 语言中的 goroutine（轻量级线程）之间主要通过 channels（通道）进行通信。一个 goroutine 可以向通道发送数据，另一个 goroutine 可以从通道接收数据，实现了类似消息传递的机制。

1.2Java内存模型的抽象结构

在Java中，所有实例域、静态域和数组元素都存储在堆内存中，堆内存在线程之间共享(本章用“共享变量”这个术语代指实例域，静态域和数组元素)。局部变量，方法定义参数和异常处理器参数不会在线程之间共享它们不会有内存可见性问题，也不受内存模型的影响。

Java线程之间的通信由 Java内存模型控制，JMM 决定一个线程对共享变量的写入何时对另一个线程可见【这就是线程之间的通信】。

从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系:线程之间的共享变量存储在主内存(MainMemory)中，每个线程都有一个私有的本地内存(LocalMemory)，本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。Java内存模型的抽象示意如图所示：

由上图：A、B线程要通信的话必须经历以下两个步骤：

1) 线程A把本地内存A中更新过的共享变量刷新到主内存中去。
2) 线程B到主内存中去读取线程A之前已更新过的共享变量。

【即主内存作为中介！这样就能实现线程B获取到线程A发送的消息，这就是线程之间完成的通信】

从整体来看，上诉1、2这两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互，来为Java程序员提供内存可见性保证。

1.3从源代码到指令序列的重排序

在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。

重排序分3种类型：

1)编译器优化的重排序。

编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。

2)指令级并行的重排序。

现代处理器采用了指令级并行技术(流水线)(Instruction-LevelParallelism，IP)来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。

3)内存系统的重排序。

由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从Java源代码到最终实际执行的指令序列，会分别经历下面3种重排序，如图所示:

【太牛逼了，讲得很清楚】

上述的1 属于编译器重排序， 2 和 3 属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。

对于编译器， JMM的编译器重排序规则会禁止特定类型的编译器重排序 （不是所有的编译器重排序都要禁止）。

对于处理器重排序， JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障指令，通过内存屏障指令来禁止特定类型的处理器重排序。

1.4不同的处理器的重排序规则

现代的处理器使用写缓冲区临时保存向内存写入的数据 。写缓冲区可以保证指令流水线

持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以

批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，减少对内存总

线的占用。 虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器

可见。这个特性会对内存操作的执行顺序产生重要的影响 ：处理器对内存的读 / 写操作的执行

顺序，不一定与内存实际发生的读 / 写操作顺序一致！

下面两个处理器的代码处理过程，按理说应该是x=2，y=1。但是会有可能的得到x=y=0的结果。

原因分析如下:

【处理器和内存的交互】

这里处理器 A 和处理器 B 可以同时把共享变量写入自己的写缓冲区（ A1，B1 ），然后从内存

中读取另一个共享变量（ A2，B2 ），最后才把自己写缓存区中保存的脏数据刷新到内存中（ A3，

B3 ）。当以这种时序执行时，程序就可以得到 x=y=0 的结果。

从内存操作实际发生的顺序来看，直到处理器A执行A3来刷新自己的写缓存区，写操作 A1才算真正执行了。虽然处理器A执行内存操作的顺序为：A1→A2，但内存操作实际发生的顺序却是A2→A1。此时，处理器A的内存操作顺序被重排序了（处理器B的情况和处理器A一样，这里就不赘述了）。

这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。由于现代的处理器都会使用写缓冲区，因此现代的处理器都会允许对写-读操作进行重排序。

【处理器的重排序规则】

从上面我们可以看出，常见的处理器都允许 Store-Load 重排序；常见的处理器都 不允许对存在数据依赖的操作做重排序。 sparc-TSO 和 X86 拥有相对较强的处理器内存模型，它们仅允许对 写-读操作 做重排序（因为它们都使用了写缓冲区）。

1.5JMM的内存屏障分类

为了保证内存可见性，Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁

止特定类型的处理器重排序。 JMM把内存屏障指令分为4类 ：

StoreLoad Barriers是一个“全能型”的屏障，它同时具有其他3个屏障的效果。现代的多处理器大多支持该屏障(其他类型的屏障不一定被所有处理器支持)。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中。

1.6happen-before简介

以下均使用JSR-133内存模型讲解！

JSR-133（Java Memory Model and Thread Specification Revision）即 Java 内存模型和线程规范修订。

1.6.1happen-before作用与意义：

JSR-133使用happens-before的概念来阐述操作之间的内存可见性。在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。

1.6.2happen-before四条规则

与程序员密切相关的happens-before规则如下。：

·程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。

·监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。

·volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。

·传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。

1.6.3happen-before规则的本质

两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）。
happens-before的定义很微妙，后文会具体说明happens-before为什么要这么定义。

JVM 使用happens-before的概念来阐述操作之间的内存可见性 :

【happens-before与JMM的关系】

如图所示，一个happens-before规则对应于一个或多个编译器和处理器重排序规则。对于Java程序员来说，happens-before规则简单易懂，它避免Java程序员为了理解JMM提供的内存
可见性保证而去学习复杂的重排序规则以及这些规则的具体实现方法。

2.重排序

定义：重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段。

2.1数据依赖性

定义：如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。

数据依赖分为下列3种类型[规定了要有一个写操作嘛,就去除掉一个`读读`]：

上面三种情况，只要重排序两个操作的执行顺序，程序的执行结果就会被改变。

前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑【这也是导致并发安全的祸根！】

2.2as-if-serial语义

2.2.1定义：

不管怎么重排序（编译器和处理器为了提高并行度）,（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

2.2.2as-if-serial语义与数据依赖性的关系：

一句话：as-if-serial是原则，该原则则依赖于数据依赖关系的正确处理，而数据关系决定了编译期与CPU是否可以重排序。

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因
为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被
编译器和处理器重排序。

例子：

数据依赖性关系：

AB之间没有数据依赖关系可以重排序，C与A\B之间存在数据依赖关系不能重排序，所以会出现以下重排序优化：

【程序的两种执行顺序】

2.2.3as-if-serial语义的意义

as-if-serial语义把单线程程序保护了起来，遵守as-if-serial语义的编译器、runtime和处理器
共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

2.2.4 程序顺序规则

根据happens-before的程序顺序规则，上面计算圆的面积的示例代码存在3个happensbefore关系。

1）A happens-before B。

2）B happens-before C。

3）A happens-before C。

这里的第3个happens-before关系，是根据happens-before的传递性推导出来的。

在计算机中，软件技术和硬件技术有一个共同的目标：在不改变程序执行结果的前提下，
尽可能提高并行度。编译器和处理器遵从这一目标，从happens-before的定义我们可以看出，
JMM同样遵从这一目标。

2.2.5 重排序对多线程的影响

重排序会改变多线程程序的结果，如下程序：

class ReorderExample {
    int a = 0;
    boolean flag = false;

    public void writer() {
        a = 1; // 1
        flag = true; // 2
    }

    public void reader() {
        if (f ? lag) { // 3
            int i = a * a; // 4
//……
        }
    }
}

【经典程序，标记写入法+控制依赖性】

flag变量是个标记，用来标识变量a是否已被写入。这里假设有两个线程A和B，A首先执行
writer()方法，随后B线程接着执行reader()方法。线程B在执行操作4时，能否看到线程A在操作
1对共享变量a的写入呢？

· 答案是:不一定能看到。
由于操作1和操作2没有数据依赖关系,编译器和处理器可以对这两个操作重排序:同样操作3和操作4没有数据依赖关系,编译器和处理器也可以对这两个操作重排序。让我们先来看看，当操作1和操作2重排序时,可能会产生什么效果?请看下面的程序执行时序图,如图所示：

注意本文统一用虚箭线标识错误的读操作，用实箭线标识正确的读操作。

操作1和操作2做了重排序。程序执行时，线程A首先写标记变量flag，随后线程B读这个变量。由于条件判断为真，线程B将读取变量a。此时，变量a还没有被线程A写入，在这里多线程程序的语义被重排序破坏了！

下面再让我们看看，当操作3和操作4重排序时会产生什么效果:【借助此例可以很好的说明控制依赖性】

2.3 控制依赖性

操作3和操作4存在控制依赖关系。当代码中存在控制依赖性时，会影响指令序列执行的并行度。为此，编译器和处理器会采用猜测（Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程B的处理器可以提前读取并计算a*a，然后把计算结果临时保存到一个名为重排序缓冲（Reorder Buffer，ROB）的硬件缓存中。当操作3的条件判断为真时，就把该计算结果写入变量i中。

在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是as-if-serial 语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。

3顺序一致性

定义：

顺序一致性内存模型是一个理论参考模型，在设计的时候，处理器的内存模型和编程语言的内存模型都会以顺序一致性内存模型作为参照。【Unsafe类底层也讲到了】。

3.1 数据竞争与顺序一致性

3.1.1数据竞争定义

当程序未正确同步时，就可能会存在数据竞争。Java内存模型规范对数据竞争的定义如下:

[原来这些都是有定义的！！真好]

在一个线程中写一个变量，
在另一个线程读同一个变量，
而且写和读没有通过同步来排序。

当代码中包含数据竞争时，程序的执行往往产生违反直觉的结果（前一章的示例正是如此）。如果一个多线程程序能正确同步，这个程序将是一个没有数据竞争的程序。

3.1.2JMM对正确同步的多线程程序的保证：

JMM对正确同步的多线程程序的内存一致性做了如下保证。

如果程序是正确同步的，程序的执行将具有顺序一致性——即程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同。马上我们就会看到，这对于程序员来说是一个极强的保证。这里的同步是指广义上的同步，包括对常用同步原语（synchronized、volatile和final）的正确使用。

🔥3.2 顺序一致性内存模型

顺序一致性内存模型是一个被计算机科学家理想化了的理论参考模型，它为程序员提供了极强的内存可见性保证。

顺序一致性内存模型有两大特性【！！！很重要，直接将线程并发安全的三大点全部堵死了！Java并发编程的三大特性：原子性、可见性、有序性】：

1）一个线程中的所有操作必须按照程序的顺序来执行。

2）（不管程序是否同步）所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。

顺序一致性内存模型为程序员提供的视图如图3-10所示。

【顺序一致性内存模型的视图】

在概念上，顺序一致性模型有一个单一的全局内存，这个内存通过一个左右摆动的开关可以连接到任意一个线程，同时每一个线程必须按照程序的顺序来执行内存读/写操作。从上面的示意图可以看出，在任意时间点最多只能有一个线程可以连接到内存。当多个线程并发执行时，图中的开关装置能把所有线程的所有内存读/写操作串行化（即在顺序一致性模型中，所有操作之间具有全序关系）。

3.2.1顺序一致性在同步于非同步之间的差异

为了更好进行理解，下面通过两个示意图来对顺序一致性模型的特性做进一步的说明。假设有两个线程A和B并发执行。其中A线程有3个操作，它们在程序中的顺序是： A1→A2→A3。B线程也有3个操作，它们在程序中的顺序是：B1→B2→B3。 假设这两个线程使用监视器锁来正确同步：A线程的3个操作执行后释放监视器锁，随后B 线程获取同一个监视器锁。那么程序在顺序一致性模型中的执行效果将如图3-11所示。

【顺序一致性模型的一种执行效果,使用监视器锁来同步的】

现在我们再假设这两个线程没有做同步，下面是这个未同步程序在顺序一致性模型中的执行示意图，如图所示:

未同步程序在顺序一致性模型中虽然整体执行顺序是无序的，但所有线程都只能看到一个一致的整体执行顺序。以上图为例，线程A和B看到的执行顺序都是： B1→A1→A2→B2→A3→B3。之所以能得到这个保证是因为顺序一致性内存模型中的每个操作必须立即对任意线程可见。[三大点，提供的原子性、可见性(但这里的有序性不提供)]。

3.2.2Java内存模型的不一致性

但是，在JMM中就没有这个保证[这才是重点！！]。未同步程序在JMM中不但整体的执行顺序是无序的，而且所有线程看到的操作执行顺序也可能不一致。比如，在当前线程把写过的数据缓存在本地内存中，在没有刷新到主内存之前，这个写操作仅对当前线程可见；从其他线程的角度来观察，会认为这个写操作根本没有被当前线程执行。只有当前线程把本地内存中写过的数据刷新到主内存之后，这个写操作才能对其他线程可见。在这种情况下，当前线程和其他线程看到的操作执行顺序将不一致。

3.2.3 同步程序的顺序一致性效果

对前面的示例程序ReorderExample用锁来同步，看看正确同步的程序如何具有顺序一致性。

class SynchronizedExample {
    int a = 0;
    boolean flag = false;
    public synchronized void writer() { // 获取锁
        a = 1;
        flag = true;
    } // 释放锁
    public synchronized void reader() { // 获取锁
        if (flag) {
            int i = a;
//……
        } // 释放锁
    }
}

在上面示例代码中，假设A线程执行writer()方法后，B线程执行reader()方法。这是一个正确同步的多线程程序。根据JMM规范，该程序的执行结果将与该程序在顺序一致性模型中的执行结果相同[但在临界区内依然可以重排序！]。下面是该程序在两个内存模型中的执行时序对比图，如图3-13所示。

【两个内存模型中的执行时序对比图】

从这里我们可以看到，JMM在具体实现上的基本方针为：在不改变（正确同步的）程序执行结果的前提下，尽可能地为编译器和处理器的优化打开方便之门。

3.2.4 未同步程序的执行特性与在两个模型中特点

对于未同步或未正确同步的多线程程序，JMM只提供最小安全性：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0，Null，False），JMM保证线程读操作读取到的值不会无中生有的冒出来。

为了实现最小安全性，JVM在堆上分配对象时，首先会对内存空间进行清零，然后才会在上面分配对象（JVM内部会同步这两个操作）。因此，在已清零的内存空间（Pre-zeroed Memory）分配对象时，域的默认初始化已经完成了

未同步程序在JMM中的执行时，整体上是无序的，其执行结果无法预知。未同步程序在两个模型中的执行特性有如下几个差异：

1）顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序的顺序执行（比如上面正确同步的多线程程序在临界区内的重排序）。

2）顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的操作执行顺序。

3）JMM不保证对64位的long型和double型变量的写操作具有原子性，而顺序一致性模型保证对所有的内存读/写操作都具有原子性。

第3个差异与处理器总线的工作机制密切相关。在计算机中，数据通过总线在处理器和内存之间传递。每次处理器和内存之间的数据传递都是通过一系列步骤来完成的，这一系列步骤称之为总线事务（Bus Transaction）。总线事务包括读事务（Read Transaction）和写事务（Write Transaction）。读事务从内存传送数据到处理器，写事务从处理器传送数据到内存，每个事务会读/写内存中一个或多个物理上连续的字。这里的关键是，总线会同步试图并发使用总线的事务。在一个处理器执行总线事务期间，总线会禁止其他的处理器和I/O设备执行内存的读/写。

【总线的工作机制】

由图可知，假设处理器A，B和C同时向总线发起总线事务，这时总线仲裁（Bus Arbitration）会对竞争做出裁决，这里假设总线在仲裁后判定处理器A在竞争中获胜（总线仲裁会确保所有处理器都能公平的访问内存）。此时处理器A继续它的总线事务，而其他两个处理器则要等待处理器A的总线事务完成后才能再次执行内存访问。假设在处理器A执行总线事务期间（不管这个总线事务是读事务还是写事务），处理器D向总线发起了总线事务，此时处理器D的请求会被总线禁止。总线的这些工作机制可以把所有处理器对内存的访问以串行化的方式来执行。在任意时间点，最多只能有一个处理器可以访问内存。这个特性确保了单个总线事务之中的内存读/写操作具有原子性。

4.内存语义

4.1volatile的内存语义

当声明共享变量为volatile后，对这个变量的读/写将会很特别。为了揭开volatile的神秘面纱，下面将介绍volatile的内存语义及volatile内存语义的实现。

4.1.1 volatile的特性

理解volatile特性的一个好方法是`把对volatile变量的单个读/写，看成是使用同一个锁对这些单个读/写操作做了同步【说明volatile内部不是锁，而是内存屏障】`。

示例代码说明volatile语义：

class VolatileFeaturesExample {
    volatile long vl = 0L; // 使用volatile声明64位的long型变量
    public void set(long l) {
        vl = l; // 单个volatile变量的写
    }
    public void getAndIncrement () {
        vl++; // 复合（多个）volatile变量的读/写
    }
    public long get() {
        return vl; // 单个volatile变量的读
    }
}

假如多线程来调用上面的三个方法，等价于下面的代码：

{注意中间的复合变量的读写转化}

class VolatileFeaturesExample {
    long vl = 0L; // 64位的long型普通变量
    public synchronized void set(long l) { // 对单个的普通变量的写用同一个锁同步
        vl = l;
    }
    public void getAndIncrement () { // 普通方法调用
        long temp = get(); // 调用已同步的读方法
        temp += 1L; // 普通写操作
        set(temp); // 调用已同步的写方法
    }
    public synchronized long get() { // 对单个的普通变量的读用同一个锁同步
        return vl;
    }
}

【与volatile等价的synchronized程序】

如上面示例程序所示，一个volatile变量的单个读/写操作，与一个普通变量的读/写操作都是使用同一个锁来同步，它们之间的执行效果相同。

而锁的happens-before规则保证释放锁和获取锁的两个线程之间的内存可见性【层层交织的】，这意味着对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。【这里就是核心了】

锁的语义决定了临界区代码的执行具有原子性。这意味着，只要它是volatile变量，对该变量的读/写就具有原子性。如果是多个volatile操作或类似于volatile++这种复合操作，这些操作整体上不具有原子性。

简而言之，volatile变量自身具有下列特性。

🔥·可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。

🔥 ·原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

4.1.2 volatile写-读建立的happens-before关系

上面讲的是volatile变量自身的特性，对程序员来说，volatile对线程的内存可见性的影响比volatile自身的特性更为重要[原来如此]，也更需要我们去关注。

从JSR-133开始（即从JDK5开始），volatile变量的写-读可以实现线程之间的通信。

从内存语义的角度来说，volatile的写-读与锁的释放-获取有相同的内存效果：volatile写和锁的释放有相同的内存语义；volatile读与锁的获取有相同的内存语义。请看下面使用volatile变量的示例代码:

class VolatileExample {
    int a = 0;
    volatile boolean flag = false;
    public void writer() {
        a = 1; // 1
        flag = true; // 2
    }
    public void reader() {
        if (flag) { // 3
            int i = a; // 4
//……
        }
    }
}

假设线程A执行writer()方法之后，线程B执行reader()方法。根据happens-before规则，这个过程建立的happens-before关系可以分为3类：

1）根据程序次序规则，1 happens-before 2;3 happens-before 4。

2）根据volatile规则[第一条：任意读在任意写之后可见]，2 happens-before 3。

3）根据happens-before的传递性规则，1 happens-before 4。

上述happens-before关系的图形化表现形式如下。

这里A线程写一个volatile变量后，B线程读同一个volatile变量。A线程在写volatile变量之前所有可见的共享变量，在B线程读同一个volatile变量后，将立即变得对B线程可见。

4.1.3volatile写-读的内存语义

4.1.3.1volatile写的内存语义

volatile写的内存语义如下:

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存(牛逼，简洁明了！)。以上面示例程序VolatileExample为例，假设线程A首先执行writer()方法，随后线程B执行 reader()方法，初始时两个线程的本地内存中的flag和a都是初始状态。图3-17是线程A执行 volatile写后，共享变量的状态示意图：

【共享变量的状态示意图】

如上图所示，线程A在写flag变量后，本地内存A中被线程A更新过的两个共享变量的值被刷新到主内存中。此时，本地内存A和主内存中的共享变量的值是一致的。

4.1.3.2volatile读的内存语义

volatile读的内存语义如下。 当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。

图3-18为线程B读同一个volatile变量后，共享变量的状态示意图。如图所示，在读flag变量后，本地内存B包含的值已经被置为无效。此时，线程B必须从主内存中读取共享变量。线程B的读取操作将导致本地内存B与主内存中的共享变量的值变成一致。如果我们把volatile写和volatile读两个步骤综合起来看的话，在读线程B读一个volatile变量后，写线程A在写这个volatile变量之前所有可见的共享变量的值都将立即变得对读线程B可见

下面对volatile写和volatile读的内存语义做个总结。

4.1.4从线程通信的角度来看volatile语义：

·线程A写一个volatile变量，实质上是线程A向接下来将要读这个volatile变量的某个线程发出了（其对共享变量所做修改的）消息。

·线程B读一个volatile变量，实质上是线程B接收了之前某个线程发出的（在写这个volatile 变量之前对共享变量所做修改的）消息。

·线程A写一个volatile变量，随后线程B读这个volatile变量，这个过程实质上是线程A通过主内存向线程B发送消息。

【共享变量的状态示意图】

4.2volatile的内存语义的实现——JMM禁止重排序

下面来看看JMM如何实现volatile写/读的内存语义。——限制指令重排序。

前文提到过重排序分为编译器重排序和处理器重排序。为了实现volatile内存语义，JMM 会分别限制这两种类型的重排序类型。表3-5是JMM针对编译器制定的volatile重排序规则表。

具体重排序规则如下：

·当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保 volatile写之前的操作不会被编译器重排序到volatile写之后。

·当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保 volatile读之后的操作不会被编译器重排序到volatile读之前。

·当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障[特定指令序列]来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能。为此，JMM采取保守策略。下面是基于保守策略的JMM内存屏障插入策略。

·在每个volatile写操作的前面插入一个StoreStore屏障。

·在每个volatile写操作的后面插入一个StoreLoad屏障。

·在每个volatile读操作的后面插入一个LoadLoad屏障。[注意这里两个都是后面]

·在每个volatile读操作的后面插入一个LoadStore屏障。

上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的volatile内存语义。

下面是保守策略下，volatile写插入内存屏障后生成的指令序列示意图，如图3-19所示。

图3-19中的StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作已经对任意处理器可见了。

下面是在保守策略下，volatile读插入内存屏障后生成的指令序列示意图，如图3-20所示.

上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不改变 volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。下面通过具体的示例代码进行说明。

class VolatileBarrierExample {
    int a;
    volatile int v1 = 1;
    volatile int v2 = 2;
    void readAndWrite() {
        int i = v1; // 第一个volatile读
        int j = v2; // 第二个volatile读
        a = i + j; // 普通写
        v1 = i + 1; // 第一个volatile写
        v2 = j * 2; // 第二个 volatile写
    }
//… // 其他方法
}

针对readAndWrite()方法，编译器在生成字节码时可以做如下的优化。

【指令序列示意图】

4.2.1不同处理器的处理优化不同

前面保守策略下的volatile读和写，在X86处理器平台可以优化成如图3-22所示。前文提到过，X86处理器仅会对写-读操作做重排序。

X86不会对读-读、读-写和写-写操作做重排序，因此在X86处理器中会省略掉这3种操作类型对应的内存屏障。

在X86中，JMM仅需在volatile写后面插入一个StoreLoad屏障即可正确实现volatile写-读的内存语义。这意味着在 X86处理器中，volatile写的开销比volatile读的开销会大很多（因为执行StoreLoad屏障开销会比较大）。

4.3锁(synchronized)的内存语义

4.3.1引出：从volatile到锁(synchronized)

由于volatile仅仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。在功能上，锁比volatile更强大；在可伸缩性和执行性能上，volatile更有优势。如果读者想在程序中用volatile代替锁，请一定谨慎，具体详情请参阅Brian Goetz的文章《Java理论与实践：正确使用Volatile变量》。

4.3.2锁的内存语义

众所周知，锁可以让临界区互斥执行。这里将介绍锁的另一个同样重要，但常常被忽视的功能：锁的内存语义。

4.3.3锁的释放-获取建立的happens-before关系(通信关系！！)

锁是Java并发编程中最重要的同步机制。锁除了让临界区互斥执行外，还可以让释放锁的线程向获取同一个锁的线程发送消息。 下面是锁释放-获取的示例代码：

class MonitorExample {
    int a = 0;
    public synchronized void writer() { // 1
        a++; // 2
    } // 3
    public synchronized void reader() { // 4
        int i = a; // 5
//……
    } // 6
}

假设线程A执行writer()方法，随后线程B执行reader()方法。根据happens-before规则，这个过程包含的happens-before关系可以分为3类：

1）根据程序次序规则，1 happens-before 2,2 happens-before 3;4 happens-before 5,5 happens before 6。

2）根据监视器锁规则，3 happens-before 4。

3）根据happens-before的传递性，2 happens-before 5。

【happens-before关系图】

上图表示在线程A释放了锁之后，随后线程B获取同一个锁。在上图中，2 happens-before 5。因此，线程A在释放锁之前所有可见的共享变量，在线程B获取同一个锁之后，将立刻变得对B线程可见。

4.3.4锁的释放和获取的内存语义

4.3.4.1释放锁的内存语义

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中(和volatile一样(应该是volatile和他一样！))。以上面的MonitorExample程序为例，A线程释放锁后，共享数据的状态示意图如图所示。

【共享数据的状态示意图】

4.3.4.2释放锁的内存语义

当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须从主内存中读取共享变量。图示是锁获取的状态示意图：

【锁获取的状态示意图】

对比锁释放-获取的内存语义与volatile写-读的内存语义可以看出：锁释放与volatile写有相同的内存语义；锁获取与volatile读有相同的内存语义。

下面对锁释放和锁获取的内存语义做个总结：

·线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A 对共享变量所做修改的）消息。

·线程B获取一个锁，实质上是线程B接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。

4.3.5 锁内存语义的实现

下面借助ReentrantLock的源代码，来分析锁内存语义的具体实现机制：

class ReentrantLockExample {
    int a = 0;
    ReentrantLock lock = new ReentrantLock();

    public void writer() {
        lock.lock(); // 获取锁 
        try {
            a++;
        } finally {
            lock.unlock(); // 释放锁
        }
    }

    public void reader() {
        lock.lock(); // 获取锁 
        try {
            int i = a; 
            //……
        } finally {
            lock.unlock(); // 释放锁 
        }
    }
}

在ReentrantLock中，调用lock()方法获取锁；调用unlock()方法释放锁。

ReentrantLock的实现依赖于Java同步器框架AbstractQueuedSynchronizer（本文简称之为 AQS）。AQS使用一个整型的volatile变量（命名为state）来维护同步状态，这个volatile变量是ReentrantLock内存语义实现的关键。

4.3.5.1公平锁

ReentrantLock的类图

【ReentrantLock的类图】

ReentrantLock分为公平锁和非公平锁，我们首先分析公平锁。

使用公平锁时，加锁方法lock()调用轨迹如下。

1）ReentrantLock:lock()。

2）FairSync:lock()。

3）AbstractQueuedSynchronizer:acquire(int arg)。

4）ReentrantLock:tryAcquire(int acquires)。

在第4步真正开始加锁，下面是该方法的源代码。

protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState(); // 获取锁的开始，首先读volatile变量state
    if (c == 0) {
        if (isFirst(current) &&
                compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

从上面源代码中我们可以看出，加锁方法首先读volatile变量state。在使用公平锁时，解锁方法unlock()调用轨迹如下。

1）ReentrantLock:unlock()。

2）AbstractQueuedSynchronizer:release(int arg)。

3）Sync:tryRelease(int releases)。

在第3步真正开始释放锁，下面是该方法的源代码。

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread()) 
throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c); // 释放锁的最后，写volatile变量state 
    return free; 
}

从上面的源代码可以看出，在释放锁的最后写volatile变量state。

公平锁在释放锁的最后写volatile变量state，在获取锁时首先读这个volatile变量。根据 volatile的happens-before规则，释放锁的线程在写volatile变量之前可见的共享变量，在获取锁的线程读取同一个volatile变量后将立即变得对获取锁的线程可见。

4.3.5.2公平锁

现在我们来分析非公平锁的内存语义的实现。非公平锁的释放和公平锁完全一样，所以这里仅仅分析非公平锁的获取。使用非公平锁时，加锁方法lock()调用轨迹如下。

1）ReentrantLock:lock()。

2）NonfairSync:lock()。

3）AbstractQueuedSynchronizer:compareAndSetState(int expect,int update)。

在第3步真正开始加锁，下面是该方法的源代码。

protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

该方法以原子操作的方式更新state变量，本文把Java的compareAndSet()方法调用简称为 CAS。JDK文档对该方法的说明如下：

如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。CAS操作具有volatile读和写的内存语义。 这里我们分别从编译器和处理器的角度来分析，CAS如何同时具有volatile读和volatile写的内存语义。前文我们提到过，编译器不会对volatile读与volatile读后面的任意内存操作重排序；编译器不会对volatile写与volatile写前面的任意内存操作重排序。组合这两个条件，意味着为了同时实现volatile读和volatile写的内存语义，编译器不能对CAS与CAS前面和后面的任意内存操作重排序。

下面我们来分析在常见的intel X86处理器中，CAS是如何同时具有volatile读和volatile写的内存语义的。下面是sun.misc.Unsafe类的compareAndSwapInt()方法的源代码。

public final native boolean compareAndSwapInt(Object o, long offset, int expected, int)

可以看到，这是一个本地方法调用。这个本地方法在openjdk中依次调用的c++代码为： unsafe.cpp，atomic.cpp和atomic_windows_x86.inline.hpp。下面是对应于intel X86处理器的源代码的片段。

如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（Lock Cmpxchg）。反之，如果程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果）。

4.3.5.3Intel的Lock前缀指令的说明

intel的手册对lock前缀的说明如下。

1）确保对内存的读-改-写操作原子执行。在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。从Pentium 4、Intel Xeon及P6处理器开始，Intel使用缓存锁定（Cache Locking）来保证指令执行的原子性。缓存锁定将大大降低lock前缀指令的执行开销。

2）禁止该指令，与之前和之后的读和写指令重排序。

3）把写缓冲区中的所有数据刷新到内存中。上面的第2点和第3点所具有的内存屏障效果，足以同时实现volatile读和volatile写的内存语义。

经过上面的分析，现在我们终于能明白为什么JDK文档说CAS同时具有volatile读和 volatile写的内存语义了。

4.3.5.4总结：

现在对公平锁和非公平锁的内存语义做个总结。

·公平锁和非公平锁释放时，最后都要写一个volatile变量state。

·公平锁获取时，首先会去读volatile变量。

·非公平锁获取时，首先会用CAS更新volatile变量，这个操作同时具有volatile读和volatile 写的内存语义。

从本文对ReentrantLock的分析可以看出，锁释放-获取的内存语义的实现至少有下面两种方式。 1）利用volatile变量的写-读所具有的内存语义。

2）利用CAS所附带的volatile读和volatile写的内存语义。

4.3.6 Java线程间通信的4种方式

由于Java的CAS同时具有volatile读和volatile写的内存语义，因此Java线程之间的通信现在有了下面4种方式。CAS*volatile=2*2=4种。

1）A线程写volatile变量，随后B线程读这个volatile变量。

2）A线程写volatile变量，随后B线程用CAS更新这个volatile变量。

3）A线程用CAS更新一个volatile变量，随后B线程用CAS更新这个volatile变量。

4）A线程用CAS更新一个volatile变量，随后B线程读这个volatile变量。

4.3.7整个JUC并发体系的基石

java的CAS会使用现代处理器上提供的高效机器级别的原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。

同时，volatile变量的读/写和 CAS可以实现线程之间的通信。把这些特性整合在一起，就形成了整个concurrent包得以实现的基石。如果我们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式。

首先，声明共享变量为volatile。然后，使用CAS的原子条件更新来实现线程之间的同步。同时，配合以volatile的读/写和CAS所具有的volatile读和写的内存语义来实现线程之间的通信。 AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent 包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent包的实现示意图如3-28所示。

【concurrent包的实现示意图】

4.4final的内存语义

final域的重排序规则对于final域，编译器和处理器要遵守两个重排序规则。

1）在构造函数内对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。

2）初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。下面通过一些示例性的代码来分别说明这两个规则。

代码实例：

public class FinalExample {
    int i; // 普通变量
    final int j; // final变量
    static FinalExample obj;
    public FinalExample () { // 构造函数
        i = 1; // 写普通域
        j = 2; // 写final域
    }
    public static void writer () { // 写线程A执行
        obj = new FinalExample ();
    }
    public static void reader () { // 读线程B执行
        FinalExample object = obj; // 读对象引用
        int a = object.i; // 读普通域
        int b = object.j; // 读final域
    }
}

这里假设一个线程A执行writer()方法，随后另一个线程B执行reader()方法。下面我们通过这两个线程的交互来说明这两个规则。

4.4.1写final域的重排序规则

写final域的重排序规则禁止把final域的写重排序到构造函数之外。这个规则的实现包含下面2个方面。

1）JMM禁止编译器把final域的写重排序到构造函数之外。

2）编译器会在final域的写之后，构造函数return之前，插入一个StoreStore屏障。这个屏障禁止处理器把final域的写重排序到构造函数之外。

现在让我们分析writer()方法。writer()方法只包含一行代码：

finalExample=new FinalExample()

包含两个步骤：

1）构造一个FinalExample类型的对象。

2）把这个对象的引用赋值给引用变量obj。

假设线程B读对象引用与读对象的成员域之间没有重排序,下图是一种可能的执行时序：

在图3-29中，写普通域的操作被编译器重排序到了构造函数之外，读线程B错误地读取了普通变量i初始化之前的值。而写final域的操作，被写final域的重排序规则“限定”在了构造函数之内，读线程B正确地读取了final变量初始化之后的值。

【线程执行时序图】

写final域的重排序规则可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确初始化过了，而普通域不具有这个保障。【核心！！】以上图为例，在读线程B“看到”对象引用obj时， 很可能obj对象还没有构造完成（对普通域i的写操作被重排序到构造函数外，此时初始值1还没有写入普通域i）。

4.4.2读final域的重排序规则

读final域的重排序规则是，在一个线程中，初次读对象引用与初次读该对象包含的final 域，JMM禁止处理器重排序这两个操作，即：在读一个对象的final域之前，一定会先读包含这个final 域的对象的引用。（注意，这个规则仅仅针对处理器）。编译器会在读final 域操作的前面插入一个LoadLoad屏障。

初次读对象引用与初次读该对象包含的final域，这两个操作之间存在间接依赖关系。由于编译器遵守间接依赖关系，因此编译器不会重排序这两个操作。大多数处理器也会遵守间接依赖，也不会重排序这两个操作。但有少数处理器允许对存在间接依赖关系的操作做重排序（比如alpha处理器），这个规则就是专门用来针对这种处理器的。

reader()方法包含3个操作：

·初次读引用变量obj。

·初次读引用变量obj指向对象的普通域j。

·初次读引用变量obj指向对象的final域i。

现在假设写线程A没有发生任何重排序，同时程序在不遵守间接依赖的处理器上执行，图示是一种可能的执行时序：

在上图中，读对象的普通域的操作被处理器重排序到读对象引用之前。读普通域时，该域还没有被写线程A写入，这是一个错误的读取操作。而读final域的重排序规则会把读对象 final域的操作“限定”在读对象引用之后，此时该final域已经被A线程初始化过了，这是一个正确的读取操作。

读final域的重排序规则可以确保：在读一个对象的final域之前，一定会先读包含这个final 域的对象的引用。在这个示例程序中，如果该引用不为null，那么引用对象的final域一定已经被A线程初始化过了。

4.4.3final域为引用类型

上面我们看到的final域是基础数据类型，如果final域是引用类型，将会有什么效果？请看下列示例代码：

public class FinalReferenceExample {
    final int[] intArray; // final是引用类型
    static FinalReferenceExample obj;
    public FinalReferenceExample () { // 构造函数
        intArray = new int[1]; // 1
        intArray[0] = 1; // 2
    }
    public static void writerOne () { // 写线程A执行
        obj = new FinalReferenceExample (); // 3
    }
    public static void writerTwo () { // 写线程B执行
        obj.intArray[0] = 2; // 4
    }
    public static void reader () { // 读线程C执行
        if (obj != null) { // 5
            int temp1 = obj.intArray[0]; // 6
        }
    }
}

本例final域为一个引用类型，它引用一个int型的数组对象。对于引用类型，写final域的重排序规则对编译器和处理器增加了如下约束：在构造函数内对一个final引用的对象的成员域的写入，与随后在构造函数外把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。

即上面的2与3不能重排序。

4.5final语义在处理器中的实现

上面我们提到，写final域的重排序规则会要求编译器在final域的写之后，构造函数return 之前插入一个StoreStore障屏。读final域的重排序规则要求编译器在读final域的操作前面插入一个LoadLoad屏障。

由于X86处理器不会对写-写操作做重排序，所以在X86处理器中，写final域需要的 StoreStore障屏会被省略掉。同样，由于X86处理器不会对存在间接依赖关系的操作做重排序，所以在X86处理器中，读final域需要的LoadLoad屏障也会被省略掉。也就是说，在X86处理器中，final域的读/写不会插入任何内存屏障！

4.5.1JSR-133为什么要增强final的语义？

在旧的Java内存模型中，一个最严重的缺陷就是线程可能看到final域的值会改变。比如，一个线程当前看到一个整型final域的值为0（还未初始化之前的默认值），过一段时间之后这个线程再去读这个final域的值时，却发现值变为1（被某个线程初始化之后的值）。最常见的例子就是在旧的Java内存模型中，String的值可能会改变。

为了修补这个漏洞，JSR-133专家组增强了final的语义。通过为final域增加写和读重排序规则，可以为Java程序员提供初始化安全保证：只要对象是正确构造的（被构造对象的引用在构造函数中没有“逸出”），那么不需要使用同步（指lock和volatile的使用）就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值。