前言

JVM系列文章如无非凡阐明，一些个性均是基于Hot Spot虚拟机和JDK1.8版本讲述。

上面这张图我想对于每个学习Java的人来说再相熟不过了，这就是整个JDK的关系图：

从上图咱们能够看到，Java Virtual Machine位于最底层，所有的Java利用都是基于JVM来运行的，所以学习JVM对任何一个想要深刻理解Java的人是必不可少的。

Java的口号是：Write once,run anywhere（一次编写，到处运行）。之所以能实现这个口号的起因就是因为JVM的存在，JVM帮咱们解决好了不同平台的兼容性问题，只有咱们装置对应零碎的JDK，就能够运行，而无需关怀其余问题。

什么是JVM

JVM全称Java Virtual Machine，即Java虚拟机，是一种形象计算机。与真正的计算机一样，它有一个指令集，并在运行时操作各种内存区域。虚拟机有很多种，不同的厂商提供了不同的实现，只有遵循虚拟机标准即可。目前咱们常说的虚拟机个别都指的是Hot Spot。

JVM对Java编程语言无所不知，只晓得一种特定的二进制格局，即类文件格式。类文件蕴含Java虚拟机指令(或字节码)和符号表，以及其余辅助信息。也就是说，咱们写好的程序最终交给JVM执行的时候会被编译成为二进制格局。

留神：Java虚拟机只认二进制格式文件，所以，任何语言，只有编译之后的格局符合要求，都能够在Java虚拟机上运行，如Kotlin,Groovy等。

Java程序执行流程

从咱们写好的.java文件到最终在JVM上运行时，大抵是如下一个流程:

一个java类在通过编译和类加载机制之后，会将加载后失去的数据放到运行时数据区内，这样咱们在运行程序的时候间接从JVM内存中读取对应信息就能够了。

运行时数据区

运行时数据区：Run-Time Data Areas。Java虚拟机定义了在程序执行期间应用的各种运行时数据区域。其中一些数据区域是在Java虚拟机启动时创立的，只在Java虚拟机退出时销毁，这些区域是所有线程共享的，所以会有线程不平安的问题产生。而有一些数据区域为每个线程独占的，每个线程独占数据区域在线程创立时创立，在线程退出时销毁，线程独占的数据区就不会有安全性问题。

Run-Time Data Areas次要包含如下局部：pc寄存器，堆，办法区，虚拟机栈，本地办法栈。

PC(program counter) Register(程序计数器)

PC Register是每个线程独占的空间。
Java虚拟机能够反对同时执行多个线程，而在任何一个确定的时刻，一个处理器只会执行一个线程中的一个指令，又因为线程具备随机性，操作系统会始终切换线程去执行不同的指令，所以为了切换线程之后能回到原先执行的地位，每个JVM线程都必须要有本人的pc(程序计数器)寄存器来独立存储执行信息，这样能力持续之前的地位往后运行。

在任何时候，每个Java虚拟机线程都在执行单个办法的代码，即该线程的以后办法。如果该办法不是Native办法，则pc寄存器会记录以后正在执行的Java虚拟机指令的地址。如果线程以后执行的办法是本地的，那么Java虚拟机的pc寄存器的值是Undefined。

Heap(堆)

堆是Java虚拟机所治理内存中最大的一块，在虚拟机启动时创立，被所有线程共享。
堆在虚拟机启动时创立，用于存储所有的对象实例和数组(在某些非凡状况下不是)。

堆中的对象永远不会显式地开释，必须由GC主动回收。所以GC也次要是回收堆中的对象实例，咱们平时探讨垃圾回收次要也是回收堆内存。

堆能够处于物理上不间断的内存空间，能够固定大小，也能够动静扩大，通过参数-Xms和Xmx两个参数来管制堆内存的最小和最大值。

堆可能存在如下异常情况：

如果计算须要的堆比主动存储管理零碎提供的堆多，将抛出OutOfMemoryError谬误。

模仿堆内OutOfMemoryError

为了不便模仿，咱们把堆固定一下大小，设置为：

-Xms20m -Xmx20m

而后新建一个测试类来测试一下：

