Java内存模型

引入Java内存模型

JVM内部使用的Java内存模型在线程栈与队之间划分内存，下图从逻辑角度展示Java内存模型：

堆栈里面都放了什么

（1）线程堆栈里面包含了正在执行的每个方法的所有局部变量（调用堆栈上的所有方法）。
（2）线程只能访问自己的线程堆栈，由于线程的局部变量对于创建它的线程意外的所有线程都是不可见，即使两个线程正在执行完全相同的代码，两个线程仍将在每个自己的线程堆栈中创建该代码的局部变量，因此，每个线程都有自己的每个局部变量的版本。
（3）基本类型的所有局部变(boolean,byte,short,char,int,long,float,double）完全存储在线程堆栈中，因此对其他线程不可见，一个线程可以将基本类型变量的副本传递给另一个线程，但它不能共享原始局部变量本身。
(4)堆中包含了在Java应用程序中创建的所有对象，无论创建该对象的线程是什么，这包含基本类型的包装类（例如：Integer,Long,Byte等）。
(5)无论是创建对象并将其分配给局部变量，还是创建另一个对象的成员变量，该对象仍然存储在堆上。
TIP:
（1）局部变量可以是基本类型，在这种情况下，它完全保留在线程堆栈上。
（2）局部变量也可以是对象的引用，在这种情况下，引用（局部变量）存储在线程堆栈中，但是对象本身存储在堆（Heap）上。
（3）对象的成员变量和对象本身一起存储在堆上，当成员变量是基本类型时，以及它时=是对象的引用时都是如此。
（4）静态类变量也与类定义一起存储在堆上。

线程栈如何访问堆上面的对象

所有具有对象引用的线程都可以访问堆上的对象，当一个线程有权访问一个对象时，它也可以访问该对象的成员变量，如果两个线程同时在同一个对象上调用一个方法，它们都可以访问该对象的成员变量,但每个线程都有自己的局部变量副本。

Java内存模型详解

并发编程模型分类

在并发编程中，需要处理的两个关键问题：
（1）线程之间如何通信？
通信是指线程之间以何种机制来交换信息，在命令式编程中，线程之间的通信机制又两种：共享内存和消息传递
-在共享内存的并发模型里，线程之间共享程序的公共状态，即线程之间通过写-读内存中的公共状态来隐式进行通信。
-在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式的进行通信。
（2）线程之间如何同步？
同步是指程序用于控制不同线程之间操作发生相对顺序的机制，在共享内存并发模型里，同步是显示进行的，程序员必须显示指定某个方法或某段代码需要在线程之间互斥执行，在消息传递的并发模型里面，由于消息的发送必须在消息的接受之前，因此同步是隐式进行的。
TIP:Java的并发采用的是共享内存模式，Java线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。

java内存模型的抽象（JMM）

在java中，所有实例域，静态域，数组元素（可以统称为共享变量）存储在堆内存中，堆内存在线程之间共享。
局部变量，方法定义参数和异常处理器参数不会在线程之间共享，它们不会存在内存可见性问题，也不受内存模型的影响。

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

从上图可知，线程A和线程B之间如果要通信，必须经历下面2个步骤：
（1）首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
（2）然后，线程B到主内存中去读取线程A之前已更新过的共享变量

重排序

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。
重排序分三种类型：
（1）编译器优化的重排序，编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
（2）指令级并行的重排序，现代处理器采用了指令级并行技术（ILP）来将多条指令重叠执行，如果不存在数据依赖性，处理器可以改变语句对应指令的执行顺序。
（3）内存系统的重排序，由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
从java源代码到最终实际执行的指令序列，会分别经理下面三种重排序

1是属于编译器重排序。
2和3是属于处理器重排序，这些重排序都可能会导致多线程程序出现内存可见性问题。
对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序。
(不是所有的编译器重排序都要禁止)
对于处理器重排序，JMM的处理器重排序规则要求Java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers）指令，通过内存屏障指令来禁止特定类型的处理器重排序。
(不是所有的处理器重排序都要禁止的)
JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供移植的内存可见性。

数据依赖性

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

写后读，写后写，读后写，这三种情况只要重排序两个操作的执行顺序，程序的执行结构将会被改变。
TIP:
编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
这里所说的数据依赖性仅针对单个处理器中执行的指令序列和当个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial 语义

as-if-serial 语义：就是不管怎么重排序(编译器和处理器为了提高并行度)，(单线程)程序的执行结果不能被改变，编译器，runtime和处理器都必须遵守as-if-serial 语义。
小知识：为什么编译器和处理器不会对存在数据依赖关系的操作做重排序？
因为要遵守as-if-serial 语义

程序顺序规则

根据happen-before的程序顺序规则
A happen-before B
B happen-before C
A happen-before C
这里的第三个happen-before关系，是根据happen-before的传递性推导出来的。
TIP：
在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因），但在多线程中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。

顺序一致性

数据竞争与顺序一致性保证
当程序为正确同步时，就会存在数据竞争。java内存模型规范对数据竞争的定义如下：
（1）在一个线程中写一个变量
（2）在另一个线程读同一个变量
（3）而且写和读没有通过同步来排序
当代码中包含数据竞争时，程序的执行往往产生违反直觉的结果，如果一个多线程程序能正确同步，这个程序将是一个没有数据竞争的程序。

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

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

常见的处理器都允许Store-Load重排序；
常见的处理器都不允许存在数据依赖的操作做重排序；
sparc-TSO和x86拥有相对较强的处理器内存模型，他们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）;
内存屏障
为了保证内存可见性，java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。
JMM把内存屏障指令分为下列四类:

StoreLoad Barriers会使该屏障之前的所有内存访问指令（存储和装置指令）完成之后，才执行该屏障之后的内存访问指令。
StoreLoad Barriers是一个全能型的屏障，它同时具有其他三个屏障的效果，现代的多处理器大都支持该屏障（其他类型的屏障不一定被所有处理器支持。）。
执行该屏障的开销会很大，因为当前处理器通常要把缓冲区中的数据全部刷新到内存中（buffer fully flush）。

happens-before

如果一个操作执行的结果需要对另一个操作可见，那么两个操作之间必须存在happens-before关系，这里提到的两个操作可以是在一个线程内，也可以是在不同线程之间。
常见的happens-before规则如下：
（1）程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
（2）对一个监视器锁的接受，happens-before于随后对这个监视器锁的加锁。
（3）volatile变量规则：对一个volatile域的写，happen-before于任意后续对这个volatile域的读。
（4）传递性：如果A happen-before B，且B happen-before C,那么A happen-before C。
注意，两个操作之间具有happens-before关系，并不意味着前一个操作必须在后以恶搞操作之前执行！happens-before仅仅要求前一个操作（执行结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前，happen-before的定义很微妙。

JMM总结

处理器内存模型

顺序一致性内存模型是一个理论参考模型，JMM和处理器内存模型在设计时通常会把顺序一致性内存作为参考。
JMM和处理器内存模型在设计时会对顺序一致性做一些放松，因为如果完全按照顺序一致性模型来实现处理器和JMM，那么很多的处理器和编译器优化都会被禁止，这会对执行性能产生很大影响。
根据对不同类型读/写操作组合的执行顺序的放松，可以把常见处理器的内存模型划分为下面几种类型：
（1）放松程序中写-读操作的顺序，由此产生了total store ordering内存模型（简称TSO）
（2）在前面1的基础上，继续放松程序中写写操作的顺序，由此产生了partial store order 内存模型（简称PSO）
（3）在前面1和2的基础上，继续放松程序中读-写和读-读操做的顺序，由此产生了relaxed memory order内存模型（简称RMO）和PowerPC内存模型
TIP：
这里处理器对读/写的放松，是以两个操作之间不存在数据依赖性为前提（因为处理器要遵守as-if-serial语义，处理器不会对存在数据依赖性的两个内存操作做重排序）。

JMM,处理器内存模型与顺序一致性内存模型之间的关系

JMM是一个语言级的内存模型，处理器内存模型是硬件级的内存模型，顺序一致性内存模型是一个理论参考模型。

JMM对于不同性质的重排序，采取了不同的策略

对于会改变程序执行结果的重排序，JMM要求编译器和处理器必须禁止这种重排序。
对于不会改变程序执行结果的重排序，JMM对编译器和处理器不做要求（JMM允许这种重排序）。

JMM向程序原提供的happens-before规则能满足程序员的需求

JMM对编译器和处理器的约束已经尽可能的少了，JMM其实是在遵循一个基本原则，只要不改变程序的执行结果（指单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。
例如：如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除，再比如，如果编译器经过细致的分析后，认定一个volatile变量仅仅只会被单个线程访问，那么编译器可以把这个volatile变量当作一个普通变量来对待，这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

JMM 的内存可见性保证

Java程序的内存可见性保证按程序类型分为下列三类：
（1）单线程程序：单线程程序不会出现内存可见性问题，编译器，runtime和处理器会共同确保单线程程序的执行结果与该线程在顺序一致性模型中的执行结果相同。
（2）正确同步的多线程程序：正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）
JMM需要关注的重点：JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证的.
（3）未同步/未正确同步的多线程程序。JMM为他们提供了最小安全性保障；线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0，null,false）。