【Todo】【转载】深刻理解Java内存模型

提纲挈领地说一下Java内存模型：

什么是Java内存模型

Java内存模型定义了一种多线程访问Java内存的规范。Java内存模型要完整讲不是这里几句话能说清楚的，我简单总结一下Java内存模型的几部份内容：

（1）Java内存模型将内存分为了 主内存和工做内存 。类的状态，也就是类之间共享的变量，是存储在主内存中的，每次Java线程用到这些主内存中的变量的时候，会读一次主内存中的变量，并让这些内存在本身的工做内存中有一份拷贝，运行本身线程代码的时候，用到这些变量，操做的都是本身工做内存中的那一份。在线程代码执行完毕以后，会将最新的值更新到主内存中去

（2）定义了几个原子操做，用于操做主内存和工做内存中的变量

（3）定义了volatile变量的使用规则

（4）happens-before，即先行发生原则，定义了操做A必然先行发生于操做B的一些规则，好比在同一个线程内控制流前面的代码必定先行发生于控制流后面的代码、一个释放锁unlock的动做必定先行发生于后面对于同一个锁进行锁定lock的动做等等。

这一句没懂：（只要符合这些规则，则不须要额外作同步措施，若是某段代码不符合全部的happens-before规则，则这段代码必定是线程非安全的）

 

 

参考Infoq上的这篇文章：Link

《深刻理解Java内存模型（一）——基础》

 

并发编程模型的分类

在并发编程中，咱们须要处理两个关键问题：线程之间如何通讯及线程之间如何同步（这里的线程是指并发执行的活动实体）。通讯是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通讯机制有两种：共享内存和消息传递。

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

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

 

同步是指程序用于控制不一样线程之间操做发生相对顺序的机制。

在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码须要在线程之间互斥执行。

在消息传递的并发模型里，因为消息的发送必须在消息的接收以前，所以同步是隐式进行的。

 

Java的并发采用的是共享内存模型，Java线程之间的通讯老是隐式进行，整个通讯过程对程序员彻底透明。若是编写多线程程序的Java程序员不理解隐式进行的线程之间通讯的工做机制，极可能会遇到各类奇怪的内存可见性问题。

原生Java线程之间只能经过共享内存(同一个虚拟机内)来通讯，固然你能够经过本身实现，使得线程看起来能够经过消息通讯（好比Scala的Actor）
能够经过消息传递，但Actor自己和线程是有很大不一样，不过看起来具有了一些线程功能 。

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个步骤：

1. 首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
2. 而后，线程B到主内存中去读取线程A以前已更新过的共享变量。

下面经过示意图来讲明这两个步骤

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

 

重排序

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

1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，能够从新安排语句的执行顺序。
2. 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。若是不存在数据依赖性，处理器能够改变语句对应机器指令的执行顺序。
3. 内存系统的重排序。因为处理器使用缓存和读/写缓冲区，这使得加载和存储操做看上去多是在乱序执行。

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

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

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

 

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

现代的处理器使用写缓冲区来临时保存向内存写入的数据。

写缓冲区能够保证指令流水线持续运行，它能够避免因为处理器停顿下来等待向内存写入数据而产生的延迟。
同时，经过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的屡次写，能够减小对内存总线的占用。

虽然写缓冲区有这么多好处，但每一个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操做的执行顺序产生重要的影响：处理器对内存的读/写操做的执行顺序，不必定与内存实际发生的读/写操做顺序一致！

为了具体说明，请看下面示例：

 

Processor A	Processor 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的内存操做顺序被重排序了。

这里的关键是，因为写缓冲区仅对本身的处理器可见，它会致使处理器执行内存操做的顺序可能会与内存实际的操做执行顺序不一致。因为现代的处理器都会使用写缓冲区，所以现代的处理器都会容许对写-读操作重排序。

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

	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 Barriers	Load1; LoadLoad; Load2	确保Load1数据的装载，以前于Load2及全部后续装载指令的装载。