package com.zwx.jvm.oom;import java.util.ArrayList;import java.util.List;public class Heap {    public static void main(String[] args) {        List<Integer> list = new ArrayList<>();        while (true){            list.add(99999);        }    }}

输入后果为（前面的Java heap space，示意堆空间溢出）：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space    at java.util.Arrays.copyOf(Arrays.java:3210)    at java.util.Arrays.copyOf(Arrays.java:3181)

留神：堆不能设置的太小，太小的话会启动失败，如上咱们把参数大小都批改为2m，会呈现上面的谬误：

Error occurred during initialization of VMGC triggered before VM initialization completed. Try increasing NewSize, current value 1536K.

Method Area(办法区)

办法区是各个线程共享的内存区域，在虚拟机启动时创立。它存储每个类的构造，比方：运行时常量池、属性和办法数据，以及办法和构造函数的代码，包含在类和实例初始化以及接口初始化中应用的非凡办法。

办法区在逻辑上是堆的一部分，然而它却又一个别名叫做Non-Heap(非堆)，目标是与Java堆辨别开来。
办法区域能够是固定大小，也能够依据计算的须要进行扩大，如果不须要更大的办法区域，则能够膨胀。办法区域的内存不须要是间断的。

办法区中可能呈现如下异样：

如果办法区域中的内存无奈满足调配申请时，将抛出OutOfMemoryError谬误。

Run-Time Constant Pool(运行时常量池)

运行时常量池是办法区中的一部分，用于存储编译生成的字面量和符号援用。类或接口的运行时常量池是在Java虚拟机创立类或接口时构建的。

字面量

在计算机科学中，字面量(literal)是用于表白源代码中一个固定值的表示法(notation)。简直所有计算机编程语言都具备对根本值的字面量示意，诸如：整数、浮点数以及字符串等。在Java中罕用的字面量就是根本数据类型或者被final润饰的常量或者字符串等。

String字符串去哪了

字符串这里值得拿进去独自解释一下，在jdk1.6以及之前的版本，Java中的字符串就是放在办法区中的运行时常量池内，然而在jdk1.7和jdk1.8版本(jdk1.8之后自己没有深刻去理解过，所以不探讨)，将字符串常量池拿进去放到了堆(heap)里。
咱们来通过一个例子来演示一下区别：

package com.zwx;public class demo {    public static void main(String[] args) {        String str1 = new String("lonely") + new String("wolf");        System.out.println(str1==str1.intern());    }}

这个语句的运行后果在不同的JDK版本中输入的后果会不一样：
JDK1.6中会输入false：

JDK1.7中输入true：

JDK1.8中也会输入true：

intern()办法

jdk1.6及之前的版本中：
调用String.intern()办法，会先去常量池查看是否存在以后字符串，如果不存在，则会在办法区中创立一个字符串，而new String("")办法创立的字符串在堆外面，两个字符串的地址不相等，故而返回false。
在jdk1.7及1.8版本中：
字符串常量池从办法区中的运行时常量池移到了堆内存中，而intern()办法也随之做了扭转。调用String.intern()办法，首先还是会去常量池中查看是否存在，如果不存在，那么就会创立一个常量，并将援用指向堆，也就是说不会再从新创立一个字符串对象了，两者都会指向堆中的对象，所以返回true。
不过有一点还是须要留神，咱们把下面的结构字符串的代码革新一下：
String str1 = new String("ja") + new String("va"); System.out.println(str1==str1.intern()); 12

这时候在jdk1.7和jdk1.8中也会返回false。
这个差别在《深刻了解Java虚拟机》一书中给出的解释是java这个字符串曾经存在常量池了，所以我集体的揣测是可能初始化的时候jdk自身须要应用到java字符串，所以常量池中就提前曾经创立好了，如果了解错了，还请大家斧正，感激！

new String(“lonely”)创立了几个对象

下面的例子中我用了两个new String(“lonely”)和new String(“wolf”)相加，而如果去掉其中一个new String()语句的话，那么实际上jdk1.7和jdk1.8中返回的也会是false，而不是true。
这是为什么？看上面(

咱们假如一开始字符串常量池没有任何字符串

)：

只执行一个new String(“lonely”)会产生2个对象，1个在堆，1个在字符串常量池

