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

3 原子性、可见性、有序性

原子性：

一个或多个操作，要么全部执行且在执行过程中不被任何因素打断,要么全部不执行。在java中当我们讨论一个操作具有原子性问题一般是指这个操作会被线程的随机调度打断。比如下面的操作：

int a = 1;                   //原子操作int a = b;                   //非原子操作，分两步操作第一步读取b的值，第二部将b赋值aint a = a + 1;               //非原子操作，分两步操作第一步读取a的值，第二部将计算结果赋值给aa ++ ;                       //非原子操作，同上

JMM对原子性问题的保证如下：

自带原子性保证：在java中，对基本数据类型的变量的读取和赋值操作是原子性操作。

synchronized：synchronized可以保证边界操作结果的原子性。synchronized可以防止多个线程并发的执行同一段代码，从结果上保证原子性。

Lock锁：Lock锁保证原子性的原理和synchronized类似。

原子类操作：JDK提供了很多原子操作类来保证操作的原子性，例如基础类型：AtomicXxx；引用类型AtomicReference等。原子类的底层是使用CAS机制，这个机制对原子性的保证和synchroinized有本质的区别。CAS机制保证了整个赋值操作是原子的不能被打断，二synchronized只能保证代码最终执行结果的正确性，也就是说，synchronized消除了原子性问题对代码最后执行结果的影响。

可见性：

在多线程环境下，一个线程对共享变量的修改，不仅要对本线程可见，而且要对其他线程可见。造成可见性的主要原因是由于CPU多核心和高速缓存（L1,L2,L3）。JMM对可见性问题，提供了如下保证：

volatile：使用volatile关键字修饰一个变量可以保证变量的可见性，大概的保证语义如下（详细的参看volatile的内存语义章节）

• 线程对共享变量的副本做了修改，会立刻刷新最新值到主内存中。

• 线程对共享变量的副本做了修改，其他其他线程中对这个变量拷贝的副本会时效；其他线程如果需要对这个共享变量进行读写，必须重新从主内存中加载。

synchronized：使用synchronized代码块或者synchronized方法也可以保证共享变量的可见性。当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。当线程获取锁时，JMM会把该线程对应的本地内存置为无效，从而使得被监听器保护的临界区代码必须从主内存中读取共享变量，从而实现共享变量的可见性。

Lock锁：使用Lock相关实现类也可以保证共享变量的可见性。其原理同synchronized。

原子操作类：原子类底层使用的是CAS机制。java中CAS机制每次都会从主内存中获取最新值进行compare，比较一致之后才会将新值set到主内存中去。而且这个操作是一个原子操作，所以CAS每次操作每次拿到的都是主内存中的最新值，每次set的值也会立即写到主内存中。

有序性：

程序执行的顺序按照代码的先后顺序执行。在JMM允许的重排序环境下，单线程的执行结果和没有重排序的情况下保持一致。JMM中提供一下方式来保证有序性：

happens-before原则：happens-before原则是java内存模型中定义的两项操作之间的偏序关系，如果操作A先行发生于操作B，也就是说发生操作B之前，操作A产生的影响能被操作B观察到。这里的“影响”包括修改共享变量，方法调用。详细的happens-before说明请参看happens-before原则章节。

synchronized机制：synchronized能够保证有序性是因为synchronized可以保证同一时间只有一个线程访问代码块，而单线程环境下，JMM能够保证代码的串行语义；虽然使用synchronized的代码块，还可以发生指令重排序，但是synchronized可以保证只有一个线程执行，所以最后的结果还是正确的。

volatile机制：volatile的底层是使用内存屏障（详细请参看内存屏障章节）来保障有序性的。写volatile变量时，可以确保volatile写之前的操作不会被编译器重排序到volatile写之后。读volatile变量时，可以确保volatile读之后的操作不会被编译器重排序到volatile读之前。

多线程面临的两个问题线程之间的通信和线程之间的同步,这两个问题如果仔细分析，从结果的角度看线程之间的通信就是可见性问题，线程之间的同步就是原子性和有序性的问题。

总结JMM对特性提供的支持如下：

4 happens-before原则

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

在《并发编程的艺术》一书中，对happens-before的定义如下：

在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在happens-before关系。这里提到的两个操作既可以是一个线程之内，也可以是不同线程之间。两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前。

happens-before规则如下：

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

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

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

