深刻理解 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<HeapObject> list = new ArrayList<HeapObject>();

 //不断的向堆中添加对象
 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<String> list = new ArrayList<String>();
 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异常。