这时候执行了String.intern()办法，String.intern()会去查看字符串常量池，发现字符串常量池存在longly字符串，所以会间接返回，不论是jdk1.6还是jdk1.7和jdk1.8都是查看到字符串存在就会间接返回，所以str1==str1.intern()失去的后果就是都是false，因为一个在堆，一个在字符串常量池。

执行new String(“lonely”)+new String(“wolf”)会产生5个对象，3个在堆，2个在字符串常量池

好了，这时候执行String.intern()办法会怎么样呢，如果在jdk1.7和jdk1.8会去查看字符串常量池,发现没有lonelywolf字符串，所以会创立一个指向堆中的字符串放到字符串常量池：

而如果是jdk1.6中，不会指向堆，会从新创立一个lonelywolf字符串放到字符串常量池，所以才会产生不同的运行后果。

留神：+号的底层执行的是new StringBuild().append()语句，所以咱们再看上面一个例子：

String s1 = new StringBuilder("aa").toString();System.out.println(s1==s1.intern());String s2 = new StringBuilder("aa").append("bb").toString();System.out.println(s2==s2.intern());//1.6返回false,1.7和1.8返回true

这个在jdk1.6版本全副返回false，而在jdk1.7和jdk1.8中一个返回false,一个返回true。多了一个append相当于下面的多了一个+号，原理是一样的。

符号援用

符号援用在下篇讲述类加载机制的时候会进行解释，这里暂不做解释，

感兴趣的能够关注我，注意我的JVM系列下一篇文章

。

jdk1.7和1.8的实现办法区的差别

办法区是Java虚拟机标准中的标准，然而具体如何实现并没有规定，所以虚拟机厂商齐全能够采纳不同的形式实现办法区的。

在HotSpot虚拟机中：

jdk1.7及之前版本

办法区采纳永恒代(Permanent Generation)的形式来实现，办法区的大小咱们能够通过参数-XX:PermSize和-XX:MaxPermSize来管制办法区的大小和所能容许最大值。

jdk1.8版本

移除了永恒代，采纳元空间(Metaspace)来实现办法区，所以在jdk1.8中对于永恒代的参数-XX:PermSize和-XX:MaxPermSize曾经被废除却代之的是参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize。元空间和永恒代的一个很大的区别就是元空间曾经不在jvm内存在，而是间接存储到了本地内存中。

如下，咱们再jdk1.8中设置-XX:PermSize和-XX:MaxPermSize会给出正告：

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize1m; support was removed in 8.0Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize1m; support was removed in 8.0

模仿办法区OutOfMemoryError

jdk1.7及之前版本

因为jdk1.7及之前都是永恒代来实现办法区，所以咱们能够通过设置永恒代参数来模仿内存溢出：
设置永恒代最大为2M:

-XX:PermSize=2m -XX:MaxPermSize=2m

而后执行如下代码：

package com.zwx;import java.util.ArrayList;import java.util.List;public class demo {    public static void main(String[] args) {        List<String> list = new ArrayList<>();        int i = 0;        while (true){            list.add(String.valueOf(i++).intern());        }    }}

最初报错OOM：PermGen space（永恒代溢出）。

Error occurred during initialization of VMjava.lang.OutOfMemoryError: PermGen space    at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:141)    at sun.misc.Launcher.<init>(Launcher.java:71)    at sun.misc.Launcher.<clinit>(Launcher.java:57)

jdk1.8

jdk1.8版本，因为永恒代被勾销了，所以模仿形式会不一样。
首先引入asm字节码框架依赖（后面介绍动静代理的时候提到cglib动静代理也是利用了asm框架来生成字节码，所以也能够间接cglib的api来生成）：

<dependency>            <groupId>asm</groupId>            <artifactId>asm</artifactId>            <version>3.3.1</version>        </dependency>

创立一个工具类去生成class文件：

