JMM简介

Java的内存模型JMM(Java Memory
Model)JMM主要是为了规定了线程和内存之间的一些关系。根据JMM的设计,系统存在一个主内存(Main
Memory),Java中所有实例变量都储存在主存中,对于所有线程都是共享的。每条线程都有自己的工作内存(Working
Memory),工作内存由缓存和堆栈两部分组成,缓存中保存的是主存中变量的拷贝,缓存可能并不总和主存同步,也就是缓存中变量的修改可能没有立刻写到主存中;堆栈中保存的是线程的局部变量,线程之间无法相互直接访问堆栈中的变量

JMM是什么

JMM (Java Memory Model)是Java内存模型,JMM定义了程序中各个共享变量的访问规则,即在虚拟机中将变量存储到内存和从内存读取变量这样的底层细节.

为什么要设计JMM

屏蔽各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到一致的内存访问效果.

为什么要理解JMM

理解JMM是理解并发问题的基础.
主内存,工作内存和线程三者的交互关系
JMM规定了共享变量都存储在主内存中.每条线程还有自己的工作内存,线程的工作内存保存了主内存的副本拷贝,对变量的操作在工作内存中进行,不能直接操作主内存中的变量.不同线程间无法直接访问对方的工作内存变量,需要通过主内存完成。如下图:

内存模型抽象图.png

JMM的基本概念

包括“并发、同步、主内存、本地内存、重排序、内存屏障、happens before规则、as-if-serial规则、数据依赖性、顺序一致性模型、JMM的含义和意义”。下面一一讲解 搞懂我们写的代码到底是怎么工作的

1、并发

定义：即，并发(同时)发生。在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理机上运行，但任一个时刻点上只有一个程序在处理机上运行。

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

(01) 通信 —— 是指线程之间如何交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。

(02) 同步—— 是指程序用于控制不同线程之间操作发生相对顺序的机制。在Java中，可以通过volatile，synchronized, 锁等方式实现同步。

• 1.1并发编程中的三个概念

  • 1.1.1 原子性

    原子是世界上的最小单位，具有不可分割性。比如 a=0；（a非long和double类型） 这个操作是不可分割的，那么我们说这个操作时原子操作。再比如：a++； 这个操作实际是a = a + 1；是可分割的，所以他不是一个原子操作。非原子操作都会存在线程安全问题，需要我们使用同步技术（sychronized）来让它变成一个原子操作。一个操作是原子操作，那么我们称它具有原子性。java的concurrent包下提供了一些原子类，我们可以通过阅读API来了解这些原子类的用法。比如：AtomicInteger、AtomicLong、AtomicReference等。

举个例子:

i = 0;       //1
j = i ;      //2
i++;         //3
i = j + 1;   //4

上面四个操作，有哪个几个是原子操作，那几个不是？如果不是很理解，可能会认为都是原子性操作，其实只有1才是原子操作，其余均不是。
1在Java中，对基本数据类型的变量和赋值操作都是原子性操作；
2中包含了两个操作：读取i，将i值赋值给j
3中包含了三个操作：读取i值、i + 1 、将+1结果赋值给i；
4中同三一样

• 1.1.2可见性

  可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。

举个例子:

//线程1执行的代码
int i = 0;
i = 10;
//线程2执行的代码
j = i;

假若执行线程1的是CPU1，执行线程2的是CPU2。由上面的分析可知，当线程1执行 i = 10这句时，会先把i的初始值加载到CPU1的高速缓存中，然后赋值为10，那么在CPU1的高速缓存当中i的值变为10了，却没有立即写入到主存当中。此时线程2执行 j = i，它会先去主存读取i的值并加载到CPU2的缓存当中，注意此时内存当中i的值还是0，那么就会使得j的值为0，而不是10。这就是可见性问题，线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。
在上面已经分析了，在多线程环境下，一个线程对共享变量的操作对其他线程是不可见的。
对于可见性，Java提供了volatile关键字来保证可见性。当一个共享变量被volatile修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。而普通的共享变量不能保证可见性，因为普通共享变量被修改之后，什么时候被写入主存是不确定的，当其他线程去读取时，此时内存中可能还是原来的旧值，因此无法保证可见性。另外，通过synchronized和Lock也能够保证可见性，synchronized和Lock能保证同一时刻只有一个线程获取锁然后执行同步代码，并且在释放锁之前会将对变量的修改刷新到主存当中。因此可以保证可见性。

