JDK1.8 你好,Metaspace；再见，永久代

JDK1.8 你好,Metaspace;再见，永久代

前言

首先需要明确的是，以下我们讨论的HotSpot虚拟机，其他类型的虚拟机，例如JRockit与J9等，压根就没有永久代的概念。因此，下面所说的“虚拟机”都是HotSpot版本的。

要想理解这种变化的原因，需要先理解方法区、永久代与元空间的概念与之间的关系。

方法区与永久代、元空间之间的关系

方法区是一种规范，不同的虚拟机厂商可以基于规范做出不同的实现，永久代和元空间就是出于不同JDK版本的实现。

说白了，方法区就像是一个接口，永久代与元空间分别是两个不同的实现类而已。只不过永久代是这个接口最初的实现类，后来这个接口一直进行变更，直到最后彻底废弃这个实现类，由新实现类——元空间进行替代。

方法区

借用《深入理解Java虚拟机——JVM高级特性与最佳实践》中介绍方法区的段落

方法区和堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。

java7及以前版本的JVM内存布局

在Java7及以前的版本，是存在永久代的。在Java7版本时，永久代已经发生了悄悄的变化。等到Java8时，彻底废弃了永久代，由元空间替换。

永久代与堆的构造如下：

从上图中可以看到，永久代与堆中的老年代是连续的，这里的连续指的是物理地址连续，永久代本身并不在堆中。因此，老年代与永久代其中一个满了，都会触发Full GC。

我们可以使用以下的命令，来显示指定永久代的大小：

-XX:PremSize：设置永久代的初始大小
-XX:MaxPermSize: 设置永久代的最大值
由于方法区主要存储类的相关信息，所以对于动态生成类的情况比较容易出现永久代的内存溢出。最典型的场景就是，在 jsp 页面比较多的情况，容易出现永久代内存溢出，会报出"java.lang.OutOfMemoryError: PermGen space "异常。

java7永久代的变化

在Java7时，任然有永久代，永久代与堆中的老年代连续，但永久代中存储的部分数据已经开始转移到Java Heap或Native Memory中了，比如：

• 符号引用(Symbols)转移到了Native Memory
• 字符串常量池(interned strings)转移到了Java Heap
• 类的静态变量(class statics)转移到了Java Heap

现在分别在Java6、7、8环境中循环调用String.intern()方法，那么分别会报出以下区域的内存溢出异常

• Java6时，内存溢出区域为永久代。因为在Java6及之前，字符串常量池在永久代中
• Java7时，内存溢出区域为堆中。因为在Java7时，字符串常量池被移到堆中了
• Java8时，内存溢出区域任然为堆中，不过此时已经没有永久代了

Java8开始，永久代就已经消失了，由元空间取而代之。

元空间（Metaspace）

元空间（Metaspace），不再与堆连续，而是直接存在本地内存中，也就是机器的内存。理论上机器的内存有多大，元空间就可以有多大。但可以通过以下参数来设置元空间的大小：

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

除了以上两个指定大小的选项以外，还有两个与GC相关的属性：

• -XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
• -XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集

在Java8时，任然使用PremSize或MaxPermSize设置永久代的大小时，会被编译器忽略或警告。

java8中，使用元空间代替永久代的原因

在之前的版本中，字符串常量池存在于永久代中，在大量使用字符串的情况下，非常容易出现OOM的异常。此外，JVM加载的class的总数，方法的大小等都很难确定，因此对永久代大小的指定难以确定。太小的永久代容易导致永久代内存溢出，太大的永久代则容易导致虚拟机内存紧张。

Metaspace 之一：Metaspace整体介绍（永久代被替换原因、元空间特点、元空间内存查看分析方法）