Java 内存模型(JMM)

什么是JMM模型

Java内存模型(Java Memory Model简称JMM)是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。

JVM运行程序的实体是线程，而每个线程创建时,JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据。

Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中的变量副本拷贝。

JMM和JVM的区别

• JMM是围绕原子性，有序性、可见性展开。
• JMM与Java内存区域唯一相似点，都存在共享数据区域和私有数据区域，在JMM中主内存属于共享数据区域，从某个程度上讲应该包括了堆和方法区，而工作内存数据线程私有数据区域，从某个程度上讲则应该包括程序计数器、虚拟机栈以及本地方法栈。

主内存和工作内存

1. 主内存

主要存储的是Java实例对象，所有线程创建的 实例对象都存放在主存中，不管该实例对象时成员边浪还是方法中的本地变量，当然还包含共享的类信息、常量、静态 变量。由于是共享数据区域，多条线程对同一个变量进行访问可能会发生线程安全问题。

2. 工作内存

• 主要存储当前方法的所有本地变量(工作内存中存储着主内存中的变量副本拷贝),每个线程只能访问自己的工作内存，即线程中的本地变量对其他线程是不可见的，就算是两个线程执行的是同一段代码，它们也会各自在自己的工作内存中创建属于当前线程的本地变量，当然也包括了字节码行号指示器、相关Native方法的信息。
• 由于工作内存是每个线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安全问题。
• 根据JVM 虚拟机规范主内存与工作内存的数据存储类型以及操作方式，对于一个实例对象中的成员方法而言，如果方法中包含本地变量是基本类型，将直接存储在工作内存的栈帧结构中，但倘若本地变量是引用类型，那么该变量的引用会存储在工作内存的栈帧中，而对象实例将存储在主内存(共享内存区域，堆中)。
• 但对于实例对象的成员变量，不管它是基本数据类型或者包装类型还是引用类型，都会存储在堆中。
• 至于static变量以及类本身相关信息将会存储在主内存中。
• 在主内存中的实例对象可以被多线程共享，倘若两个线程同时调用了同一对象的同一方法，那么两条线程会将要操作的数据拷贝一份到自己的工作内存中，执行完成操作后才刷新到主内存中。

Java内存模型与硬件内存架构的关系

对于硬件内存来说只有寄存器、缓存内存、主内存的概念，并没有工作内存之分，也就是说Java内存模型对内存的划分对硬件内存并没有任何影响，因为JMM只是一种抽象的概念，是一组规则，并不实际存在,不管是工作内存的数据还是主 内存的数据，对于计算机硬件来说都会存储在计算机主内存中，当然也有可能存储在到CPU缓存或者寄存器中

因此总体上来 说，Java内存模型和计算机硬件内存架构是一个相互交叉的关系，是一种抽象概念划分与真实物理硬件的交互。

JMM存在的必要性

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据，线程与主内存中的变量操作必须通过工作内存间接完成，主要过程是将变量从主内存拷贝的每个线程各自的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，如果存在两个线程同时对一个主内存中的实例对象的变量进行操作就有可能诱发线程安全问题。

假设主内存中存在一个共享变量X，现在有A和B两条线程分别对该变量x=1进行操作，A和B线程各自在自己的工作内存中存在共享变量副本X.

假设现在A线程想要修改x的值 为2，而B线程却想要读取X的值，那么B线程读取到的值是A线程更新后的值2还是更新前的值1呢？答案是不确定，即B线程 有可能读取到A线程更新前的值1，也有可能读取到A 线程更新后的值2，这是因为工作内存是每个线程私有的数据区域，而线程A变量x时，首先是讲变量从主内存拷贝到A线程的工作内存中，然后对变量进行操作，操作完成 后再将变量X写回主内存中，而对于B线程也是类似，这样就有可能造成主内存与工作内存间数据存在不一致性问题。

假设A线程修改完成后正在将数据写回主内存，而B线程此时正在读取主内存，即将x=1拷贝到自己的工作呢次云中，这样B线程读取的值就是x=1,但如果A线程已将x=2写回主内存后，B线程才开始读取的话，那么此时B线程读取的就是x=2，但到底是哪种情况先发生呢？

JMM数据同步八大原子操作

（1）lock(锁定)：作用于主内存的变量，把一个变量标记为一条线程独占状态

（2）unlock(解锁)：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
（3）read(读取)：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用。
（4）load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
（5）use(使用)：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎。
（6）assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量。
（7）store(存储)：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
（8）write(写入)：作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中。

CPU缓存一致性协议MESI

为什么要有高速缓存？

• CPU在摩尔定律的指导下以每18个月翻一番的速度在发展，然而内存和硬盘的发展速度远远不及CPU。这就造成了高性能能的内存和硬盘价格及其昂贵。然而CPU的高度运算需要高速的数据。为了解决这个问题，CPU厂商在CPU中内置了少量的高速缓存以解决I\O速度和CPU运算速度之间的不匹配问题。在CPU访问存储设备时，无论是存取数据抑或存取指令，都趋于聚集在一片连续的区域中，这就被称为局部性原理。

• 时间局部 性

  如果一个信息项正在被访问，那么在近期它很可能还会被再次访问。比如循环、递归、方法的反复调用等。

• 空间局部性

  如果一个存储器的位置被引用，那么将来他附近的位置也会被引用。比如顺序执行的代码、连续创建的两个对象、数组等。

带有高速缓存的CPU执行计算的流程

1.程序以及数据被加载到主内存
2.指令和数据被加载到CPU的高速缓存
3.CPU执行指令，把结果写到高速缓存
4.高速缓存中的数据写回主内存

目前流行的多级缓存结构

由于CPU的运算速度超越了1级缓存的数据I\O能力，CPU厂商又引入了多级的缓存结构。

CPU底层全执行流程

同步规则分析

1）不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
2）一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或者assign）的变量。即就是对一个变量实施use和store操作之前，必须先自行assign和load操作。
3）一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现。
4）如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量之前需要重新执行load或assign操作初始化变量的值。
5）如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
6）对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作。

并发编程的可见性、原子性和有序性问题

1. 原子性

   原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。在java中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道这么回事即可

2. 可见性

• 可见性指的是当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。对于串行程序来说，可见性是不存在的，因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改过的新值。
• 但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实会导致程序轮序执行的问题，从而也就导致可见性问题。

3. 有序性

   有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象。

JMM是如何解决原子性&可见性&有序性问题

1. 原子性问题
   除了JVM自身提供的对基本数据类型读写操作的原子性外，可以通过 synchronized和Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码块。

2. 可见性问题

• volatile关键字保证可见性。当一个共享变量被volatile修饰时，它会保证修改的值立即被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取新值。
• synchronized和Lock也可以保证可见性，因为它们可以保证任一时刻只有一个线程能访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。

3. 有序性问题

• 通过volatile可以保证有序性。
• 可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

指令重排序

Java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与它的顺序情况的结果相等，那么指令的执行顺序可以与代码顺序不一样，此过程叫指令你的重排序

指令重排序的意义是什么？

JVM能根据处理器特征适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器特性。

as-if-serial 语义

不管怎么重排序，程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

为了遵守as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

happens-before原则

只靠synchronized和volatile关键字来保证原子性、可见性以及有序性，那么编写并发编程显得十分麻烦，从JDK5开始，Java使用新的JSR-133内存模型，提供了happeds-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()方法