Java JMM

JMM简介

JMM：Java Memory Model(Java内存模型)，围绕着在并发过程中如何处理可见性、原子性、有序性这三个特性而建立的模型。

可见性：JMM提供了volatile变量定义、final、synchronized块来保证可见性。
例如：线程a在将共享变量x=1写入主内存的时候，如何保证线程b读取共享变量x的值为1，这就是JMM做的事情。JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证。

原子性：JMM提供保证了访问基本数据类型的原子性（其实在写一个工作内存变量到主内存是分主要两步：store、write），但是实际业务处理场景往往是需要更大的范围的原子性保证，所以模型也提供了synchronized块来保证

有序性：这个概念是相对而言的，如果在本线程内，所有的操作都是有序的，如果在一个线程观察另一个线程，所有的操作都是无序的，前句是“线程内表现为串行行为”，后句是“指令的重排序”和“工作内存和主内存同步延迟”现象，模型提供了volatile和synchronized来保证线程之间操作的有序性。

重排序：在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序(编译器、处理器)，就是因为这些重排序，所以可能会导致多线程程序出现内存可见性问题(数据安全问题)和有序性问题。
JMM是如何处理的呢？
对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序
对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel称之为memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序
总之一句话，JMM是通过禁止特定类型的编译器重排序和处理器重排序来为程序员提供一致的内存可见性保证。

A线程具体什么时候刷新共享数据到主内存是不确定的，假设我们使用了同步原语(synchronized，volatile和final),那么刷新的时间是确定的，例如：线程A释放锁后会同步到主内存，线程B获取锁后会同步主内存数据
即“A线程释放锁--B线程获取锁”可以实现A，B线程之间的通信

指令重排序及Happens-before法则

指令重排序

对主存的一次访问一般花费硬件的数百次时钟周期。处理器通过缓存（caching）能够从数量级上降低内存延迟的成本这些缓存为了性能重新排列待定内存操作的顺序。也就是说，程序的读写操作不一定会按照它要求处理器的顺序执行。

重排序的背景

我们知道现代CPU的主频越来越高，与cache的交互次数也越来越多。当CPU的计算速度远远超过访问cache时，会产生cache wait，过多的cache  wait就会造成性能瓶颈。
针对这种情况，多数架构（包括X86）采用了一种将cache分片的解决方案，即将一块cache划分成互不关联地多个 slots (逻辑存储单元，又名 Memory Bank 或 Cache Bank)，CPU可以自行选择在多个 idle bank 中进行存取。这种 SMP 的设计，显著提高了CPU的并行处理能力，也回避了cache访问瓶颈。

Memory Bank的划分
一般 Memory bank 是按cache address来划分的。比如 偶数adress 0×12345000 分到 bank 0, 奇数address 0×12345100 分到 bank1。

重排序的种类
编译期重排。编译源代码时，编译器依据对上下文的分析，对指令进行重排序，以之更适合于CPU的并行执行。

运行期重排，CPU在执行过程中，动态分析依赖部件的效能，对指令做重排序优化。

Java语言规范规定了JVM线程内部维持顺序化语义，也就是说只要程序的最终结果等同于它在严格的顺序化环境下的结果，那么指令的执行顺序就可能与代码的顺序不一致。这个过程通过叫做指令的重排序。指令重排序存在的意义在于：JVM能够根据处理器的特性（CPU的多级缓存系统、多核处理器等）适当的重新排序机器指令，使机器指令更符合CPU的执行特点，最大限度的发挥机器的性能。

程序执行最简单的模型是按照指令出现的顺序执行，这样就与执行指令的CPU无关，最大限度的保证了指令的可移植性。这个模型的专业术语叫做顺序化一致性模型。但是现代计算机体系和处理器架构都不保证这一点（因为人为的指定并不能总是保证符合CPU处理的特性）。

我们来看最经典的一个案例。

package  xylz.study.concurrency.atomic; 

public   class  ReorderingDemo  { 

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

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

        for (int i = 0; i < 100; i++) {
            x=y=a=b=0;
            Thread one = new Thread() {
                public void run() {
                    a = 1;
                    x = b;
                }
            };
            Thread two = new Thread() {
                public void run() {
                    b = 1;
                    y = a;
                }
            };
            one.start();
            two.start();
            one.join();
            two.join();
            System.out.println(x + " " + y);
        }
    } 

}

在这个例子中one/two两个线程修改区x,y,a,b四个变量，在执行100次的情况下，可能得到(0 1)或者（1 0）或者（1 1）。事实上按照JVM的规范以及CPU的特性有很可能得到（0 0）。当然上面的代码大家不一定能得到（0 0），因为run()里面的操作过于简单，可能比启动一个线程花费的时间还少，因此上面的例子难以出现（0,0）。但是在现代CPU和JVM上确实是存在的。由于run()里面的动作对于结果是无关的，因此里面的指令可能发生指令重排序，即使是按照程序的顺序执行，数据变化刷新到主存也是需要时间的。假定是按照a=1;x=b;b=1;y=a;执行的，x=0是比较正常的，虽然a=1在y=a之前执行的，但是由于线程one执行a=1完成后还没有来得及将数据1写回主存（这时候数据是在线程one的堆栈里面的），线程two从主存中拿到的数据a可能仍然是0（显然是一个过期数据，但是是有可能的），这样就发生了数据错误。

在两个线程交替执行的情况下数据的结果就不确定了，在机器压力大，多核CPU并发执行的情况下，数据的结果就更加不确定了。

Happens-before法则

Java的内存结构如下

如果多线程之间不共享数据，这也表现得很好，但是如果多线程之间要共享数据，那么这些乱序执行，数据在寄存器中这些行为将导致程序行为的不确定性，现在处理器已经是多核时代了，这些问题将会更加严重，每个线程都有自己的工作内存，多个线程共享主内存，如图

 

如果共享数据，什么时候同步到主内存让别人的线程读取数据呢？这又是不确定的，如果非要一致，那么代价高昂，这将牺牲处理器的性能，所以现在的处理器会牺牲存储一致性来换取性能，如果程序要确保共享数据的时候获得一致性，处理器通常了提供了一些关卡指令，这个可以帮助程序员来实现，但是各种处理器都不一样，如果要使程序能够跨平台是不可能的，怎么办？

 

使用Java,由JMM（Java Memeory Model Action）来屏蔽，我们只要和JMM的规定来使用一致性保证就搞定了，那么JMM又提供了什么保证呢？JMM的定义是通过动作的形式来描述的，所谓动作，包括变量的读和写，监视器加锁和释放锁，线程的启动和拼接，这就是传说中的happen before,要想A动作看到B动作的结果，B和A必须满足happen before关系,happen before法则如下：

1， 程序次序法则，如果A一定在B之前发生，则happen before,

2， 监视器法则,对一个监视器的解锁一定发生在后续对同一监视器加锁之前

3， Volatie变量法则：写volatile变量一定发生在后续对它的读之前

4， 线程启动法则：Thread.start一定发生在线程中的动作

5， 线程终结法则：线程中的任何动作一定发生在括号中的动作之前（其他线程检测到这个线程已经终止，从Thread.join调用成功返回，Thread.isAlive()返回false）

6， 中断法则：一个线程调用另一个线程的interrupt一定发生在另一线程发现中断。

7， 终结法则：一个对象的构造函数结束一定发生在对象的finalizer之前

8， 传递性：A发生在B之前，B发生在C之前，A一定发生在C之前。