JVM Java 内存区域透彻分析（转）

　　　 Java8内存模型—永久代(PermGen)和元空间(Metaspace)

　　这篇文章主要介绍Java内存区域，也是作为Java虚拟机的一些最基本的知识，理解了这些知识之后，才能更好的进行Jvm调优或者更加深入的学习，本来这些知识是晦涩难懂的，所以希望能够讲解的透彻且形象。

0 运行时数据区域

　　JVM载执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。

　　Java 虚拟机所管理的内存一共分为Method Area（方法区）、VM Stack（虚拟机栈）、Native Method Stack（本地方法栈）、Heap（堆）、Program Counter Register（程序计数器）五个区域。

　　这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。具体如下图所示：

　　上图介绍的是JDK1.8 JVM运行时内存数据区域划分。1.8同1.7比，最大的差别就是：元数据区取代了永久代。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元数据空间并不在虚拟机中，而是使用本地内存。

1 程序计数器（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情况的内存区域。

其实，我感觉这块区域，作为我们开发人员来说是不能过多的干预的，我们只需要了解有这个区域的存在就可以，并且也没有虚拟机相应的参数可以进行设置及控制。

2 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异常现象。

3 本地方法栈（Native Method Stack）

　　本地方法栈（Native Method Stack） 与Java虚拟机栈作用很相似，它们的区别在于虚拟机栈为虚拟机执行Java方法（即字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。

　　在虚拟机规范中对本地方法栈中使用的语言、方式和数据结构并无强制规定，因此具体的虚拟机可实现它。甚至有的虚拟机（Sun HotSpot虚拟机）直接把本地方法栈和虚拟机栈合二为一。与虚拟机一样，本地方法栈会抛出StackOverflowError和OutOfMemoryError异常。

使用-Xss参数减少栈内存容量（更多的JVM参数可以参考这篇文章：深入理解Java虚拟机-常用vm参数分析）

这个例子中，我们将栈内存的容量设置为256K（默认1M），并且再定义一个变量查看栈递归的深度。

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();

        } catch (Throwable e) {

            e.printStackTrace();

        }

    }

}

运行时设置JVM参数

输出结果：

4 Java堆（Heap）

　　对于大多数应用而言，Java堆（Heap）是Java虚拟机所管理的内存中最大的一块，它被所有线程共享的，在虚拟机启动时创建。此内存区域唯一的目的是存放对象实例，几乎所有的对象实例都在这里分配内存，且每次分配的空间是不定长的。在Heap 中分配一定的内存来保存对象实例，实际上只是保存对象实例的属性值，属性的类型和对象本身的类型标记等，并不保存对象的方法（方法是指令，保存在Stack中）,在Heap 中分配一定的内存保存对象实例和对象的序列化比较类似。

Java堆是垃圾收集器管理的主要区域，因此也被称为 “GC堆（Garbage Collected Heap）” 。从内存回收的角度看内存空间可如下划分：

新生代（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参数分析

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频繁。

5 方法区（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对象的字符串，则直接返回池中的字符串；否则，加入到池中，并返回。

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及以后，去掉了永久代。

6 直接内存

　　直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。但这部分内存也被频繁运用，而却可能导致OutOfMemoryError异常出现。

　　这个我们实际中主要接触到的就是NIO，在NIO中，我们为了能够加快IO操作，采用了一种直接内存的方式，使得相比于传统的IO快了很多。

　　在NIO引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能避免在Java堆和Native堆中来回复制数据，在一些场景里显著提高性能。

　　在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统的限制），从而导致动态扩展时出现OutOfMemoryError异常。

不同jdk版本：永久代(PermGen)和元空间(Metaspace)的了解

方法区：

　　方法区也是所有线程共享。主要用于存储类的信息、常量池、方法数据、方法代码等。方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。关于方法区内存溢出的问题会在下文中详细探讨。

PermGen（永久代）