StoreStore Barriers	Store1; StoreStore; Store2	确保Store1数据对其余处理器可见（刷新到内存），以前于Store2及全部后续存储指令的存储。
LoadStore Barriers	Load1; LoadStore; Store2	确保Load1数据装载，以前于Store2及全部后续的存储指令刷新到内存。
StoreLoad Barriers	Store1; 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提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现。

 

注：以上happens-before规则，指的就是程序员不用去管底层的重排序规则，哪些被禁止了哪些还生效，只须要知道上面4类规则一直是生效的，而且应用于代码中，就能够了。

 

继续。以上这个文章系列的电子版已经下载：

/Users/baidu/Documents/Data/Interview/Java/think_deep_in_java_mem_model.pdf

可是电子版复制粘贴不方便，因此仍是在Infoq原文中看。

 

开始看第二篇：http://www.infoq.com/cn/articles/java-memory-model-2    （完整的系列，点做者名字就能看到）

数据依赖性

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

 

名称	代码示例	说明
写后读	a = 1;b = a;	写一个变量以后，再读这个位置。
写后写	a = 1;a = 2;	写一个变量以后，再写这个变量。
读后写	a = b;b = 1;	读一个变量以后，再写这个变量。

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

前面提到过，编译器和处理器可能会对操做作重排序。编译器和处理器在重排序时，会遵照数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操做的执行顺序。

注意，这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操做，不一样处理器之间和不一样线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial语义

as-if-serial语义的意思指：无论怎么重排序（编译器和处理器为了提升并行度），（单线程）程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵照as-if-serial语义。

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

下图是该程序的两种执行顺序：

程序顺序规则

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

1. A happens- before B；
2. B happens- before C；
3. A happens- before C；

这里A happens- before B，但实际执行时B却能够排在A以前执行（看上面的重排序后的执行顺序）。在第一章提到过，若是A happens- before B，JMM并不要求A必定要在B以前执行。JMM仅仅要求前一个操做（执行的结果）对后一个操做可见，且前一个操做按顺序排在第二个操做以前。这里操做A的执行结果不须要对操做B可见；并且重排序操做A和操做B后的执行结果，与操做A和操做B按happens- before顺序执行的结果一致。在这种状况下，JMM会认为这种重排序并不非法（not illegal），JMM容许这种重排序。

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

 

 

重排序对多线程的影响(这个例子挺重要，可以加深对重排序的理解)

如今让咱们来看看，重排序是否会改变多线程程序的执行结果。请看下面的示例代码：

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

// 线程A执行
public void writer() {
    a = 1;                   //1
    flag = true;             //2
}

// 线程B执行
Public void reader() {
    if (flag) {                //3
        int i =  a * a;        //4
        ……
    }
}
}

在单线程程序中，对存在控制依赖的操做重排序，不会改变执行结果（这也是as-if-serial语义容许对存在控制依赖的操做作重排序的缘由）；

但在多线程程序中，线程A和B分别执行上面这两个函数，对存在控制依赖的操做重排序，可能会改变程序的执行结果。

 

因为操做1和操做2没有数据依赖关系，编译器和处理器能够对这两个操做重排序；

一样，操做3和操做4没有数据依赖关系（只有控制依赖关系，会用预存关系，下面有详细介绍），编译器和处理器也能够对这两个操做重排序。

 

让咱们先来看看，当操做1和操做2重排序时，可能会产生什么效果？请看下面的程序执行时序图：

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

 

下面再让咱们看看，当操做3和操做4重排序时会产生什么效果（借助这个重排序，能够顺便说明控制依赖性）。下面是操做3和操做4重排序后，程序的执行时序图：

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

从图中咱们能够看出，猜想执行实质上对操做3和4作了重排序。重排序在这里破坏了多线程程序的语义！

 

下一篇《深刻理解Java内存模型（三）——顺序一致性》（全系列能够点做者名进入）

http://www.infoq.com/cn/articles/java-memory-model-3

数据竞争与顺序一致性保证

顺序一致性内存模型有两大特性：

• 一个线程中的全部操做必须按照程序的顺序来执行。
• （无论程序是否同步）全部线程都只能看到一个单一的操做执行顺序。在顺序一致性内存模型中，每一个操做都必须原子执行且马上对全部线程可见。

