【JMM】Java内存模型
什么是JMM
先上图
Java内存模型(Java Memory Model简称JMM)是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段 和构成数组对象的元素）的访问方式。
java内存模型跟cpu内存模型类似，是基于cpu缓存模型来建立的，java线程内存模型是标准化的，屏蔽掉了底层不同计算机的区别。
JMM与JVM内存模型的不同
JMM与JVM内存区域的划分是不同的概念层次。更恰当的说，JMM描述的是一组规则，通过这组规则控制程序中各个变量在共享数据区域和私有数据区域的访问方式，JMM是围绕原子性、有序性、可见性展开。
JMM中的主内存，从某个程度上讲，应该包含了JVM中的堆和方法区；而工作内存，则应该包含了程序计数器、虚拟机栈、本地方法栈。
JMM工作原理
java多线程调用变量时，并不是直接操作主内存中的变量，而是将主内存中的变量由JMM控制复制到自身线程的工作内存中，建立并操作副本。
- 主内存：
主内存中主要存储的是JAVA实例变量，所有线程创建的实例对象都存放在主内存中，不管该实例对象是成员变量还是方法中的本地变量(也称局部变量，这里指的是非基本数据类型的局部变量！！)，当然也包括了共享的类信息，常量，静态变量。由于是共享数据区域，多条线程对同一个变量进行访问可能会发生线程安全问题。 - 工作内存：
工作内存中主要存储当前方法的所有本地变量信息(也就是主内存中的变量的拷贝副本)。每个线程只会访问自己的工作内存，即线程中的数据副本对其他线程是不可见的，因此工作内存中的数据是不存在线程安全问题的。
所以，又回到了上文所说的：JMM中的主内存，从某个程度上讲，应该包含了JVM中的堆和方法区；而工作内存，则应该包含了程序计数器、虚拟机栈、本地方法栈。
这里引入一个知识点：为什么非基本数据类型的局部变量存放在主内存中？那么基本数据类型的局部变量又存放在哪？
非基本数据类型(引用类型)的局部变量对象实例，是存放在堆中，而栈帧中的局部变量表存放的是该变量的引用。而基本数据类型的局部变量，会直接存放在栈帧中的局部变量表中，所以也就是工作内存中。但是对于实例变量来说，不管它是基本数据 类型或者包装类型(Integer、Double等)还是引用类型，都会被存储到堆区。
JMM的八大原子性操作
- lock(锁定)：作用于主内存的变量，把一个变量标记为一条线程独占状态
- unlock(解锁)：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
- read(读取)：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存 中，以便随后的load动作使用
- load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
- use(使用)：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎
- assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量
- store(存储)：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作
- write(写入)：作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中
主内存与工作内存之间的同步规则
1、不允许在没有发生任何assign操作，把数据从工作内存同步回主内存。
2、一个新的变量只能从主内存中产生，对一个变量实施use和store之前，必须先执行load和assign操作。
3、一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一线程重复执行多次，执行多次lock后，必须执行同样次数的unlock才能对其解锁。
4、对一个变量执行lock，将会清空工作内存中此变量的值，在执行引擎使用这个变量之前，需要重新执行load和assign操作初始化变量的值。
5、如果一个变量事先没有被lock，则不许对它执行unlock；也不允许unlock一个被其他线程加锁的变量。
6、对一个变量执行unlock之前，必须先把此变量同步到主内存中（执行store和write）
JMM如何解决原子性、可见性、有序性的问题
并发编程中的原子性、可见性、有序性问题
原子性：
原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。 在java中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元， 这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数 据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道这么回事即可。
可见性
理解了指令重排现象后，可见性容易了，可见性指的是当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。
对于串行程序来说，可见性是不存在的， 因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改过的新值。 但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确 实会导致程序轮序执行的问题，从而也就导致可见性问题。
有序性
有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象。
JMM是如何解决原子性、可见性、有序性的问题的
- 原子性问题：
除了JVM自身提供的对基本数据类型读写操作的原子性外，可以通过 synchronized和Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码块。 - 可见性问题：
volatile关键字保证可见性。当一个共享变量被volatile修饰时，它会保证修改的值立即被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取新值。synchronized和Lock也可以保证可见性，因为它们可以保证任一时刻只有一个线程能访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。 - 有序性问题：
- volatile关键字保证有序性。volatile可以禁止指令重排序。
- 另外可以通过synchronized和Lock来保证有序性，很显然， synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行 同步代码，自然就保证了有序性。
- 为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序， 因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。
- as-if-serial语义：as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。
- Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为happens-before原则。如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它们进行重排序。
- happens-before原则：
- 程序顺序原则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执 行。
- 锁规则，解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)。
- volatile规则，volatile变量的写，先发生于读，这保证了volatile变量的可见性，简单的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值，而当该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的 线程总是能够看到该变量的最新值。
- 线程启动规则，线程的start()方法先于它的每一个动作，即如果线程A在执行线程B的start方法之前修改了共享变量的值，那么当线程B执行start方法时，线程A对共享变量的修改对线程B可见
- 传递性，A先于B ，B先于C，那么A必然先于C
- 线程终止规则，线程的所有操作先于线程的终结，Thread.join()方法的作用是等待当前执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的join方法成功返回后，线程B对共享变量的修改将对线程A可见。
- 线程中断规则，对线程 interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断。
- 对象终结规则，对象的构造函数执行，结束先于finalize()方法。
volatile
volatile是Java虚拟机提供的轻量级的同步机制。volatile关键字有如下两个作用：
1、线程可见性：
Volatile 保证了线程间共享变量的及时可见性，但不能保证原子性。
可见性也就是说一旦某个线程修改了该被volatile修饰的变量，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，可以立即获取修改之后的值。
2、禁止指令重排
底层实现主要是通过汇编lock前缀指令（volatile在底层汇编语言，在前缀加了lock），它会锁定这块内存区域的缓存（缓存行锁定）并回写到主内存。
IA-32架构软件开发手册对lock指令的解释：
1）会将当前处理器缓存行的数据立即写回到系统内存
2）这个写回内存的操作会引起在其他CPU里缓存了该内存地址的数据无效（MESI协议）