1、CPU和内存的交互
了解jvm内存模型前，了解下cpu和计算机内存的交互情况。【因为Java虚拟机内存模型定义的访问操作与计算机十分相似】
有篇很棒的文章，从cpu讲到内存模型:[什么是java内存模型？]
在计算机中，cpu和内存的交互最为频繁，相比内存，磁盘读写太慢，内存相当于高速的缓冲区。
但是随着cpu的发展，内存的读写速度也远远赶不上cpu。因此cpu厂商在每颗cpu上加上高速缓存，用于缓解这种情况。现在cpu和内存的交互大致如下。
的问题 - 缓存一致性
在多核cpu中，每个处理器都有各自的高速缓存(L1,L2,L3)，而主内存确只有一个 。
以我的pc为例,因为cpu成本高，缓存区一般也很小。
CPU要读取一个数据时，首先从一级缓存中查找，如果没有找到再从二级缓存中查找，如果还是没有就从三级缓存或内存中查找，每个cpu有且只有一套自己的缓存。
如何保证多个处理器运算涉及到同一个内存区域时，多线程场景下会存在缓存一致性问题，那么运行时保证数据一致性？
为了解决这个问题，各个处理器需遵循一些协议保证一致性。【如MSI，MESI啥啥的协议。。】
大概如下
在CPU层面，内存屏障提供了个充分必要条件
2、内存屏障(Memory Barrier)
CPU中，每个CPU又有多级缓存【上图统一定义为高速缓存】，一般分为L1,L2,L3，因为这些缓存的出现，提高了数据访问性能，避免每次都向内存索取，但是弊端也很明显，不能实时的和内存发生信息交换，分在不同CPU执行的不同线程对同一个变量的缓存值不同。
硬件层的内存屏障分为两种：Load Barrier 和 Store Barrier即读屏障和写屏障。【内存屏障是硬件层的】
2.1、为什么需要内存屏障
由于现代操作系统都是多处理器操作系统，每个处理器都会有自己的缓存，可能存再不同处理器缓存不一致的问题，而且由于操作系统可能存在重排序，导致读取到错误的数据，因此，操作系统提供了一些内存屏障以解决这种问题.
简单来说:
1)在不同CPU执行的不同线程对同一个变量的缓存值不同，为了解决这个问题。
2)用volatile可以解决上面的问题，不同硬件对内存屏障的实现方式不一样。
java屏蔽掉这些差异，通过jvm生成内存屏障的指令。
3)对于读屏障:在指令前插入读屏障，可以让高速缓存中的数据失效，强制从主内存取。
2.2、内存屏障的作用
cpu执行指令可能是无序的，它有两个比较重要的作用
1) 阻止屏障两侧指令重排序
2) 强制把写缓冲区/高速缓存中的脏数据等写回主内存，让缓存中相应的数据失效。
3、volatile型变量
当我们声明某个变量为volatile修饰时，这个变量就有了线程可见性，volatile通过在读写操作前后添加内存屏障。
volatile型变量拥有如下特性
可见性，对于一个该变量的读，一定能看到读之前最后的写入。
防止指令重排序，执行代码时,为了提高执行效率,会在不影响最后结果的前提下对指令进行重新排序,使用volatile可以防止，比如单例模式双重校验锁的创建中有使用到
public class Lock2Singleton {
private volatile static Lock2Singleton singleton; // 1. 对象锁
private Lock2Singleton(){}
public static Lock2Singleton getSingleton(){
if(singleton == null){
synchronized(Lock2Singleton.class){ // 2. synchronized 方法锁
if(singleton == null){
singleton = new Lock2Singleton();
}
}
}
return singleton;
}
}
注意的是volatile不具有原子性，如volatile++这样的复合操作,这里感谢大家的指正。
至于volatile底层是怎么实现保证不同线程可见性的，这里涉及到的就是硬件上的，被volatile修饰的变量在进行写操作时，会生成一个特殊的汇编指令，该指令会触发mesi协议，会存在一个总线嗅探机制的东西，简单来说就是这个cpu会不停检测总线中该变量的变化，如果该变量一旦变化了，由于这个嗅探机制，其它cpu会立马将该变量的cpu缓存数据清空掉，重新的去从主内存拿到这个数据。
4、Java内存区域
前提:本文讲的基本都是以Sun HotSpot虚拟机为基础的，Oracle收购了Sun后目前得到了两个【Sun的HotSpot和JRockit(以后可能合并这两个),还有一个是IBM的IBMJVM】
之所以扯了那么多计算机内存模型，是因为java内存模型的设定符合了计算机的规范。
Java程序内存的分配是在JVM虚拟机内存分配机制下完成。
Java内存模型（Java Memory Model ,JMM）就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。
简要言之，jmm是jvm的一种规范，定义了jvm的内存模型。它屏蔽了各种硬件和操作系统的访问差异，不像c那样直接访问硬件内存，相对安全很多，它的主要目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。可以保证并发编程场景中的原子性、可见性和有序性。
从下面这张图可以看出来，Java数据区域分为五大数据区域。这些区域各有各的用途，创建及销毁时间。
其中方法区和堆是所有线程共享的，栈，本地方法栈和程序计数器则为线程私有的。
根据java虚拟机规范，java虚拟机管理的内存将分为下面五大区域。
5、五大内存区域
5.1、程序计数器
程序计数器是一块很小的内存空间，它是线程私有的，可以认作为当前线程的行号指示器。
为什么需要程序计数器
我们知道对于一个处理器(如果是多核cpu那就是一核)，在一个确定的时刻都只会执行一条线程中的指令，一条线程中有多个指令，为了线程切换可以恢复到正确执行位置，每个线程都需有独立的一个程序计数器，不同线程之间的程序计数器互不影响，独立存储。
注意：如果线程执行的是个java方法，那么计数器记录虚拟机字节码指令的地址。如果为native【底层方法】，那么计数器为空。这块内存区域是虚拟机规范中唯一没有OutOfMemoryError的区域。
5.2、Java栈（虚拟机栈）
同计数器也为线程私有，生命周期与相同，就是我们平时说的栈，栈描述的是Java方法执行的内存模型。
每个方法被执行的时候都会创建一个栈帧用于存储局部变量表，操作栈，动态链接，方法出口等信息。每一个方法被调用的过程就对应一个栈帧在虚拟机栈中从入栈到出栈的过程。
对于栈帧的解释参考 Java虚拟机运行时栈帧结构
栈帧: 是用来存储数据和部分过程结果的数据结构。
栈帧的位置: 内存 -> 运行时数据区 -> 某个线程对应的虚拟机栈 -> here
栈帧大小确定时间: 编译期确定，不受运行期数据影响。
通常有人将java内存区分为栈和堆，实际上java内存比这复杂，这么区分可能是因为我们最关注，与对象内存分配关系最密切的是这两个。
平时说的栈一般指局部变量表部分
局部变量表:一片连续的内存空间，用来存放方法参数，以及方法内定义的局部变量，存放着编译期间已知的数据类型(八大基本类型和对象引用(reference类型),returnAddress类型。它的最小的局部变量表空间单位为Slot，虚拟机没有指明Slot的大小，但在jvm中，long和double类型数据明确规定为64位，这两个类型占2个Slot，其它基本类型固定占用1个Slot。
reference类型:与基本类型不同的是它不等同本身，即使是String，内部也是char数组组成，它可能是指向一个对象起始位置指针，也可能指向一个代表对象的句柄或其他与该对象有关的位置。
returnAddress类型:指向一条字节码指令的地址【深入理解Java虚拟机】怎么理解returnAddress
需要注意的是，局部变量表所需要的内存空间在编译期完成分配，当进入一个方法时，这个方法在栈中需要分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表大小。
Java虚拟机栈可能出现两种类型的异常：
线程请求的栈深度大于虚拟机允许的栈深度，将抛出StackOverflowError。虚拟机栈空间可以动态扩展，当动态扩展是无法申请到足够的空间时，抛出OutOfMemory异常。
本地方法栈
本地方法栈是与虚拟机栈发挥的作用十分相似,区别是虚拟机栈执行的是Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的native方法服务，可能底层调用的c或者c++,我们打开jdk安装目录可以看到也有很多用c编写的文件，可能就是native方法所调用的c代码。
堆
对于大多数应用来说，堆是java虚拟机管理内存最大的一块内存区域，因为堆存放的对象是线程共享的，所以多线程的时候也需要同步机制。因此需要重点了解下。
java虚拟机规范对这块的描述是:所有对象实例及数组都要在堆上分配内存，但随着JIT编译器的发展和逃逸分析技术的成熟，这个说法也不是那么绝对，但是大多数情况都是这样的。
即时编译器:可以把把Java的字节码，包括需要被解释的指令的程序）转换成可以直接发送给处理器的指令的程序)
逃逸分析:通过逃逸分析来决定某些实例或者变量是否要在堆中进行分配，如果开启了逃逸分析，即可将这些变量直接在栈上进行分配，而非堆上进行分配。这些变量的指针可以被全局所引用，或者其其它线程所引用。
6、浅谈HotSpot逃逸分析
6.1、JIT
即时编译（Just-in-time Compilation，JIT）是一种通过在运行时将字节码翻译为机器码，从而改善字节码编译语言性能的技术。在HotSpot实现中有多种选择：C1、C2和C1+C2，分别对应client、server和分层编译。
C1编译速度快，优化方式比较保守；
C2编译速度慢，优化方式比较激进；
C1+C2在开始阶段采用C1编译，当代码运行到一定热度之后采用G2重新编译；
在1.8之前，分层编译默认是关闭的，可以添加-server -XX:+TieredCompilation参数进行开启。
6.2、逃逸分析
逃逸分析并不是直接的优化手段，而是一个代码分析，通过动态分析对象的作用域，为其它优化手段如栈上分配、标量替换和同步消除等提供依据，发生逃逸行为的情况有两种：方法逃逸和线程逃逸。
方法逃逸：当一个对象在方法中定义之后，作为参数传递到其它方法中；
线程逃逸：如类变量或实例变量，可能被其它线程访问到；
如果不存在逃逸行为，则可以对该对象进行如下优化：同步消除、标量替换和栈上分配。
1）同步消除
线程同步本身比较耗，如果确定一个对象不会逃逸出线程，无法被其它线程访问到，那该对象的读写就不会存在竞争，则可以消除对该对象的同步锁，通过-XX:+EliminateLocks可以开启同步消除。
2）标量替换
标量是指不可分割的量，如java中基本数据类型和reference类型，相对的一个数据可以继续分解，称为聚合量；
如果把一个对象拆散，将其成员变量恢复到基本类型来访问就叫做标量替换；如果逃逸分析发现一个对象不会被外部访问，并且该对象可以被拆散，那么经过优化之后，并不直接生成该对象，而是在栈上创建若干个成员变量；
通过-XX:+EliminateAllocations可以开启标量替换，-XX:+PrintEliminateAllocations查看标量替换情况。
3）栈上分配
故名思议就是在栈上分配对象，其实目前Hotspot并没有实现真正意义上的栈上分配，实际上是标量替换
private static int fn(int age) {
User user = new User(age);
int i = user.getAge();
return i;
}
User对象的作用域局限在方法fn中，可以使用标量替换的优化手段在栈上分配对象的成员变量，这样就不会生成User对象，大大减轻GC的压力，下面通过例子看看逃逸分析的影响。
public class JVM {
public static void main(String[] args) throws Exception {
int sum = 0;
int count = 1000000;
//warm up
for (int i = 0; i < count ; i++) {
sum += fn(i);
}
Thread.sleep(500);
for (int i = 0; i < count ; i++) {
sum += fn(i);
}
System.out.println(sum);
System.in.read();
}
private static int fn(int age) {
User user = new User(age);
int i = user.getAge();
return i;
}
}
class User {
private final int age;
public User(int age) {
this.age = age;
}
public int getAge() {
return age;
}}
分层编译和逃逸分析在1.8中是默认是开启的，例子中fn方法被执行了200w次，按理说应该在Java堆生成200w个User对象。
通过java -cp . -Xmx3G -Xmn2G -server -XX:-DoEscapeAnalysis JVM运行代码，-XX:-DoEscapeAnalysis关闭逃逸分析，通过jps查看java进程的PID，接着通过jmap -histo [pid]查看java堆上的对象分布情况，结果如下：