• 1.1.3有序性

  即程序执行的顺序按照代码的先后顺序执行。

即程序执行的顺序按照代码的先后顺序执行：

//线程1执行的代码
int i = 0;              
boolean flag = false;
i = 1;                //语句1  
flag = true;          //语句2

上面代码定义了一个int型变量，定义了一个boolean类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句1是在语句2前面的，那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）。
在Java里面，可以通过volatile关键字来保证一定的“有序性”。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。另外，Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为 happens-before 原则。

2、主内存和本地内存

主内存 —— 即main memory。在java中，实例域、静态域和数组元素是线程之间共享的数据，它们存储在主内存中。

本地内存 —— 即local memory。 局部变量，方法定义参数 和 异常处理器参数是不会在线程之间共享的，它们存储在线程的本地内存中。

• 2.1、 主内存与工作内存交互协议

JMM定义了8中操作来完成主内存与工作内存的交互。虚拟机保证每种操作都是原子的,不可再分的.8种操作分别是lock,unlock,read,load,use,assign,store,write.把一个变量复制到工作内存,就要顺序的执行read和load操作,从工作内存同步会主内存,就要顺序的执行store和write操作.对一个变量执行lock操作,将会清空工作内存中此变量的值,在使用前,需要重新执行load或assign操作初始化变量的值对一个变量unlock操作前,必须先将此变量同步会主内存.工作内存中的volatile变量在每次使用前要刷新,执行引擎看不到不一致的情况,volatile还禁止指令重排序

• 2.1.1内存间交互操作

我们接着再来关注下变量从主内存读取到工作内存，然后同步回工作内存的细节，这就是主内存与工作内存之间的交互协议。Java内存模型定义了以下8种操作来完成，它们都是原子操作（除了对long和double类型的变量）。

• lock(锁定)
  作用于主内存中的变量，它将一个变量标志为一个线程独占的状态。

• unlock(解锁)
  作用于主内存中的变量，解除变量的锁定状态，被解除锁定状态的变量才能被其他线程锁定。

• read(读取)
  作用于主内存中的变量，它把一个变量的值从主内存中传递到工作内存，以便进行下一步的load操作。

• load(载入)
  作用于工作内存中的变量，它把read操作传递来的变量值放到工作内存中的变量副本中。

• use(使用)
  作用于工作内存中的变量，这个操作把变量副本中的值传递给执行引擎。当执行需要使用到变量值的字节码指令的时候就会执行这个操作。

• assign(赋值)
  作用于工作内存中的变量，接收执行引擎传递过来的值，将其赋给工作内存中的变量。当执行赋值的字节码指令的时候就会执行这个操作。

• store(存储)
  作用于工作内存中的变量，它把工作内存中的值传递到主内存中来，以便进行下一步write操作。

• write(写入)
  作用于主内存中的变量，它把store传递过来的值放到主内存的变量中。

• 2.1.2JMM对交互指令的约束

如果要把一个变量从主内存中复制到工作内存，就需要按顺寻地执行read和load操作，如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。
Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。也就是read和load之间，store和write之间是可以插入其他指令的，如对主内存中的变量a、b进行访问时，可能的顺序是read a，read b，load b， load a。Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：

• 不允许read和load、store和write操作之一单独出现

• 不允许一个线程丢弃它的最近assign的操作，即变量在工作内存中改变了之后必须同步到主内存中。

• 不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。

• 一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。

• 一个变量在同一时刻只允许一条线程对其进行lock操作，lock和unlock必须成对出现

• 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值

• 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。

• 对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。
  具体执行流程图:

  
  
  主内存到工作内存流程图.png

JMM规定如果要把一个变量从主内存复制到工作内存，那就要顺序地执行read和load操作，如果要把变量从工作内存同步回主内存，就要顺序地执行store和write操作。
注意，Java内存模型只要求上述两个操作必须按顺序执行，而没有保证是连续执行。也就是说，read与load之间、store与write之间是可插入其他指令的，如对主内存中的变量a、b进行访问时，一种可能出现顺序是read a、read b、load b、load a。
除了以上的顺序约束以外，还规定了其他的约束：
a. 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现。
b. 不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
c. 不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
d. 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说，就是对一个变量实施use、store操作之前，必须先执行过了assign和load操作。
e. 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
f. 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
g. 如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定住的变量。 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。

