JVM 灵性一问——为什么用元空间替换永久代?

Posted xhmj12

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JVM 灵性一问——为什么用元空间替换永久代?相关的知识,希望对你有一定的参考价值。

来源:blog.csdn.net/qq_33591903

JVM 灵性一问——为什么用元空间替换永久代?

前言

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

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

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

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

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

方法区

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

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

Java7及以前版本的永久代的结构

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

永久代与堆的构造如下:

关于堆中的Eden、from与to区域,可以先参考我的历史文章。

从上图中可以看到,永久代与堆中的老年代是连续的,这里的连续指的是物理地址连续,永久代本身并不在堆中。因此,老年代与永久代其中一个满了,都会触发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),不再与堆连续,而是直接存在于本地内存中,也就是机器的内存。理论上机器内存有多大,元空间的野心就有多大。但可以通过以下的参数来设置元空间的大小:

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

  • -XX:MaxMetaspaceSize,最大空间,默认是没有限制的。

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

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

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

在使用-XX:MaxMetaspaceSize显示指定元空间的大小为一个比较小的值,接着在循环中动态加载过多的类,那么会报出"java.lang.OutOfMemoryError: Metaspace"异常。

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

Java8中,使用元空间替换永久代的原因

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

为什么移除持久代

  • 它的大小是在启动时固定好的——很难进行调优。-XX:MaxPermSize,设置成多少好呢?

  • HotSpot的内部类型也是Java对象:它可能会在Full GC中被移动,同时它对应用不透明,且是非强类型的,难以跟踪调试,还需要存储元数据的元数据信息(meta-metadata)。

  • 简化Full GC:每一个回收器有专门的元数据迭代器。

  • 可以在GC不进行暂停的情况下并发地释放类数据。

  • 使得原来受限于持久代的一些改进未来有可能实现

元空间的特点

  • 充分利用了Java语言规范中的好处:类及相关的元数据的生命周期与类加载器的一致。

  • 每个加载器有专门的存储空间

  • 只进行线性分配

  • 不会单独回收某个类

  • 省掉了GC扫描及压缩的时间

  • 元空间里的对象的位置是固定的

  • 如果GC发现某个类加载器不再存活了,会把相关的空间整个回收掉

以上是关于JVM 灵性一问——为什么用元空间替换永久代?的主要内容,如果未能解决你的问题,请参考以下文章

JVM1.7和1.8的永久代和元空间的变化

JVM09_方法区

JVM 调优总结

JVM 知识点补充——永久代和元空间

方法区永久代元空间

JVM内存:年轻代老年代永久代(推荐 转)