JVM、JMM与硬件的对应关系

1. JVM内存区域

1. 程序计数器

线程的私有数据，存放执行下一条指令的地址。
1.在任一具体时刻，一个CPU的内核只会执行一条线程中的指令，因此，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器。
2.在JVM规范中规定，如果线程执行的是非native方法，则程序计数器中保存的是当前需要执行的指令的地址；如果线程执行的是native方法，则程序计数器中的值是undefined。
　　3.由于程序计数器中存储的数据所占空间的大小不会随程序的执行而发生改变，因此，对于程序计数器是不会发生内存溢出现象(OutOfMemory)的。

2. VM栈

VM栈也称Java Vitual Machine Stack，Java栈
由于每个线程正在执行的方法可能不同，因此每个线程都会有一个自己的VM栈，互不干扰。
每一个方法对应一个栈帧
当线程执行一个方法时，就会随之创建一个对应的栈帧，并将建立的栈帧压栈。当方法执行完毕之后，便会将栈帧出栈。
线程当前执行的方法所对应的栈帧必定位于Java栈的顶部，因此在使用递归方法的时候容易导致栈内存溢出的现象。

1. 局部变量表，用来存储方法中的局部变量（包括在方法中声明的非静态变量以及函数形参）。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。局部变量表的大小在编译器就可以确定其大小了，因此在程序执行期间局部变量表的大小是不会改变的。
2. 操作数栈，程序中的所有计算过程都是在借助于操作数栈来完成的。
3. 指向运行时常量池的引用，因为在方法执行的过程中有可能需要用到类中的常量，所以必须要有一个引用指向运行时常量。
4. 方法返回地址，当一个方法执行完毕之后，要返回之前调用它的地方，因此在栈帧中必须保存一个方法返回地址。

3. 本地方法栈

本地方法栈与Java栈的作用和原理非常相似。区别只不过是Java栈是为执行Java方法服务的，而本地方法栈则是为执行本地方法（Native Method）服务的。在JVM规范中，并没有对本地方发展的具体实现方法以及数据结构作强制规定，虚拟机可以自由实现它。在HotSopt虚拟机中直接就把本地方法栈和Java栈合二为一。

4. 堆区

存放实例对象、数组等，这部分空间也是Java垃圾收集器管理的主要区域。
堆是被所有线程共享的，在JVM中只有一个堆。

5. 方法区

线程共享
在方法区中，存储了每个类的信息（包括类的名称、方法信息、字段信息）、静态变量、常量以及编译器编译后的代码等。

在Class文件中除了类的字段、方法、接口等描述信息外，还有一项信息是常量池，用来存储编译期间生成的字面量和符号引用。

在方法区中有一个非常重要的部分就是运行时常量池，它是每一个类或接口的常量池的运行时表示形式，在类和接口被加载到JVM后，对应的运行时常量池就被创建出来。当然并非Class文件常量池中的内容才能进入运行时常量池，在运行期间也可将新的常量放入运行时常量池中，比如String的intern方法。

在JVM规范中，没有强制要求方法区必须实现垃圾回收。很多人习惯将方法区称为==“永久代”，是因为HotSpot虚拟机以永久代来实现方法区，从而JVM的垃圾收集器可以像管理堆区一样管理这部分区域，从而不需要专门为这部分设计垃圾回收机制。不过自从JDK7之后，Hotspot虚拟机便将运行时常量池从永久代移除了。==

2. Java内存模型(Java Memory Model)

1.什么是JMM

Java内存模型，简称JMM，是一种抽象的设计概念，是Java内存设计的一种指导思想。JVM是JMM的一种实现。
在不同的硬件生产商和不同的操作系统下，内存的访问逻辑有一定的差异，结果就是当你的代码在某个系统环境下运行良好，并且线程安全，但是换了个系统就出现各种问题。Java内存模型，就是为了屏蔽系统和硬件的差异，让一套代码在不同平台下能到达相同的访问结果。JMM从java 5开始的JSR-133发布后，已经成熟和完善起来。

2.JMM内存模型

如果非要把 JMM、JVM、硬件结构 对应起来，主内存对应的是JVM堆中的对象实例部分，工作内存对应的是栈中的部分区域，从更底层的来说，主内存对应的是硬件的物理内存，工作内存对应的是寄存器和高速缓存。

线程修改私有数据在工作空间中操作
线程修改共享数据：复制主内存数据到工作空间->修改->刷新内存中的数据

1）主内存：共享的信息（例如：引用的对象实例）
2）工作空间：私有信息与基本数据类型（因为基本数据类型的常量一定在栈区）等直接分配到工作内存，引用的地址存放在工作内存

3. 硬件内存架构与Java内存模型

1. 硬件架构

a)CPU缓存的一致性问题：并发处理的不同步
b)解决方案：
i.总线加锁（） 降低CPU的吞吐量
ii.缓存上的一致性协议（比如Intel的MESI协议）
MESI：当CPU在CACHE中操作数据时，如果该数据是共享变量，数据在CACHE读到寄存器中，进行新修改，并更新内存数据
CaCHE LINE置无效，其他的CPU就从内存中读数据

2. Java线程与硬件处理器

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

即，JMM中的主内存与工作空间的数据有可能在硬件架构中的寄存器、cache、内存中的任何一个位置。

4. 数据交互操作

线程在执行时可能会发生读取数据不一致等的一系列问题，JMM的作用也就是规范工作空间与主内存的数据交互问题。
内存交互操作有8种，虚拟机实现必须保证每一个操作都是原子的，不可在分的（对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许例外）