package com.zwx.jvm.oom;import jdk.internal.org.objectweb.asm.ClassWriter;import jdk.internal.org.objectweb.asm.MethodVisitor;import org.objectweb.asm.Opcodes;import java.util.ArrayList;import java.util.List;public class MetaspaceUtil extends ClassLoader {    public static List<Class<?>> createClasses() {        List<Class<?>> classes = new ArrayList<Class<?>>();        for (int i = 0; i < 10000000; ++i) {            ClassWriter cw = new ClassWriter(0);            cw.visit(Opcodes.V1_1, Opcodes.ACC_PUBLIC, "Class" + i, null,                    "java/lang/Object", null);            MethodVisitor mw = cw.visitMethod(Opcodes.ACC_PUBLIC, "<init>",                    "()V", null, null);            mw.visitVarInsn(Opcodes.ALOAD, 0);            mw.visitMethodInsn(Opcodes.INVOKESPECIAL, "java/lang/Object",                    "<init>", "()V");            mw.visitInsn(Opcodes.RETURN);            mw.visitMaxs(1, 1);            mw.visitEnd();            MetaspaceUtil test = new MetaspaceUtil();            byte[] code = cw.toByteArray();            Class<?> exampleClass = test.defineClass("Class" + i, code, 0, code.length);            classes.add(exampleClass);        }        return classes;    }}

设置元空间大小

-XX:MetaspaceSize=5M -XX:MaxMetaspaceSize=5M 1

而后运行测试类模仿：

package com.zwx.jvm.oom;import java.util.ArrayList;import java.util.List;public class MethodArea {    public static void main(String[] args) {        //jdk1.8        List<Class<?>> list=new ArrayList<Class<?>>();        while(true){            list.addAll(MetaspaceUtil.createClasses());        }    }}

抛出如下异样OOM:Metaspace：

Java Virtual Machine Stacks(Java虚拟机栈)

每个Java虚拟机线程都有一个与线程同时创立的公有Java虚拟机栈。
Java虚拟机栈存储栈帧(Frame)。每个被调用的办法就会产生一个栈帧，栈帧中保留了一个办法的状态信息，如：局部变量，操作栈帧，方出进口等。

调用一个办法，就会产生一个栈帧，并压入栈内；一个办法调用实现，就会把该栈帧从栈中弹出，大抵调用过程如下图所示：

Java虚拟机栈中可能有上面两种异常情况：

如果线程执行所需栈深度大于Java虚拟机栈深度，则会抛出StackOverflowError。
上图能够晓得，其实办法的调用就是入栈和出栈的过程，如果始终入栈而不出栈就容易产生异样(如递归)。
如果Java虚拟机栈能够动静地扩大,然而扩大大小的时候无奈申请到足够的内存，则会抛出一个OutOfMemoryError。
大部分Java虚拟机栈都是反对动静扩大大小的，也容许设置固定大小(在Java虚拟机标准中两种都是能够的，具体要看虚拟机的实现)。

注：咱们常常说的JVM中的栈，个别指的就是Java虚拟机栈。

模仿栈内StackOverflowError

上面是一个简略的递归办法，没有跳出递归条件：

package com.zwx.jvm.oom;public class JMVStack {    public static void main(String[] args) {        test();    }    static void test(){        test();    }}

输入后果为：

Exception in thread "main" java.lang.StackOverflowError    at com.zwx.jvm.oom.JMVStack.test(JMVStack.java:15)    at com.zwx.jvm.oom.JMVStack.test(JMVStack.java:15)    .....

Native Method Stacks(本地办法栈)

本中央发栈相似于Java虚拟机栈，区别就是本地办法栈存储的是Native办法。本中央发栈和Java虚拟机栈在有的虚拟机中是合在一起的，并没有离开，如：Hot Spot虚拟机。

本地办法栈可能呈现如下异样：

如果线程执行所需栈深度大于本地办法栈深度，则会抛出StackOverflowError。
如果能够动静扩大本地办法栈，然而扩大大小的时候无奈申请到足够的内存，则会抛出OutOfMemoryError。

总结

本文次要介绍了jvm运行时数据区的结构，以及每局部区域到底都存了哪些数据，而后去模仿了一下常见异样的产生形式，当然，模仿异样的形式很多，要害要晓得每个区域存了哪些货色，模仿的时候对应生成就能够。

本文次要从总体上介绍运行时数据区，次要是有一个概念上的意识，下一篇，将会介绍类加载机制，以及双亲委派模式，介绍类加载模式的同时会对运行时数据区做更具体的介绍。

请关注我，一起学习提高