JAVA内存可见性

基本概念

java 的所有变量都存储在主内存中

每个线程有自己独的工作内存，保存了该线程使用到的变量副本，是对主内存中变量的一份拷贝

每个线程不能访问其他线程的工作内存，线程间变量传递需要通过主内存来完成

每个线程不能直接操作主存，只能把主存的内容拷贝到本地内存后再做操作（这是线程不安全的本质），然后写回主存

可见性

当一个线程修改了共享变量时，另一个线程可以读取到这个修改后的值。

内存屏障（Memory Barriers）

处理器的一组指令，用于实现对内存操作的顺序限制。

缓冲行

CPU告诉缓存中可以分配的最小存储单位，处理器填写缓存行时，会加载整个缓存行。

Lock前缀的指令

Lock前缀的指令在多核处理器下会发生两件事情：

1）将当前处理器的缓存行的数据协会到系统内存。

2）这个写回内存的操作会使其他CPU缓存了该内存的地址的数据无效。

缓存一致性协议

在多处理器下，为零保证各个处理器的缓存是一致的，每个处理器都会通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了。当处理器发现自己缓存行对应的地址被修改，就会将当前处理器的缓存行设置为无效状态。当处理器对这个数据进行读写的时候，会重新把数据从内存中读取到处理器缓存中。

CAS

CompareAndSwap 比较并交换

CAS操作需要输入两个值，一个旧值（执行CAS操作前的值，期望值）和一个新值，只有当当前值等于旧值时，才可以将当前值设置为新值，否则不设置。这是一个原子操作，由硬件保证。

重排序规则

从根本上来所，JMM 对编译器和处理器的重排序限制只有一条，只要不改变程序执行的结果（指的是单线程或者正确同步的多线程环境下），那么编译器和处理器怎么优化都可以。

Volatile

从上面的Lock前缀指令和缓存一致性协议可以看出来，这就是volatile的实现原理了。

实际上，valatile变量被写入时，确实加了一个Lock前缀的指定，以此来达到可见性的目的。

通过内存屏障和禁止指令重排序来保证可见性：

（a）对volatile进行读操作，会在读操作之前增加一个load屏障指令

（b）对volatile进行写操作，会在写操作之后增加一个store屏障指令

 内存屏障：处理器的一组指令，用于实现对内存操作的顺序限制（指令重排时不能把后面的指令重排列到内存屏障之前的位置）

你可能会问：我们可否在num前面加volatile 达到内存可见性呢？ 答案是否定的，volatile实现共享变量内存可见性有一个条件，就是对共享变量的操作必须具有原子性。比如 num = 10; 这个操作具有原子性，但是 num++ 或者num--由3步组成，并不具有原子性，所以是不行的。

synchronized

synchronized用来给对象和方法或者代码块加锁，当它锁定一个方法或者一个代码块的时候，同一时刻最多只有一个线程执行这段代码。当两个并发线程访问同一个对象object中的这个加锁同步代码块时，一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。然而，当一个线程访问object的一个加锁代码块时，另一个线程仍然可以访问该object中的非加锁代码块。

同步块的可见性：对一个变量执行unlock操作之前，必须把此变量同步回主内存中（执行store、write操作）

JMM关于synchronized的两条规定：

1. 线程解锁前，必须把共享变量的最新值刷新到主内存中

2. 线程加锁时，讲清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值。

final

Final域只能被显示地赋值一次，但是这并不代表final域不能被多次初始化。

比如：final int i ;i在构造函数中被赋值之前，就会被初始化为默认的值：0.通过调试代码可以证明这一点。

为了保证final域的值不会在为初始化的情况下被访问到，程序员只需要保证一点即可：即，在构造函数中，正在被构造的对象（this）没有“逸出”，那么不需要任何同步手段，就能保证任意线程看到的final域，包括基本类型和引用类型，都是已经被正确地通过构造函数初始化过了的。

一个会是正在被构造的对象逸出的例子：

public class FinalTest { 

final int i;

static FinalTest obj;

public FinalTest() {

   i  =1;

  /**

  *这里会使正在被构造的对象逸出，如果和上一句做了重排序，那么其他线程就可以通过obj访问到还为被初始化的final域。

  **/

obj =this; 

 }

}

Happens-Before规则

Happen-Before规则用来描述两个操作之间的顺序关系，这两个操作可以再一个线程内，也可以不再一个线程内。此顺序并不严格意味着执行时间上的顺序，而是至前一个操作的结果要对后一个操作可见。

Happens-Before关系的定义如下：

如果一个happens-before另一个操作，那么第一个操作的执行结果对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前

两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。

举例来说，如果在程序执行顺序上，A先于B，并且A修改了共享变量，而B正好使用该共享变量，那么A需要happen-before B，再直白一点，就是A对共享变量的修改，需要在B执行时，对B可见。