3、 重排序

计算机在执行程序时，为了提高性能，编译器和处理器的常常会对指令做重排，一般分以下3种

• 编译器优化的重排

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

• 指令并行的重排

现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性(即后一个执行的语句无需依赖前面执行的语句的结果)，处理器可以改变语句对应的机器指令的执行顺序

• 内存系统的重排

由于处理器使用缓存和读写缓存冲区，这使得加载(load)和存储(store)操作看上去可能是在乱序执行，因为三级缓存的存在，导致内存与缓存的数据同步存在时间差。

流程图如下:

重排序.png

其中编译器优化的重排属于编译期重排，指令并行的重排和内存系统的重排属于处理器重排，在多线程环境中，这些重排优化可能会导致程序出现内存可见性问题

举个例子 下面代码执行顺序是什么？

int  x =1; //语句1
int  y=2; //语句2

如果不了解重排序的同学,可能说先执行语句1,在执行语句2。
其实在真正运行的时候 可能是先执行语句2在执行语句1。

下面写一段代码来验证下重排序。这段代码绝对是看完理解绝对能爽5天 。

/**
 * @author hongwang.zhang
 * @version: 1.0
 * @date 2018/7/3118:25
 * @see
 **/
public class jmmReorder {

          private static int x = 0, y = 0;
          private static int a = 0, b =0;

          public static void main(String[] args) throws InterruptedException {
               int i = 0;
               for(;;) {
                    i++;
                    x = 0; y = 0;
                    a = 0; b = 0;
                    Thread one = new Thread(new Runnable() {
                         public void run() {
                              //由于线程one先启动，下面这句话让它等一等线程two. 读着可根据自己电脑的实际性能适当调整等待时间.
                              shortWait(100000);
                              a = 1;
                              x = b;
                         }
                    });

                    Thread other = new Thread(new Runnable() {
                         public void run() {
                              b = 1;
                              y = a;
                         }
                    });
                    one.start();other.start();
                    one.join();other.join();
                    String result = "第" + i + "次 (" + x + "," + y + "）";
                    if(x == 0 && y == 0) {
                         System.err.println(result);
                         break;
                    } else {
                         System.out.println(result);
                    }
               }
          }


          public static void shortWait(long interval){
               long start = System.nanoTime();
               long end;
               do{
                    end = System.nanoTime();
               }while(start + interval >= end);
          }
     }

出道题考考大家 以上代码可能执行的结果是：
A、1,0
B、0,1
C、1,1
D、0,0
E、以上均有可能

答案:69 请参考ascll编码十进制寻找答案

实验代码是构造一个循环，反复执行上面的实例代码，直到出现a=0且b=0的输出为止。实验结果说明，循环执行到第13830次时输出了(0,0)。
大多数现代微处理器都会采用将指令乱序执行（out-of-order execution，简称OoOE或OOE）的方法，在条件允许的情况下，直接运行当前有能力立即执行的后续指令，避开获取下一条指令所需数据时造成的等待。通过乱序执行的技术，处理器可以大大提高执行效率。
除了处理器，常见的Java运行时环境的JIT编译器也会做指令重排序操作，即生成的机器指令与字节码指令顺序不一致。

如果你了解了重排序 那么就再来一份代码告诉C等于几

int a = 1;
int b = 2;
int c = a + b;

答案： C=3

原因: 不管怎么重排序(编译器和处理器为了提高并行度),(单线程)程序的执行结果不能被改变。
java内存中的变量都有指针引用，上下文引用成链，这个链是不会被打乱重排序的，只有没有数据依赖关系的代码，才会被冲排序，所以在单线程内部重排序不会改变程序运行结果

3、1数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型：

上面三种情况，只要重排序两个操作的执行顺序，程序的执行结果将会被改变。
前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
注意，这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