可是，在JMM中就没有这个保证。未同步程序在JMM中不但总体的执行顺序是无序的，并且全部线程看到的操做执行顺序也可能不一致。好比，在当前线程把写过的数据缓存在本地内存中，且尚未刷新到主内存以前，这个写操做仅对当前线程可见；从其余线程的角度来观察，会认为这个写操做根本尚未被当前线程执行。只有当前线程把本地内存中写过的数据刷新到主内存以后，这个写操做才能对其余线程可见。在这种状况下，当前线程和其它线程看到的操做执行顺序将不一致。

 

这一篇不太好懂。先看下面一篇吧。

http://www.infoq.com/cn/articles/java-memory-model-4

 

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变量的单个读/写操做，与对一个普通变量的读/写操做使用同一个监视器锁来同步，它们之间的执行效果相同。

监视器锁的happens-before规则保证释放监视器和获取监视器的两个线程之间的内存可见性，这意味着对一个volatile变量的读，老是能看到（任意线程）对这个volatile变量最后的写入。

 

监视器锁的语义决定了临界区代码的执行具备原子性。这意味着即便是64位的long型和double型变量，只要它是volatile变量，对该变量的读写就将具备原子性。若是是多个volatile操做或相似于volatile++这种复合操做，这些操做总体上不具备原子性。

简而言之，volatile变量自身具备下列特性：

• 可见性：对一个volatile变量的读，老是能看到（任意线程）对这个volatile变量最后的写入。
• 原子性：对任意单个volatile变量的读/写具备原子性，但相似于volatile++这种复合操做不具备原子性。

 

volatile写-读创建的happens before关系

上面讲的是volatile变量自身的特性，对程序员来讲，volatile对线程的内存可见性的影响比volatile自身的特性更为重要，也更须要咱们去关注。

从JSR-133开始，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 关系能够分为两类：

1. 根据程序次序规则，1 happens before 2; 3 happens before 4。
2. 根据volatile规则，2 happens before 3。
3. 根据happens before 的传递性规则，1 happens before 4。

上述happens before 关系的图形化表现形式以下：

在上图中，每个箭头连接的两个节点，表明了一个happens before 关系。黑色箭头表示程序顺序规则；橙色箭头表示volatile规则；蓝色箭头表示组合这些规则后提供的happens before保证。

这里A线程写一个volatile变量后，B线程读同一个volatile变量。A线程在写volatile变量以前全部可见的共享变量，在B线程读同一个volatile变量后，将当即变得对B线程可见。

 (注意：happens-before不必定被JMM实现，可是volatile的happens-before被实现了，见后文)

 

volatile写-读的内存语义

volatile写的内存语义以下：

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

以上面示例程序VolatileExample为例，假设线程A首先执行writer()方法，随后线程B执行reader()方法，初始时两个线程的本地内存中的flag和a都是初始状态。下图是线程A执行volatile写后，共享变量的状态示意图：

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

volatile读的内存语义以下：

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

下面是线程B读同一个volatile变量后，共享变量的状态示意图：

如上图所示，在读flag变量后，本地内存B已经被置为无效。此时，线程B必须从主内存中读取共享变量。线程B的读取操做将致使本地内存B与主内存中的共享变量的值也变成一致的了。

若是咱们把volatile写和volatile读这两个步骤综合起来看的话，在读线程B读一个volatile变量后，写线程A在写这个volatile变量以前全部可见的共享变量的值都将当即变得对读线程B可见。

下面对volatile写和volatile读的内存语义作个总结：

• 线程A写一个volatile变量，实质上是线程A向接下来将要读这个volatile变量的某个线程发出了（其对共享变量所在修改的）消息。
• 线程B读一个volatile变量，实质上是线程B接收了以前某个线程发出的（在写这个volatile变量以前对共享变量所作修改的）消息。
• 线程A写一个volatile变量，随后线程B读这个volatile变量，这个过程实质上是线程A经过主内存向线程B发送消息。

 