应用

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

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

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

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

start()规则：如果线程A执行操作ThreadB.start()，那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。

join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

对所有这些规则的说明：A happens-before B并不意味着A一定要先在B之前发生，而是说，如果A已经发生在了B前面，那么A的操作结果一定要对B可见

只有在下列情况时，一个线程对字段的修改才能确保对另一个线程可见：

一个写线程释放一个锁之后，另一个读线程随后获取了同一个锁。本质上，线程释放锁时会将强制刷新工作内存中的脏数据到主内存中，获取一个锁将强制线程装载（或重新装载）字段的值。锁提供对一个同步方法或块的互斥性执行，线程执行获取锁和释放锁时，所有对字段的访问的内存效果都是已定义的。

注意同步的双重含义：锁提供高级同步协议，同时在线程执行同步方法或块时，内存系统（有时通过内存屏障指令）保证值的一致性。这说明，与顺序程序设计相比较，并发程序设计与分布式程序设计更加类似。同步的第二个特性可以视为一种机制：一个线程在运行已同步方法时，它将发送和/或接收其他线程在同步方法中对变量所做的修改。从这一点来说，使用锁和发送消息仅仅是语法不同而已。

如果把一个字段声明为volatile型，线程对这个字段写入后，在执行后续的内存访问之前，线程必须刷新这个字段且让这个字段对其他线程可见（即该字段立即刷新）。每次对volatile字段的读访问，都要重新装载字段的值。

一个线程首次访问一个对象的字段，它将读到这个字段的初始值或被某个线程写入后的值。

此外，把还未构造完成的对象的引用暴露给某个线程，这是一个错误的做法 (see ?.1.2)。在构造函数内部开始一个新线程也是危险的，特别是这个类可能被子类化时。Thread.start有如下的内存效果：调用start方法的线程释放了锁，随后开始执行的新线程获取了这个锁。如果在子类构造函数执行之前，可运行的超类调用了new Thread(this).start()，当run方法执行时，对象很可能还没有完全初始化。同样，如果你创建且开始一个新线程T，这个线程使用了在执行start之后才创建的一个对象X。你不能确信X的字段值将能对线程T可见。除非你把所有用到X的引用的方法都同步。如果可行的话，你可以在开始T线程之前创建X。

线程终止时，所有写过的变量值都要刷新到主内存中。比如，一个线程使用Thread.join来终止另一个线程，那么第一个线程肯定能看到第二个线程对变量值得修改。

注意，在同一个线程的不同方法之间传递对象的引用，永远也不会出现内存可见性问题。

内存模型确保上述操作最终会发生，一个线程对一个特定字段的特定更新，最终将会对其他线程可见，但这个“最终”可能是很长一段时间。线程之间没有同步时，很难保证对字段的值能在多线程之间保持一致（指写线程对字段的写入立即能对读线程可见）。特别是，如果字段不是volatile或没有通过同步来访问这个字段，在一个循环中等待其他线程对这个字段的写入，这种情况总是错误的(see ?.2.6)。

在缺乏同步的情况下，模型还允许不一致的可见性。比如，得到一个对象的一个字段的最新值，同时得到这个对象的其他字段的过期的值。同样，可能读到一个引用变量的最新值，但读取到这个引用变量引用的对象的字段的过期值。

不管怎样，线程之间的可见性并不总是失效（指线程即使没有使用同步，仍然有可能读取到字段的最新值），内存模型仅仅是允许这种失效发生而已。因此，即使多个线程之间没有使用同步，也不保证一定会发生内存可见性问题（指线程读取到过期的值），java内存模型仅仅是允许内存可见性问题发生而已。在很多当前的JVM实现和java执行平台中，甚至是在那些使用多处理器的JVM和平台中，也很少出现内存可见性问题。共享同一个CPU的多个线程使用公共的缓存，缺少强大的编译器优化，以及存在强缓存一致性的硬件，这些都会使线程更新后的值能够立即在多线程之间传递。这使得测试基于内存可见性的错误是不切实际的，因为这样的错误极难发生。或者这种错误仅仅在某个你没有使用过的平台上发生，或仅在未来的某个平台上发生。这些类似的解释对于多线程之间的内存可见性问题来说非常普遍。没有同步的并发程序会出现很多问题，包括内存一致性问题。

案例

public class Zuo {

private static boolean flag =true;

public static void main(String[] args) throws InterruptedException {

newThread(() -> { print(); }).start();

 Thread.sleep(2500);

 flag =false;

 System.out.println("flag set to false"); 

 }

private static void print() {

while(flag) { } 

 }

}