• lock （锁定）：作用于主内存的变量，把一个变量标识为线程独占状态
• unlock （解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
• read （读取）：作用于主内存变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用
• load （载入）：作用于工作内存的变量，它把read操作从主存中变量放入工作内存中
• use （使用）：作用于工作内存中的变量，它把工作内存中的变量传输给执行引擎，每当虚拟机遇到一个需要使用到变量的值，就会使用到这个指令
• assign （赋值）：作用于工作内存中的变量，它把一个从执行引擎中接受到的值放入工作内存的变量副本中
• store （存储）：作用于主内存中的变量，它把一个从工作内存中一个变量的值传送到主内存中，以便后续的write使用
• write 　（写入）：作用于主内存中的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中

JMM对这八种指令的使用，制定了如下规则：

1. 不允许read和load、store和write操作之一单独出现。即使用了read必须load，使用了store必须write
2. 不允许线程丢弃他最近的assign操作，即工作变量的数据改变了之后，必须告知主存
3. 不允许一个线程将没有assign的数据从工作内存同步回主内存
4. 一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未被初始化的变量。就是怼变量实施use、store操作之前，必须经过assign和load操作
5. 一个变量同一时间只有一个线程能对其进行lock。多次lock后，必须执行相同次数的unlock才能解锁
6. 如果对一个变量进行lock操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新load或assign操作初始化变量的值
7. 如果一个变量没有被lock，就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
8. 对一个变量进行unlock操作之前，必须把此变量同步回主内存

JMM对这八种操作规则和对volatile的一些特殊规则就能确定哪里操作是线程安全，哪些操作是线程不安全的了。但是这些规则实在复杂，很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候，我们可以使用java的happen-before规则来进行分析。

5. 并发编程的三个特性

1. 原子性

原子性不多说，需要注意的是多个原子性的操作合并到一起没有原子性。

2. 可见性

定义：可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

3.有序性

有序性是指代码的执行顺序，但此执行顺序经过了编译器重排序与处理器重排序（为了提高代码的执行效率）。但是，在重排序时要保证可见性，具体的说要遵循happens-before等原则。

6. 重排序

作用：在不改变程序执行结果的前提下，尽可能提高并行度（提高执行效率）。
为了提高性能，编译器和处理器常常会对指令进行重排序。

如图，1属于编译器重排序，而2和3统称为处理器重排序。

1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序；
2. 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序；
3. 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行的。
   这些重排序会导致线程安全的问题，一个很经典的例子就是DCL问题（双重检验锁），这时需要禁止重排序（这个先不说）。针对编译器重排序，JMM的编译器重排序规则会禁止一些特定类型的编译器重排序；针对处理器重排序，编译器在生成指令序列的时候会通过插入内存屏障指令来禁止某些特殊的处理器重排序。

数据依赖性

定义：如果两个操作访问同一个变量，且这两个操作有一个为写操作，此时这两个操作就存在数据依赖性。
编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖性关系的两个操作的执行顺序。

double pi = 3.14 //A

double r = 1.0 //B

double area = pi * r * r //C
//上面A,B就不会出现数据依赖性，可以进行重排序。

as-if-serial

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

happens-before

JMM可以通过happens-before关系向程序员提供跨线程的内存可见性保证

happens-before具体定义为：
1）如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前（并不是真的就在前面执行）。
2）两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法（也就是说，JMM允许这种重排序）。

依旧以上面计算圆面积的进行描述。利用程序顺序规则（规则1）存在三个happens-before关系：1. A happens-before B；2. B happens-before C;3. A happens-before C。这里的第三个关系是利用传递性进行推论的。A happens-before B,定义1要求A执行结果对B可见，并且A操作的执行顺序在B操作之前，但与此同时利用定义中的第二条，A,B操作彼此不存在数据依赖性，两个操作的执行顺序对最终结果都不会产生影响，在不改变最终结果的前提下，允许A，B两个操作重排序，即happens-before关系并不代表了最终的执行顺序。

上面的1）是JMM对程序员的承诺。从程序员的角度来说，可以这样理解happens-before关系：如果A happens-before B，那么Java内存模型将向程序员保证——A操作的结果将对B可见，且A的执行顺序排在B之前。注意，这只是Java内存模型向程序员做出的保证！

上面的2）是JMM对编译器和处理器重排序的约束原则。正如前面所言，JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。JMM这么做的原因是：程序员对于这两个操作是否真的被重排序并不关心，程序员关心的是程序执行时的语义不能被改变（即执行结果不能被改变）。

happens-before的规则：

1. 程序顺序规则：一个线程内，代码执行的过程必须保证语义的串行性（ as-if-serial，看起来是串行的；另外如果程序内数据存在依赖，也不允许进行重排序 ）。
2. 监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
3. volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
4. 传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。
5. start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
6. join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
7. 程序中断规则：对线程interrupted()方法的调用先行于被中断线程的代码检测到中断时间的发生。
8. 对象finalize规则：一个对象的初始化完成（构造函数执行结束）先行于发生它的finalize()方法的开始。

as-if-serial VS happens-before

1. as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before关系保证正确同步的多线程程序的执行结果不被改变。
2. as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按happens-before指定的顺序来执行的。
3. as-if-serial语义和happens-before这么做的目的，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

7. JMM对三个特性的保证

1. 对原子性的保证

Synchronized
JUC Lock的lock

2. 对可见性的保证

Volatile:在JMM模型上模拟了MESI协议（个人理解）
Synchronized:加锁
JUC Lock的lock

3.对有序性的保证

Volatile
Synchronized
Happens-before原则