总结: 为了提高程序的并发度，从而提高性能！但是对于多线程程序，重排序可能会导致程序执行的结果不是我们需要的结果！因此，在多线程环境下就需要我们通过“volatile，synchronize，锁等方式”作出正确的实现同步,因为单线程遵循as-if-serial语义

4、as-if-serial语义

as-if-serial语义:
所有的动作都可以为了优化而被重排序，但是必须保证它们重排序后的结果和程序代码本身的应有结果是一致的。Java编译器、运行时和处理器都会保证Java在单线程下遵循as-if-serial语义。

为了具体说明，请看下面计算圆面积的代码示例：

double pi  = 3.14;    //A
double r   = 1.0;     //B
double area = pi * r * r; //C 

上面三个操作的数据依赖关系如下图所示：

as-if-erial关系图.png

如上图所示，A 和 C 之间存在数据依赖关系，同时 B 和 C 之间也存在数据依赖关系。因此在最终执行的指令序列中，C 不能被重排序到 A 和 B 的前面（C 排到 A 和 B 的前面，程序的结果将会被改变）。但 A 和 B 之间没有数据依赖关系，编译器和处理器可以重排序 A 和 B 之间的执行顺序。下图是该程序的两种执行顺序：

未命名文件.png

了解后as-if-serial语义后如下代码 X等于几

public class Reordering {
    public static void main(String[] args) {
        int x, y;
        x = 1;
        try {
            x = 2;
            y = 0 / 0;    
        } catch (Exception e) {
        } finally {
            System.out.println("x = " + x);
        }
    }
}

答案是2

原因: 为保证as-if-serial语义，Java异常处理机制也会为重排序做一些特殊处理。例如在下面的代码中，y = 0 / 0可能会被重排序在x = 2之前执行，为了保证最终不致于输出x = 1的错误结果，JIT在重排序时会在catch语句中插入错误代偿代码，将x赋值为2，将程序恢复到发生异常时应有的状态。这种做法的确将异常捕捉的逻辑变得复杂了，但是JIT的优化的原则是，尽力优化正常运行下的代码逻辑，哪怕以catch块逻辑变得复杂为代价，毕竟，进入catch块内是一种“异常”情况的表现。

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

5、 happens-before规则

从JDK5开始，Java使用新的JSR -133内存模型。JSR-133提出了happens-before的概念，通过这个概念来阐述操作之间的内存可见性。
如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见。

常见的满足happens- before原则的语法现象：

• 对象加锁：对一个监视器锁的解锁，happens-before 于随后对这个监视器锁的加锁。
• volatile变量：对一个volatile域的写，happens-before 于任意后续对这个volatile域的读。

在java语言中大概有8大happens-before原则，分别如下：

• 程序次序规则(Pragram Order Rule):在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环结构。

一段代码在单线程中执行的结果是有序的。注意是执行结果，因为虚拟机、处理器会对指令进行重排序。虽然重排序了，但是并不会影响程序的执行结果，所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对单线程有效，在多线程环境下无法保证正确性。

int a = 3; //1
int b = a + 3; //2

这里的对b的赋值操作会用到变量a，那么java的“单线程happen-before原则”就保证②的中的a的值一定是3，因为① 书写在②前面, ①对变量a的赋值操作对②一定可见。因为② 中有用到①中的变量a，再加上java内存模型提供了“单线程happen-before原则”，所以java虚拟机不许可操作系统对① ② 操作进行指令重排序，即不可能有② 在①之前发生，
但是对于下面的代码：

int a = 3;
int b = 4;

两个语句直接没有依赖关系，所以指令重排序可能发生，即对b的赋值可能先于对a的赋值。

• 监视器规则(Monitor Lock Rule)：

对某个锁的unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，这里的“后面”是指时间上的先后顺序。也就是说，如果某个锁已经被lock了，那么只有它被unlock之后，其他线程才能lock该锁。表现在代码上，如果是某个同步方法，如果某个线程已经进入了该同步方法，只有当这个线程退出了该同步方法(unlock操作)，别的线程才可以进入该同步方法。

• volatile变量规则(Volatile Variable Rule)：

对一个volatile变量的写操作先行发生于对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。也就是说，某个线程对volatile变量写入某个值后，能立即被其它线程读取到

• 线程启动规则(Thread Start Rule) ：

