深入理解 Java 虚拟机：Java 内存区域透彻分析
前言
Java是目前用户最多、使用范围最广的软件开发技术，Java 的技术体系主要由支撑Java程序运行的虚拟机。为各开发领域提供接口支持的Java API， Java编程语言及许许多多的第三方Java框架( 如Spring和Struts等)构成。在国内，有关Java API、Java 语言及第三方框架的技术资料和书籍非常丰富，相比之下，有关Java虚拟机的资料却显得异常贫乏。
这种状况很大程度上是由Java开发技术本身的一个重要优点导致的：
在虚拟机层面隐藏了底层技术的复杂性以及机器与操作系统的差异性。运行程序的物理机器情况千差万别，而Java虚拟机则在千差万别的物理机上面建立了统一的运行平台，实现了在任意一台虛拟机上编译的程序都能在任何一台虚拟机上正常运行。这一极大的优势使得Java应用的开发比传统C/C++应用的开发更高效和快捷，程序员可以把主要精力集中在具体业务逻辑上，而不是物理硬件的兼容性上。
一般情况下，一个程序员只要了解了必要的Java API, Java语法井学习适当的第三方开发框架，就已经基本能满足日常开发的需要了，虚拟机会在用户不知不觉中完成对硬件平台的兼容以及对内存等资源的管理工作。因此，了解虚拟机的运作并不是一般开发人员必须掌握的知识。然而，凡事都具备两面性。随着Java技术的不断发展，它被应用于越来越多的领域之中。其中一些领域，如电力、金融、通信等，对程序的性能、稳定性和可扩展性方面都有极高的要求。
一个程序很可能在10个人同时使用时完全正常，但是在10000个人同时使用时就会变慢、死锁甚至崩溃。毫无疑问，要满足10000个人同时使用需要更高性能的物理硬件，但是在绝大多数情况下，提升硬件效能无法等比例地提升程序的性能和并发能力，有时甚至可能对程序的性能没有任何改善作用。
这里面有Java虚拟机的原因：为了达到为所有硬件提供一致的虚拟平台的目的，牺牲了一些硬件相关的性能特性。
更重要的是人为原因：开发人员如果不了解虚拟机的一些技术特性的运行原理，就无法写出最适合虚拟机运行和可自优化的代码。
其实，目前商用的高性能Java虚拟机都提供了相当多的优化特性和调节手段，用于满足应用程序在实际生产环境中对性能和稳定性的要求。如果只是为了入门学习，让程序在自己的机器上正常运行，那么这些特性可以说是可有可无的；如果用于生产环境，尤其是企业级应用开发中，就迫切需要开发人员中至少有一部分人对虚拟机的特性及调节方法具有很清晰的认识，所以在Java开发体系中，对架构师、系统调优师、高级程序员等角色的需求一直都非常大。
关于JVM
JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。
Java内存区域透彻分析
这篇文章主要介绍Java内存区域，也是作为Java虚拟机的一些最基本的知识，理解了这些知识之后，才能更好的进行Jvm调优或者更加深入的学习，本来这些知识是晦涩难懂的，所以希望能够讲解的透彻且形象。
运行时数据区域
JVM载执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。
Java 虚拟机所管理的内存一共分为Method Area（方法区）、VM Stack（虚拟机栈）、Native Method Stack（本地方法栈）、Heap（堆）、Program Counter Register（程序计数器）五个区域。
这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。具体如下图所示：
上图介绍的是JDK1.8 JVM运行时内存数据区域划分。1.8同1.7比，最大的差别就是：元数据区取代了永久代。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元数据空间并不在虚拟机中，而是使用本地内存。
程序计数器（Program Counter Register）
程序计数器（Program Counter Register）是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。在虚拟机概念模型中，字节码解释器工作时就是通过改变计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
程序计数器是一块 “线程私有” 的内存，每条线程都有一个独立的程序计数器，能够将切换后的线程恢复到正确的执行位置。
执行的是一个Java方法
计数器记录的是正在执行的虚拟机字节码指令的地址。
执行的是Native方法
计数器为空（Undefined），因为native方法是java通过JNI直接调用本地C/C++库，可以近似的认为native方法相当于C/C++暴露给java的一个接口，java通过调用这个接口从而调用到C/C++方法。由于该方法是通过C/C++而不是java进行实现。那么自然无法产生相应的字节码，并且C/C++执行时的内存分配是由自己语言决定的，而不是由JVM决定的。
程序计数器也是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的内存区域。
其实，我感觉这块区域，作为我们开发人员来说是不能过多的干预的，我们只需要了解有这个区域的存在就可以，并且也没有虚拟机相应的参数可以进行设置及控制。
Java虚拟机栈（Java Virtual Machine Stacks）
Java虚拟机栈（Java Virtual Machine Stacks）描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame），从上图中可以看出，栈帧中存储着局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，会对应一个栈帧在虚拟机栈中入栈到出栈的过程。
与程序计数器一样，Java虚拟机栈也是线程私有的。
而局部变量表中存放了编译期可知的各种：
基本数据类型(boolen、byte、char、short、int、 float、 long、double）
对象引用（reference类型，它不等于对象本身，可能是一个指向对象起始地址的指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）
returnAddress类型（指向了一条字节码指令的地址）
其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
Java虚拟机规范中对这个区域规定了两种异常状况：
StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度，将会抛出此异常。
OutOfMemoryError：当可动态扩展的虚拟机栈在扩展时无法申请到足够的内存，就会抛出该异常。
一直觉得上面的概念性的知识还是比较抽象的，下面我们通过JVM参数的方式来控制栈的内存容量，模拟StackOverflowError异常现象。
本地方法栈（Native Method Stack）
本地方法栈（Native Method Stack） 与Java虚拟机栈作用很相似，它们的区别在于虚拟机栈为虚拟机执行Java方法（即字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。
在虚拟机规范中对本地方法栈中使用的语言、方式和数据结构并无强制规定，因此具体的虚拟机可实现它。甚至有的虚拟机（Sun HotSpot虚拟机）直接把本地方法栈和虚拟机栈合二为一。与虚拟机一样，本地方法栈会抛出StackOverflowError和OutOfMemoryError异常。
使用-Xss参数减少栈内存容量（更多的JVM参数可以参考这篇文章：深入理解Java虚拟机-常用vm参数分析）
这个例子中，我们将栈内存的容量设置为256K（默认1M），并且再定义一个变量查看栈递归的深度。
/**
* @ClassName Test_02
* @Description 设置Jvm参数：-Xss256k
* @Author 欧阳思海
* @Date 2019/9/30 11:05
* @Version 1.0
**/
public class Test_02 {
private int len = 1;
public void stackTest() {
len++;
System.out.println("stack len:" + len);
stackTest();
}
public static void main(String[] args) {
Test_02 test = new Test_02();
try {
test.stackTest();
2 } catch (Throwable e) {
23 e.printStackTrace();
24 }
25 }
26}
运行时设置JVM参数
输出结果：
Java堆（Heap）
对于大多数应用而言，Java堆（Heap）是Java虚拟机所管理的内存中最大的一块，它被所有线程共享的，在虚拟机启动时创建。此内存区域唯一的目的是存放对象实例，几乎所有的对象实例都在这里分配内存，且每次分配的空间是不定长的。在Heap 中分配一定的内存来保存对象实例，实际上只是保存对象实例的属性值，属性的类型和对象本身的类型标记等，并不保存对象的方法（方法是指令，保存在Stack中）,在Heap 中分配一定的内存保存对象实例和对象的序列化比较类似。
Java堆是垃圾收集器管理的主要区域，因此也被称为 “GC堆（Garbage Collected Heap）” 。从内存回收的角度看内存空间可如下划分：
图片摘自https://blog.csdn.net/bruce128/article/details/79357870
新生代（Young）：新生成的对象优先存放在新生代中，新生代对象朝生夕死，存活率很低。在新生代中，常规应用进行一次垃圾收集一般可以回收70% ~ 95% 的空间，回收效率很高。
如果把新生代再分的细致一点，新生代又可细分为Eden空间、From Survivor空间、To Survivor空间，默认比例为8:1:1。
老年代（Tenured/Old）：在新生代中经历了多次（具体看虚拟机配置的阀值）GC后仍然存活下来的对象会进入老年代中。老年代中的对象生命周期较长，存活率比较高，在老年代中进行GC的频率相对而言较低，而且回收的速度也比较慢。
永久代（Perm）：永久代存储类信息、常量、静态变量、即时编译器编译后的代码等数据，对这一区域而言，Java虚拟机规范指出可以不进行垃圾收集，一般而言不会进行垃圾回收。
其中新生代和老年代组成了Java堆的全部内存区域，而永久代不属于堆空间，它在JDK 1.8以前被Sun HotSpot虚拟机用作方法区的实现
另外，再强调一下堆空间内存分配的大体情况，这对于后面一些Jvm优化的技巧还是有帮助的。
老年代 ：三分之二的堆空间
年轻代 ：三分之一的堆空间
eden区：8/10 的年轻代空间
survivor0 : 1/10 的年轻代空间
survivor1 : 1/10 的年轻代空间
最后，我们再通过一个简单的例子更加形象化的展示一下堆溢出的情况。
JVM参数设置：-Xms10m -Xmx10m
这里将堆的最小值和最大值都设置为10m，如果不了解这些参数的含义，可以参考这篇文章：深入理解Java虚拟机-常用vm参数分析
/**
* VM Args：-Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError
* @author zzm
*/
public class HeapTest {
static class HeapObject {
}
public static void main(String[] args) {
List list = new ArrayList();
//不断的向堆中添加对象
while (true) {
list.add(new HeapObject());
}
}
}
输出结果：
图中出现了java.lang.OutOfMemoryError，并且提示了Java heap space，这就说明是Java堆内存溢出的情况。
堆的Dump文件分析
我的使用的是VisualVM工具进行分析，关于如何使用这个工具查看这篇文章（深入理解Java虚拟机-如何利用VisualVM对高并发项目进行性能分析 ）。在运行程序之后，会同时打开VisualVM工具，查看堆内存的变化情况。
在上图中，可以看到，堆的最大值是30m，但是使用的堆的容量也快接近30m了，所以很容易发生堆内存溢出的情况。
接着查看dump文件。
如上图，堆中的大部分的对象都是HeapObject，所以，就是因为这个对象的一直产生，所以导致堆内存不够分配，所以出现内存溢出。
我们再看GC情况。
如上图，Eden新生代总共48次minor gc，耗时1.168s，基本满足要求，但是survivor却没有，这不正常，同时Old Gen老年代总共27次full gc，耗时4.266s，耗时长，gc多，这正是因为大量的大对象进入到老年代导致的，所以，导致full gc频繁。
方法区（Method Area）
方法区（Method Area） 与Java堆一样，是各个线程共享的内存区域。它用于存储一杯虚拟机加载的类信息、常量、静态变量、及时编译器编译后的代码等数据。正因为方法区所存储的数据与堆有一种类比关系，所以它还被称为 Non-Heap。
运行时常量池（Runtime Constant Pool）
运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池存放。
Java虚拟机对Class文件每一部分（自然包括常量池）的格式有严格规定，每一个字节用于存储那种数据都必须符合规范上的要求才会被虚拟机认可、装载和执行。但对于运行时常量池，Java虚拟机规范没有做任何有关细节的要求，不同的提供商实现的虚拟机可以按照自己的需求来实现此内存区域。不过一般而言，除了保存Class文件中的描述符号引用外，还会把翻译出的直接引用也存储在运行时常量池中。
运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译器才能产生，也就是并非置入Class文件中的常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。
运行时常量池举例
上面的动态性在开发中用的比较多的便是String类的intern() 方法。所以，我们以intern() 方法举例，讲解一下运行时常量池。
String.intern()是一个native方法，作用是：如果字符串常量池中已经包含有一个等于此String对象的字符串，则直接返回池中的字符串；否则，加入到池中，并返回。
/**
* @ClassName MethodTest
* @Description vm参数设置：-Xms512m -Xmx512m -Xmn128m -XX:PermSize=10M -XX:MaxPermSize=10M -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:-HeapDumpOnOutOfMemoryError -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
* @Author 欧阳思海
* @Date 2019/11/25 20:06
* @Version 1.0
**/
public class MethodTest {
public static void main(String[] args) {
List list = new ArrayList();
long i = 0;
while (i < 1000000000) {
System.out.println(i);
list.add(String.valueOf(i++).intern());
}
}
}
vm参数介绍：
-Xms512m -Xmx512m -Xmn128m -XX:PermSize=10M -XX:MaxPermSize=10M -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:-HeapDumpOnOutOfMemoryError -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
开始堆内存和最大堆内存都是512m，永久代大小10m，新生代和老年代1：4，E:S1:S2=8:1:1，最大经过15次survivor进入老年代，使用的，垃圾收集器是新生代ParNew，老年代CMS。
通过这样的设置之后，查看运行结果：
首先堆内存耗完，然后看看GC情况，设置这些参数之后，GC情况应该会不错，拭目以待。
上图是GC情况，我们可以看到新生代 21 次minor gc，用了1.179秒，平均不到50ms一次，性能不错，老年代 117 次full gc，用了45.308s，平均一次不到1s，性能也不错，说明jvm运行是不错的。
注意： 在JDK1.6及以前的版本中运行以上代码，因为我们通过-XX:PermSize=10M -XX:MaxPermSize=10M设置了方法区的大小，所以也就是设置了常量池的容量，所以运行之后，会报错：java.lang.OutOfMemoryError:PermGen space，这说明常量池溢出；在JDK1.7及以后的版本中，将会一直运行下去，不会报错，在前面也说到，JDK1.7及以后，去掉了永久代。
直接内存
直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但这部分内存也被频繁运用，而却可能导致OutOfMemoryError异常出现。
这个我们实际中主要接触到的就是NIO，在NIO中，我们为了能够加快IO操作，采用了一种直接内存的方式，使得相比于传统的IO快了很多。
在NIO引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能避免在Java堆和Native堆中来回复制数据，在一些场景里显著提高性能。
在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统的限制），从而导致动态扩展时出现OutOfMemoryError异常。