start()规则（Thread Start Rule）：如果线程A执行线程B.start()(启动线程B），那么A线程的B.start()操作happens-before于线程B中的任意操作。

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

程序中断规则（Thread Interruption Rule）：对线程interrupt()的调用happens-before于被中断线程的interrupted()或者isInterrupted()。

finalizer规则（Finalizer Rule）：一个对象构造函数的结束happens-before于该对象finalizer()的开始。

传递性规则（Transitivity）：如果A happens-before B，且B happens-before C ，那么A happens-before C。

了解了happens-before原则，下面举例帮助理解：

private int value = 0;public void setValue(int value){    this.value = value;}public int getValue(){    return value;}

假设两个线程A和B，线程A先（在时间上先）调用了这个对象的setValue(1),接着线程B调用了getValue（）方法，那么B的返回值是多少？

对照happens-before原则，上面的操作不满下面的条件：

• 不是同一个线程，所以不涉及：程序顺序规则。

• 不涉及同步，所以不涉及：监视器锁规则。

• 没有volatile，所以不涉及：volatile变量规则。

• 没有线程的启动和中断，所以不涉及：start()规则，join规则，程序中断规则。

• 没有对象的创建和终结，所以不涉及：finalizer规则。

• 更没有传递规则。

所以，一条规则都不满足，尽管线程A在时间上与线程B具有先后顺序，但是，却不满足happens-before原则，也就是有序性并不会保障，所以线程B获取到的数据是不安全的！！！这也反向说明了happens-before原则提到的关系和时间的先后顺序没有关系。

时间先后顺序与先行发生原则之间基本没有太大关系，所以我们衡量并发安全问题的时候不要收到时间顺序的干扰，一切必须以先行发生原则为准。只有真正满足了happens-before原则，才能保证安全。

5 内存屏障

内存屏障（Memory Barrier），也称为内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以执行此点之后的操作。大多数现代计算机为了提高性能而采取乱序执行，这使得内存屏障成为必须。

语义上，内存屏障之前的所有写操作都要写入内存；内存屏障之后的读操作都可以获得同步屏障之前的写操作的结果。因此，对于敏感的程序块，写操作之后、读操作之前可以插入内存屏障。

CPU层面的内存屏障

CPU层面的内存屏障分为三类：

写屏障（Store Memory Barrier）：告诉处理器在写屏障之前的所有已经存储在存储缓存(store bufferes)中的数据同步到主内存，简单来说就是使得写屏障之前的指令的结果对写屏障之后的读或者写是可见的。

读屏障（Load Memory Barrier）：处理器在读屏障之后的读操作,都在读屏障之后执行。配合写屏障，使得写屏障之前的内存更新对于读屏障之后的读操作是可见的。

全屏障（Full Memory Barrier）：确保屏障前的内存读写操作的结果提交到内存之后，再执行屏障后的读写操作。

JMM层面的内存屏障

在JMM中将内存屏障分为四类：LoadLoad Barrier；StoreStore Barrier；LoadStore Barrier；StoreLoad Barrier，内存屏障的详细解释如下图8（图片来源于《并发编程艺术》）：

6 volatile的内存语义

volatile是java提供的一种轻量级的同步机制，在并发编程中，它也扮演着比较重要的角色。一方面volatile不会造成上下文切换的开销，另一方面它又不能像synchronized那样保证所有场景下线程安全，因此必须在合适的场景下使用volatile机制。前面一个章节，我们了解到volatile可以支持可见性和有序性，那么它是通过怎样的机制来实现这些特性的？其核心原理就是上一章节描述的内存屏障。

volatile写-读的内存语义

• 当写一个volatile变量时，JMM会把该线程对应的本地内存中的变量值刷新到主内存。

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

volatile内存语义的实现

为了实现volatile的内存语义，JMM会限制两种类型的重排序，下图是JMM针对编译器指定的volatile重排序规则表：

• 当第二个操作为volatile写操作时，不管第一个操作是什么，都不能进行重排序。这个规则确保volatile写之前的所有操作都不会被重排序到volatile写之后。

• 当第一个操作为volatile读操作时，不管第二个操作时什么，都不能进行重排序。这个规则确保volatile读之后的所有操作都不会被重排序到volatile读之前。

• 当第一个操作时volatile写操作时，第二个操作时读操作，不能进行重排序。

为了实现以上规则，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序，下面是基于保守策略（根据不同虚拟机策略不同）的JMM内存屏障插入策略：

• 在每个volatile写操作的前面插入一个StoreStore屏障（禁止前面的写与volatile写重排序）。

• 在每个volatile写操作的后面插入一个StoreLoad屏障（禁止volatile写与后面可能有的读和写重排序）。

• 在每个volatile读操作的后面插入一个LoadLoad屏障（禁止volatile读与后面的读操作重排序）。

• 在每个volatile读操作的后面插入一个LoadStore屏障（禁止volatile读与后面的写操作重排序）。

下图为volatile写操作插入内存屏障后生成的指令序列示意图。

上述volatile写和volatile读的内存屏障插入策略非常保守，在实际执行时，只要不改变volatile写-读的内存语义，编译器可以根据具体情况忽略不必要的屏障。

7 final的内存语义

在平时的开发过程中常常使用final关键字来修饰方法，保证方法不能被子类重写，那使用final修饰变量又表达什么内存语义呢？

final的内存语义

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

• 初次读取一个包含final域对象的引用，与随后初次读取这个final域，这两个操作之间不能重排序。

final的内存语义实现

• 写final域的重排序规则会要求编译器在final域写之后，构造函数返回之前，插入一个StoreStore屏障。

• 读final域的重排序规则会要求编译器在final域读之前插入一个LoadLoad屏障。