volatile内存语义的实现

下面，让咱们来看看JMM如何实现volatile写/读的内存语义。

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

是否能重排序	第二个操做
第一个操做	普通读/写	volatile读	volatile写
普通读/写			NO
volatile读	NO	NO	NO
volatile写		NO	NO

举例来讲，第三行最后一个单元格的意思是：在程序顺序中，当第一个操做为普通变量的读或写时，若是第二个操做为volatile写，则编译器不能重排序这两个操做。

从上表咱们能够看出：

• 当第二个操做是volatile写时，无论第一个操做是什么，都不能重排序。这个规则确保volatile写以前的操做不会被编译器重排序到volatile写以后。
• 当第一个操做是volatile读时，无论第二个操做是什么，都不能重排序。这个规则确保volatile读以后的操做不会被编译器重排序到volatile读以前。
• 当第一个操做是volatile写，第二个操做是volatile读时，不能重排序。

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

• 在每一个volatile写操做的前面插入一个StoreStore屏障。
• 在每一个volatile写操做的后面插入一个StoreLoad屏障。
• 在每一个volatile读操做的后面插入一个LoadLoad屏障。
• 在每一个volatile读操做的后面插入一个LoadStore屏障。

 

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

下面是保守策略下，volatile写插入内存屏障后生成的指令序列示意图：

上图中的StoreStore屏障能够保证在volatile写以前，其前面的全部普通写操做已经对任意处理器可见了。这是由于StoreStore屏障将保障上面全部的普通写在volatile写以前刷新到主内存。

这里比较有意思的是volatile写后面的StoreLoad屏障。这个屏障的做用是避免volatile写与后面可能有的volatile读/写操做重排序。由于编译器经常没法准确判断在一个volatile写的后面，是否须要插入一个StoreLoad屏障（好比，一个volatile写以后方法当即return）。为了保证能正确实现volatile的内存语义，JMM在这里采起了保守策略：在每一个volatile写的后面或在每一个volatile读的前面插入一个StoreLoad屏障。从总体执行效率的角度考虑，JMM选择了在每一个volatile写的后面插入一个StoreLoad屏障。由于volatile写-读内存语义的常见使用模式是：一个写线程写volatile变量，多个读线程读同一个volatile变量。当读线程的数量大大超过写线程时，选择在volatile写以后插入StoreLoad屏障将带来可观的执行效率的提高。从这里咱们能够看到JMM在实现上的一个特色：首先确保正确性，而后再去追求执行效率。

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

上图中的LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。

上述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()方法，编译器在生成字节码时能够作以下的优化：

 

注意，最后的StoreLoad屏障不能省略。由于第二个volatile写以后，方法当即return。此时编译器可能没法准确判定后面是否会有volatile读或写，为了安全起见，编译器经常会在这里插入一个StoreLoad屏障。

上面的优化是针对任意处理器平台，因为不一样的处理器有不一样“松紧度”的处理器内存模型，内存屏障的插入还能够根据具体的处理器内存模型继续优化。以x86处理器为例，上图中除最后的StoreLoad屏障外，其它的屏障都会被省略。

 

前面保守策略下的volatile读和写，在 x86处理器平台能够优化成：

前文提到过，x86处理器仅会对写-读操做作重排序。X86不会对读-读，读-写和写-写操做作重排序，所以在x86处理器中会省略掉这三种操做类型对应的内存屏障。在x86中，JMM仅需在volatile写后面插入一个StoreLoad屏障便可正确实现volatile写-读的内存语义。这意味着在x86处理器中，volatile写的开销比volatile读的开销会大不少（由于执行StoreLoad屏障开销会比较大）。

 

第五篇：锁

http://www.infoq.com/cn/articles/java-memory-model-5

 

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从总体来看，concurrent包的实现示意图以下：

 

 

也能够结合这篇看：Java Synchronized和ReentrantLock的比较：http://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html

 

 

 

另有这个序列也讲的不错：

《同步和Java内存模型》

目录

1. 引言
2. 原子性
3. 可见性
4. 有序性
5. Volatile