Java8内存模型—永久代(PermGen)和元空间(Metaspace)
查看原文点击传送门：http://www.cnblogs.com/paddix/p/5309550.html提示:本文做了一些修改
一、JVM 内存模型
根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。
1、虚拟机栈：每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、返回地址等信息。栈的大小可以固定（编译时确定）也可以动态扩展。当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误，不过这个深度范围不是一个恒定的值，我们通过下面这段程序可以测试一下这个结果：
栈溢出测试源码：
| 1234567891011121314151617181920 | package com.paddx.test.memory; public class StackErrorMock { private static int index = 1; public void call(){ index++; call(); } public static void main(String[] args) { StackErrorMock mock = new StackErrorMock(); try { mock.call(); }catch (Throwable e){ System.out.println("Stack deep : "+index); e.printStackTrace(); } }} |
代码段 1
运行三次，可以看出每次栈的深度都是不一样的，输出结果如下。
至于红色框里的值是怎么出来的，就需要深入到 JVM 的源码中才能探讨，这里不作详细阐述。
虚拟机栈除了上述错误外，还有另一种错误，那就是当申请不到空间时，会抛出 OutOfMemoryError。这里有一个小细节需要注意，catch 捕获的是 Throwable，而不是 Exception。因为 StackOverflowError 和 OutOfMemoryError 都不属于 Exception 的子类。
2、本地方法栈：
这部分主要与虚拟机用到的 Native 方法相关，一般情况下， Java 应用程序员并不需要关心这部分的内容。
3、PC 寄存器：
PC 寄存器，也叫程序计数器。JVM支持多个线程同时运行，每个线程都有自己的程序计数器。倘若当前执行的是 JVM 的方法，则该寄存器中保存当前执行指令的地址；倘若执行的是native 方法，则PC寄存器中为空。
4、堆
堆内存是 JVM 所有线程共享的部分，在虚拟机启动的时候就已经创建。所有的对象和数组都在堆上进行分配。这部分空间可通过 GC 进行回收。当申请不到空间时会抛出 OutOfMemoryError。下面我们简单的模拟一个堆内存溢出的情况：
| 12345678910111213141516171819202122 | package com.paddx.test.memory; import java.util.ArrayList;import java.util.List; public class HeapOomMock { public static void main(String[] args) { List<byte[]> list = new ArrayList<byte[]>(); int i = 0; boolean flag = true; while (flag){ try { i++; list.add(new byte[1024 * 1024]);//每次增加一个1M大小的数组对象 }catch (Throwable e){ e.printStackTrace(); flag = false; System.out.println("count="+i);//记录运行的次数 } } }} |
代码段 2
运行上述代码，输出结果如下：
注意，这里我指定了堆内存的大小为16M，所以这个地方显示的count=14（这个数字不是固定的），至于为什么会是14或其他数字，需要根据 GC 日志来判断
5、方法区：
方法区也是所有线程共享。主要用于存储类的信息、常量池、方法数据、方法代码等。
二、HotSpot VM
在学习jvm的过程中，最容易混淆的概念就是jvm规范中内存区域的划分和jvm具体实现中jvm内存区域的划分，它们之间存在一个映射关系，下面是在不同jdk版本中HotSpot vm的具体实现情况（更详细的移步oracle官网的jdk realse notes）：
在JDK6以及之前版本的HotSpot VM里，GC heap包括young+old+perm gen，其中young+old gen里只会存放Java对象所以肯定属于jvm概念上的Java Heap；而perm gen里混合存储了部分Java对象以及应该属于Method Area的元数据（类数据、方法数据、symbols等），所以把perm gen说成就是Method Area也不对，说成就是Java Heap的一部分也不对——它是两者的混合。
在JDK7的HotSpot VM里，属于Method Area的symbols（符号引用）挪到了native heap而不再位于GC heap内；属于Method Area的static field挪到了java.lang.Class对象实例的末尾，被放在了young+old gen里。这么一来young+old gen也不能说只是纯粹的Java Heap了，而也存储了一些属于Method Area的数据。
在JDK8开始的HotSpot VM里，移除了perm gen,属于Method Area的元数据（类数据、方法数据等）也被挪到了native heap里。至此属于Method Area的数据里只有static field还存在GC heap中了。
| 1234 | package com.paddx.test.memory; public class Test {} |
代码段 3
| 12345678910111213141516171819202122232425 | package com.paddx.test.memory; 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(); } }} |
代码段 4
运行结果如下：
本例中使用的 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)和类的静态变量(class statics)转移到了young+old gen。我们可以通过一段程序来比较 JDK 1.6 与 JDK 1.7及 JDK 1.8 的区别，以字符串常量为例：
| 12345678910111213141516 | 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 合二为一。