上面这段代码在JVM默认参数下会一直执行下去，但是如果在VM options中加上-Xint参数则不会。-Xint这个参数的作用是让JVM在解释器的模式下执行。那么这里的区别就是是否进行了JIT优化。

使用hids查看JIT后的汇编码后发现只在进入循环之前读取的flag变量，后面JMP指令无条件跳转了无论flag怎么变都不管了。JAVA内存模型中不能保证没有线程安全的字段将会看到更新。这个规定允许JIT进行这样的优化。 

通过这个例子发现，在解释执行模式下不修改共享变量的值的情况下共享变量不加volatile关键字的变量也是具有多线程的可见性的。所谓的本地内存只是JAVA内存模型（JMM）的一个抽象概念，并不真实存在。

Java内存模型的抽象

在java中，所有实例域、静态域和数组元素存储在堆内存中，堆内存在线程之间共享（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）。局部变量（Local variables），方法定义参数（java语言规范称之为formal method parameters）和异常处理器参数（exception handler parameters）不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

Java线程之间的通信由Java内存模型（本文简称为JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。Java内存模型的抽象示意图如下：

从上图来看，线程A与线程B之间如要通信的话，必须要经历下面2个步骤：

首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。

然后，线程B到主内存中去读取线程A之前已更新过的共享变量。

下面通过示意图来说明这两个步骤：

如上图所示，本地内存A和B有主内存中共享变量x的副本。假设初始时，这三个内存中的x值都为0。线程A在执行时，把更新后的x值（假设值为1）临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的x值刷新到主内存中，此时主内存中的x值变为了1。随后，线程B到主内存中去读取线程A更新后的x值，此时线程B的本地内存的x值也变为了1。

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

重排序

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

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

指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。

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

从java源代码到最终实际执行的指令序列，会分别经历下面三种重排序：

上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel称之为memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。

JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

处理器重排序与内存屏障指令

现代的处理器使用写缓冲区来临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用。虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响：处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致！为了具体说明，请看下面示例：

Processor AProcessor B

a = 1; //A1

x = b; //A2

b = 2; //B1

y = a; //B2

初始状态：a = b = 0

处理器允许执行后得到结果：x = y = 0

假设处理器A和处理器B按程序的顺序并行执行内存访问，最终却可能得到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一样，这里就不赘述了）。

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

下面是常见处理器允许的重排序类型的列表：

     Load-Load Load-Store Store-Store Store-Load 数据依赖

sparc-TSO    N    N    N    Y    N

x86    N    N    N    Y    N

ia64    Y    Y    Y    Y    N

PowerPC    Y    Y    Y    Y    N

上表单元格中的“N”表示处理器不允许两个操作重排序，“Y”表示允许重排序。

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

※注1：sparc-TSO是指以TSO(Total Store Order)内存模型运行时，sparc处理器的特性。

※注2：上表中的x86包括x64及AMD64。

※注3：由于ARM处理器的内存模型与PowerPC处理器的内存模型非常类似，本文将忽略它。

※注4：数据依赖性后文会专门说明。

为了保证内存可见性，java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM把内存屏障指令分为下列四类：

屏障类型指令示例说明

LoadLoad BarriersLoad1; LoadLoad; Load2确保Load1数据的装载，之前于Load2及所有后续装载指令的装载。

StoreStore BarriersStore1; StoreStore; Store2确保Store1数据对其他处理器可见（刷新到内存），之前于Store2及所有后续存储指令的存储。

LoadStore BarriersLoad1; LoadStore; Store2确保Load1数据装载，之前于Store2及所有后续的存储指令刷新到内存。

StoreLoad BarriersStore1; StoreLoad; Load2确保Store1数据对其他处理器变得可见（指刷新到内存），之前于Load2及所有后续装载指令的装载。StoreLoad Barriers会使该屏障之前的所有内存访问指令（存储和装载指令）完成之后，才执行该屏障之后的内存访问指令。

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

happens-before

从JDK5开始，java使用新的JSR -133内存模型（本文除非特别说明，针对的都是JSR- 133内存模型）。JSR-133提出了happens-before的概念，通过这个概念来阐述操作之间的内存可见性。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。 与程序员密切相关的happens-before规则如下：

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

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

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

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

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

happens-before与JMM的关系如下图所示：

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

参考文献

理解 Memory barrier（内存屏障）

Programming Language Pragmatics, Third Edition

The Java Language Specification, Third Edition

JSR-133: Java Memory Model and Thread Specification

Java theory and practice: Fixing the Java Memory Model, Part 2

Understanding POWER Multiprocessors

Concurrent Programming on Windows

The Art of Multiprocessor Programming

Intel® 64 and IA-32 ArchitecturesvSoftware Developer’s Manual Volume 3A: System Programming Guide, Part 1

Java Concurrency in Practice

The JSR-133 Cookbook for Compiler Writers