Thread对象的start()方法先行发生于此线程的每一个动作。

• 线程终于规则(Thread Termination Rule) ：

线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束，Thread.isAlive()的返回值等作段检测到线程已经终止执行。

• 线程中断规则(Thread Interruption Rule) ：

对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生。

• 对象终结规则(Finalizer Rule)：

一个对象初始化完成(构造方法执行完成)先行发生于它的finalize()方法的开始。

• 传递性(Transitivity)：

如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

案例分析:

package com.test.volatiles;

import java.util.Vector;

/**
 * @author hongwang.zhang
 * @version: 1.0
 * @date 2018/8/215:03
 * @see
 **/
public class Test2 {
     private static Vector<Integer> vector = new Vector<Integer>();
     public static void main(String[] args) {
          while (true) {
               for (int i = 0; i < 10; i++) {
                    vector.add(i);
               }
               Thread removeThread = new Thread(new Runnable() {
                    public void run() {
                         for (int i = 0; i < vector.size(); i++) {
                              vector.remove(i);
                         }
                    }
               });
               Thread getThread = new Thread(new Runnable() {
                    public void run() {
                         for (int i = 0; i < vector.size(); i++) {
//          尝试加入首先判断i是否在vector size范围内，结果同样报错，
//              if (i < vector.size()) {
//                  continue;
//              }
                              vector.get(i);
                         }
                    }
               });
               removeThread.start();
               getThread.start();
               //不要同时产生过多的线程，否则会导致操作系统假死
               while (Thread.activeCount() > 20) ;
          }
     }
}

程序次序：不满足，remove(i)与get(i)在控制流顺序没有先行发生关系；
管程锁定：不满足，remove(i)与get(i)方法都是synchronized修饰，但各自持有不同的锁，不满足管程锁定要求的同一个锁；
volatile变量：不满足，没有volatile修饰变量，无视；
线程启动：不满足，removeThread.start()先与vector.remove(i)，getThread.start()先于vector.get(i)，但后两者明显没有关系；
线程终止：不满足；
线程中断：不满足；
对象终结：不满足，不存在对象终结的关系；
传递性：不满足，加入size()验证作为参考，假定A是remove()，B是size()验证，C是get()，B先于C，但A可能介乎于BC之间，也可能在B之前。因此不符合传递性。
结论：Vector作为相对线程安全对象，其单个方法带Synchronized修饰，是相对线程安全的，但Vector方法之间不是线程安全的，不能保证多个方法作用下的数据一致性。执行例子get()会报错：java.lang.ArrayIndexOutOfBoundsException。

时间上的先后顺序”与“先行发生”之间有什么不同：

private int value=0；
pubilc void setValue（int value）{
    this.value=value；
} public int getValue（）{
    return value；
}

以上显示的是一组再普通不过的getter/setter方法，假设存在线程A和B，线程A先（时间上的先后）调用了“setValue（1）”，然后线程B调用了同一个对象的“getValue（）”，那么线程B收到的返回值是什么？
我们依次分析一下先行发生原则中的各项规则，由于两个方法分别由线程A和线程B调用，不在一个线程中，所以程序次序规则在这里不适用；由于没有同步块，自然就不会发生lock和unlock操作，所以管程锁定规则不适用；由于value变量没有被volatile关键字修饰，所以volatile变量规则不适用；后面的线程启动、 终止、 中断规则和对象终结规则也和这里完全没有关系。 因为没有一个适用的先行发生规则，所以最后一条传递性也无从谈起，因此我们可以判定尽管线程A在操作时间上先于线程B，但是无法确定线程B中“getValue（）”方法的返回结果，换句话说，这里面的操作不是线程安全的。
那怎么修复这个问题呢？我们至少有两种比较简单的方案可以选择：要么把getter/setter方法都定义为synchronized方法，这样就可以套用管程锁定规则；要么把value定义为volatile变量，由于setter方法对value的修改不依赖value的原值，满足volatile关键字使用场景，这样就可以套用volatile变量规则来实现先行发生关系。

通过上面的例子，我们可以得出结论：一个操作“时间上的先发生”不代表这个操作会是“先行发生”，那如果一个操作“先行发生”是否就能推导出这个操作必定是“时间上的先发生”呢？很遗憾，这个推论也是不成立的，一个典型的例子就是多次提到的“指令重排序”，演示例子如下代码所示：