　　绝大部分 Java 程序员应该都见过 "java.lang.OutOfMemoryError: PermGen space "这个异常。这里的 “PermGen space”其实指的就是方法区。不过方法区和“PermGen space”又有着本质的区别。前者（方法区）是 JVM 的规范，而后者（永久带PermGen space）则是 JVM 规范的一种实现，并且只有 HotSpot 才有 “PermGen space”，而对于其他类型的虚拟机，如 JRockit（Oracle）、J9（IBM）并没有“PermGen space”。由于方法区主要存储类的相关信息，所以对于动态生成类的情况比较容易出现永久代的内存溢出。最典型的场景就是，在 jsp 页面比较多的情况，容易出现永久代内存溢出。我们现在通过动态生成类来模拟 “PermGen space”的内存溢出：

代码段 3 Test类

package com.paddx.test.memory;

public class Test {

}

代码段 4 PermGenOomMock类

import java.io.File;

import java.net.URL;

import java.net.URLClassLoader;

import java.util.ArrayList;

import java.util.List;

public class PermGenOomMock{

    public static void main(String[] args) {

        URL url = null;

        List<ClassLoader> classLoaderList = new ArrayList<ClassLoader>();

        try {

            url = new File("/tmp").toURI().toURL();

            URL[] urls = {url};

            while (true){

                ClassLoader loader = new URLClassLoader(urls);

                classLoaderList.add(loader);

                loader.loadClass("com.paddx.test.memory.Test");

            }

        } catch (Exception e) {

            e.printStackTrace();

        }

    }

}

运行结果如下：

　　本例中使用的 JDK 版本是 1.7，指定的 PermGen 区的大小为 8M。通过每次生成不同URLClassLoader对象来加载Test类，从而生成不同的类对象，这样就能看到我们熟悉的 "java.lang.OutOfMemoryError: PermGen space " 异常了。这里之所以采用 JDK 1.7，是因为在 JDK 1.8 中， HotSpot 已经没有 “PermGen space”这个区间了，取而代之是一个叫做 Metaspace（元空间）的东西。下面我们就来看看 Metaspace 与 PermGen space 的区别。

三、Metaspace（元空间）

　　其实，移除永久代的工作从JDK1.7就开始了。JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap。但永久代仍存在于JDK1.7中，并没完全移除，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。我们可以通过一段程序来比较 JDK 1.6 与 JDK 1.7及 JDK 1.8 的区别，以字符串常量为例：

package com.paddx.test.memory;

import java.util.ArrayList;

import java.util.List;

public class StringOomMock {

    static String  base = "string";

    public static void main(String[] args) {

        List<String> list = new ArrayList<String>();

        for (int i=0;i< Integer.MAX_VALUE;i++){

            String str = base + base;

            base = str;

            list.add(str.intern());

        }

    }

}

这段程序以2的指数级不断的生成新的字符串，这样可以比较快速的消耗内存。我们通过 JDK 1.6、JDK 1.7 和 JDK 1.8 分别运行：

JDK 1.6 的运行结果：

JDK 1.7的运行结果：

JDK 1.8的运行结果：

　　从上述结果可以看出，JDK 1.6下，会出现“PermGen Space”的内存溢出，而在 JDK 1.7和 JDK 1.8 中，会出现堆内存溢出，并且 JDK 1.8中 PermSize 和 MaxPermGen 已经无效。因此，可以大致验证 JDK 1.7 和 1.8 将字符串常量由永久代转移到堆中，并且 JDK 1.8 中已经不存在永久代的结论。现在我们看看元空间到底是一个什么东西？

　　元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：

　　-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
　　-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。

　　除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
　　-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
　　-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

现在我们在 JDK 8下重新运行一下代码段 4，不过这次不再指定 PermSize 和 MaxPermSize。而是指定 MetaSpaceSize 和 MaxMetaSpaceSize的大小。输出结果如下：

从输出结果，我们可以看出，这次不再出现永久代溢出，而是出现了元空间的溢出。

四、总结

　　通过上面分析，大家应该大致了解了 JVM 的内存划分，也清楚了 JDK 8 中永久代向元空间的转换。不过大家应该都有一个疑问，就是为什么要做这个转换？所以，最后给大家总结以下几点原因：

　　1、字符串存在永久代中，容易出现性能问题和内存溢出。

　　2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。

　　3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

　　4、Oracle 可能会将HotSpot 与 JRockit 合二为一。