基本介绍
JVM是Java Virtual Machine的缩写，是一种虚拟机。它直接和操作系统进行交互，类似于一台小电脑运行在windows或者linux这些操作系统环境下。
JVM运行时数据区
参考博客blog.csdn.net/qq_41701956…
程序计数器
程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能，都需要依赖这个计数器来完成。
其中线程恢复，为了线程切换后能恢复到正确的执行位置，每个线程都需要有一个独立的程序计数器，各个线程之间的计数器互不影响，独立存储。（我们将这类内存区域称为“线程私有”内存）
程序计数器作用：
（1）字节码解释器通过改变程序计数器来依次独取指令，从而实现代码流程控制。如顺序执行、选择、循环、跳转、异常处理等。 （2）多线程情况下，程序计数器用来记录每个线程执行的位置，然后再线程进行切换的时候可以进行线程恢复，可以知道当前切换线程上次执行位置。
注：程序计数器是唯一一个不会出现 OutOfMemoryError 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。
虚拟机栈
与程序计数器一样，Java 虚拟机栈也是线程私有的，它的生命周期和线程相同，随着线程的创建而创建，随着线程的死亡而死亡。
java方法的调用基本都是通过栈来实现的，（除了一些Native方法需要调用本地方法栈外）方法调用的数据需要通过栈来进行传递，每一次方法调用都会有一个对应的栈帧被压入栈中，每一次方法调用结束，都会有一个栈帧被弹出。
栈由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接和方法返回地址。和数据结构上的栈类似，两者都是先进后出的数据结构，只支持出栈和入栈两种操作。
局部变量表主要存放再编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不同于对象本身！它可能只是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄。）
对象访问定位的两种方式：
（1）句柄：如果使用句柄的话，那么 Java 堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息。
（2）指针：如果使用直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而 reference 中存储的直接就是对象的地址。
比较：使用句柄的最大好处是 reference 中存储的是稳定的句柄地址，在对象移动(GC)是只改变实例数据指针地址，reference 自身不需要修改。直接指针访问的最大好处是速度快，节省了一次指针定位的时间开销。如果是对象频繁 GC 那么句柄方法好，如果是对象频繁访问则直接指针访问好。
操作数栈是方法调用的中转站，用于存放方法执行过程中产生的中间计算结果和产生的临时变量。
动态链接用于一个方法调用其他方法的场景。Java源文件被编译为JVM可以识别的字节码文件时，所有的变量和方法引用都会做为符号引用保存在Class文件的常量池中。当一个方法要调用其他方法时，需要将指向方法的符号引用转换为在内存中的直接引用。动态链接就是为了将符号引用转换为内存中的直接引用。
程序运行中栈可能出现的错误：
（1）StackOverFlowError： 若栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 StackOverFlowError 错误。
（2）OutOfMemoryError： 如果栈的内存大小可以动态扩展， 如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
Java 方法有两种返回方式，一种是 return 语句正常返回，一种是抛出异常。不管哪种返回方式，都会导致栈帧被弹出。也就是说， 栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。
本地方法栈
和虚拟机栈所发挥的作用非常相似，区别是： 虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。
本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。
也会存在StackOverFlowError 、OutOfMemoryError错误。
堆
堆是Java虚拟机所管理的内存中最大的一块，在虚拟机启动时创建，被所有线程共享。堆内存用来存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。
Java堆是垃圾收集器管理的主要区域，因此也被称为GC堆（Garbage Collected Heap）。
从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代；再细致一点有：Eden、Survivor(from,to)、Old 等空间。进一步划分的目的是更好地回收内存，或者更快地分配内存。
在 JDK 7 版本及 JDK 7 版本之前，堆内存被通常分为下面三部分：
- 新生代内存(Young Generation)
- 老生代(Old Generation)
- 永久代(Permanent Generation)
JDK 8 版本之后 PermGen(永久) 已被 Metaspace(元空间) 取代，元空间使用的是直接内存
当我们new一个对象后，会先放到Eden划分出来的一块做为存储空间的内存中。但是由于堆内存时所有线程共享的，就有可能会出现两个对象公用一个线程的情况。所以这里JVM处理时会为每个线程预先申请好一块连续的内存空间并规定对象存放的位置。如果空间不足会在申请多块内存空间。（多块内存空间在物理上可以不连续，但在逻辑上要连续）这个操作我们称为TALB。
当Eden空间满了之后，会触发Minor GC（发生在年轻代的GC）的操作，将存活下来的对象移动到Survivor0区。Survivor0区满了之后，在触发Minor GC，就会将存活的对象移动到Survivor1区，并将from和to两个指针交换，这样保证了一段时间内总有一个survivor区为空，且to所指向的survivor区为空。经历多次Minor GC后仍然存货的对象（这里的存活判断是15次，对应到虚拟机参数为 -XX:MaxTenuringThreshold 。为什么是15，因为HotSpot会在对象头中的标记字段里记录年龄，分配到的空间仅有4位，所以最多只能记录到15。但是实际取时并不一定取15，Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的一半时，取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值）会移动到老年代。老年代是存储长期存活的对象的，占满时就会触发我们最常听说的Full GC，期间会停止所有线程等待GC的完成。所以对于响应要求高的应用应该尽量去减少发生Full GC从而避免响应超时的问题。
而且当老年区执行了full gc之后仍然无法进行对象保存的操作，就会产生OOM，这时候就是虚拟机中的堆内存不足，原因可能会是堆内存设置的大小过小，这个可以通过参数-Xms、-Xmx来调整。也可能是代码中创建的对象大且多，而且它们一直在被引用从而长时间垃圾收集无法收集它们。
堆这里最容易出现的就是 OutOfMemoryError 错误，并且出现这种错误之后的表现形式还会有几种，比如：
java.lang.OutOfMemoryError: GC Overhead Limit Exceeded： 当 JVM 花太多时间执行垃圾回收并且只能回收很少的堆空间时，就会发生此错误。java.lang.OutOfMemoryError: Java heap space:假如在创建新的对象时, 堆内存中的空间不足以存放新创建的对象, 就会引发此错误。
方法区
方法区是JVM运行时数据区域的一块逻辑区域，各个线程共享。当虚拟机要使用一个类时，它需要读取并解析 Class 文件获取相关信息，再将信息存入到方法区。方法区会存储已被虚拟机加载的 类信息、字段信息、方法信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
方法区和永久代以及元空间的关系很像 Java 中接口和类的关系，类实现了接口，这里的类就可以看作是永久代和元空间，接口可以看作是方法区，也就是说永久代以及元空间是 HotSpot 虚拟机对虚拟机规范中方法区的两种实现方式。并且，永久代是 JDK 1.8 之前的方法区实现，JDK 1.8 及以后方法区的实现变成了元空间（元空间使用的是直接内存）。
为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) 呢?
1、整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。
-XX:PermSize=N //方法区 (永久代) 初始大小
-XX:MaxPermSize=N //方法区 (永久代) 最大大小,超过这个值将会抛出 OutOfMemoryError 异常:java.lang.OutOfMemoryError: PermGen
-XX:MetaspaceSize=N //设置 Metaspace 的初始（和最小大小）
-XX:MaxMetaspaceSize=N //设置 Metaspace 的最大大小
2、元空间里面存放的是类的元数据，这样加载多少类的元数据就不由 MaxPermSize 控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。
3、在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有一个叫永久代的东西, 合并之后就没有必要额外的设置这么一个永久代的地方了。
运行时常量池主要存储编译期生成的各种字面量和符号引用。
字面量是源代码中的固定值的表示法，即通过字面我们就能知道其值的含义。字面量包括整数、浮点数和字符串字面量，符号引用包括类符号引用、字段符号引用、方法符号引用和接口方法符号引用。
常量池表会在类加载后存放到方法区的运行时常量池中。当常量池无法再申请到内存时会抛出 OutOfMemoryError 错误。
字符串常量池
字符串常量池 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。
// 在堆中创建字符串对象”ab“
// 将字符串对象”ab“的引用保存在字符串常量池中
String aa = "ab";
// 直接返回字符串常量池中字符串对象”ab“的引用
String bb = "ab";
System.out.println(aa==bb);// true
HotSpot 虚拟机中字符串常量池的实现是 src/hotspot/share/classfile/stringTable.cpp ,StringTable 本质上就是一个HashSet<String> ,容量为 StringTableSize（可以通过 -XX:StringTableSize 参数来设置）。
StringTable 中保存的是字符串对象的引用，字符串对象的引用指向堆中的字符串对象。
JDK 1.7 为什么要将字符串常量池移动到堆中？
主要是因为永久代（方法区实现）的 GC 回收效率太低，只有在整堆收集 (Full GC)的时候才会被执行 GC。Java 程序中通常会有大量的被创建的字符串等待回收，将字符串常量池放到堆中，能够更高效及时地回收字符串内存。
直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。而且也可能导致 OutOfMemoryError 错误出现。
JDK1.4 中新加入的 NIO(New Input/Output) 类，引入了一种基于通道（Channel）与缓存区（Buffer）的 I/O 方式，它可以直接使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样就能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆之间来回复制数据。
本机直接内存的分配不会受到 Java 堆的限制，但是，既然是内存就会受到本机总内存大小以及处理器寻址空间的限制。