//以下操作在同一个线程中执行
int i=1；
int j=2；

以上代码的两条赋值语句在同一个线程之中，根据程序次序规则，“int i=1”的操作先行发生于“int j=2”，但是“int j=2”的代码完全可能先被处理器执行，这并不影响先行发生原则的正确性，因为我们在这条线程之中没有办法感知到这点。
上面两个例子综合起来证明了一个结论：时间先后顺序与先行发生原则之间基本没有太大的关系，所以我们衡量并发安全问题的时候不要受到时间顺序的干扰，一切必须以先行发生原则为准。

6、内存屏障

处理器都支持一定的内存屏障(memory barrier)或栅栏(fence)来控制重排序和数据在不同的处理器间的可见性。将CPU和内存间的数据存取操作分为load和store。例如，CPU将数据写回时，会将store请求放入write buffer中等待flush到内存，可以通过插入barrier的方式防止这个store请求与其他的请求重排序、保证数据的可见性。可以用一个生活中的例子类比屏障，例如坐地铁的斜坡式电梯时，大家按顺序进入电梯，但是会有一些人从左侧绕过去，这样出电梯时顺序就不相同了，如果有一个人携带了一个大的行李堵住了（屏障），则后面的人就不能绕过去了:)。另外这里的barrier和GC中用到的write barrier是不同的概念。

下面是常见处理器允许的重排序类型的列表
上面我们说了处理器会发生指令重排,现在来简单的看看常见处理器允许的重排规则,换言之就是处理器可以对那些指令进行顺序调整:

上表单元格中的 “N” 表示处理器不允许两个操作重排序，“Y” 表示允许重排序。
从上表我们可以看出：常见的处理器都允许 Store-Load 重排序；常见的处理器都不允许对存在数据依赖的操作做重排序。 x86 拥有相对较强的处理器内存模型，它们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）。
※注1：上表中的 x86 包括 x64 及 AMD64。=
※注2：由于 ARM 处理器的内存模型与 PowerPC 处理器的内存模型非常类似，本文将忽略它。
※注3：数据依赖性后文会专门说明。

先简单了解两个指令：

• Store：将处理器缓存的数据刷新到内存中。
• Load：将内存存储的数据拷贝到处理器的缓存中。

表格中的Y表示前后两个操作允许重排,N则表示不允许重排.与这些规则对应是的禁止重排的内存屏障.

注意:处理器和编译都会遵循数据依赖性,不会改变存在数据依赖关系的两个操作的顺序.所谓的数据依赖性就是如果两个操作访问同一个变量,且这两个操作中有一个是写操作,那么久可以称这两个操作存在数据依赖性.举个简单例子:

a=100;//write
b=a;//read

或者
a=100;//write
a=2000;//write
或者
a=b;//read
b=12;//write

以上所示的,两个操作之间不能发生重排,这是处理器和编译所必须遵循的.当然这里指的是发生在单个处理器或单个线程中.

内存屏障的分类

几乎所有的处理器都支持一定粗粒度的barrier指令，通常叫做Fence(栅栏、围墙)，能够保证在fence之前发起的load和store指令都能严格的和fence之后的load和store保持有序。通常按照用途会分为下面四种barrier

StoreLoad Barriers同时具备其他三个屏障的效果，因此也称之为全能屏障（mfence），是目前大多数处理器所支持的；但是相对其他屏障，该屏障的开销相对昂贵。

内存屏障对性能的影响（Performance Impact of Memory Barriers）

内存屏障阻止了 CPU 执行很多隐藏内存延迟的技术，因此有它们有显著的性能开销，必须考虑。为了达到最大性能，最好对问题建模，这样处理器可以做工作单元，然后让所有必须的内存屏障在工作单元的边界上发生。采用这种方法允许处理器不受限制地优化工作单元。把必须的内存屏障分组是有益的，那样，在第一个之后的 buffer 刷新的开销会小点，因为没有工作需要进行重新填充它。

总结: 通过内存屏障可以禁止特定类型处理器的重排序，从而让程序按我们预想的流程去执行。