Java的永久代和元空间及各种常量池

最新推荐文章于 2022-05-01 11:48:09 发布

基础不牢，地动山摇...

最新推荐文章于 2022-05-01 11:48:09 发布

阅读量1.6k

点赞数 3

分类专栏： # Java虚拟机

本文链接：https://blog.csdn.net/danxiaodeshitou/article/details/104404495

版权

Java虚拟机专栏收录该内容

12 篇文章 0 订阅

订阅专栏

转载地址：https://www.cnblogs.com/jwcz/p/11772143.html

https://www.cnblogs.com/shen-qian/p/11277085.html

元空间替代永久代

元空间代替了永久代,所以JVM关于永久代的参数也都作废了，取而代之的是关于MetaSpace空间的参数。而且Mete Space是属于直接内存。示意图：

永久代

Java 的内存中有一块称之为方法区的部分，在 JDK8 之前， Hotspot 虚拟机中的实现方式为永久代（Permanent Generation），别的JVM都没有这个东西。

在过去（当自定义类加载器使用不普遍的时候），类几乎是“静态的”并且很少被卸载和回收，因此类也可以被看成“永久的”。另外由于类作为 JVM 实现的一部分，它们不由程序来创建，因为它们也被认为是“非堆”的内存。

永久代是一段连续的内存空间，我们在 JVM 启动之前可以通过设置-XX:MaxPermSize的值来控制永久代的大小，32 位机器默认的永久代的大小为 64M，64 位的机器则为 85M。

永久代的垃圾回收和老年代的垃圾回收是绑定的，一旦其中一个区域被占满，这两个区都要进行垃圾回收。但是有一个明显的问题，由于我们可以通过‑XX:MaxPermSize设置永久代的大小，一旦类的元数据超过了设定的大小，程序就会耗尽内存，并出现内存溢出错误 ( java.lang.OutOfMemoryError: PermGen space)。

为什么类的元数据占用内存会那么大？因为在 JDK7 之前的 HotSpot 虚拟机中，纳入字符串常量池的字符串被存储在永久代中，因此导致了一系列的性能问题和内存溢出错误。

为了解决这些性能问题，也为了能够让 Hotspot 能和其他的虚拟机一样管理，元空间就产生了。

元空间

元空间是 Hotspot 在 JDK8 中新加的内容，其本质和永久代类似，都是对 JVM 规范中方法区的实现。不过元空间与永久代之间最大的区别在于：

元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：

-XX:MetaspaceSize　

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

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

-XX:MinMetaspaceFreeRatio

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

-XX:MaxMetaspaceFreeRatio

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

移除永久代的影响

由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。因此，我们就不会遇到永久代存在时的内存溢出错误，也不会出现泄漏的数据移到交换区这样的事情。最终用户可以为元空间设置一个可用空间最大值，如果不进行设置，JVM 会自动根据类的元数据大小动态增加元空间的容量。

注意：永久代的移除并不代表自定义的类加载器泄露问题就解决了。因此，你还必须监控你的内存消耗情况，因为一旦发生泄漏，会占用你的大量本地内存，并且还可能导致交换区交换更加糟糕。

元空间内存管理

元空间的内存管理由元空间虚拟机来完成。

先前，对于类的元数据我们需要不同的垃圾回收器进行处理，现在只需要执行元空间虚拟机的 C++ 代码即可完成。在元空间中，类和其元数据的生命周期和其对应的类加载器是相同的。话句话说，只要类加载器存活，其加载的类的元数据也是存活的，因而不会被回收掉。

准确的来说，每一个类加载器的存储区域都称作一个元空间，所有的元空间合在一起就是我们一直说的元空间。当一个类加载器被垃圾回收器标记为不再存活，其对应的元空间会被回收。在元空间的回收过程中没有重定位和压缩等操作。但是元空间内的元数据会进行扫描来确定 Java 引用。

那具体是如何管理的呢？

元空间虚拟机负责元空间的分配，其采用的形式为组块分配。组块的大小因类加载器的类型而异。在元空间虚拟机中存在一个全局的空闲组块列表。

当一个类加载器需要组块时，它就会从这个全局的组块列表中获取并维持一个自己的组块列表。
当一个类加载器不再存活时，那么其持有的组块将会被释放，并返回给全局组块列表。
类加载器持有的组块又会被分成多个块，每一个块存储一个单元的元信息。组块中的块是线性分配（指针碰撞分配形式）。组块分配自内存映射区域。这些全局的虚拟内存映射区域以链表形式连接，一旦某个虚拟内存映射区域清空，这部分内存就会返回给操作系统。

运行时常量池

运行时常量池在 JDK6 及之前版本的 JVM 中是方法区的一部分，而在 HotSpot 虚拟机中方法区的实现是永久代(Permanent Generation)。所以运行时常量池也是在永久代的。

但是 JDK7 及之后版本的 JVM 已经将字符串常量池从方法区中移了出来，在堆（Heap）中开辟了一块区域存放字符串常量池。

String.intern()是一个 Native 方法，它的作用是：如果字符串常量池(非运行时常量池)中已经包含一个等于此 String 对象内容的字符串，则返回常量池中该字符串的引用；如果没有，则在常量池中创建与此 String 内容相同的字符串，并返回常量池中创建的字符串的引用。

存在的问题

前面已经提到，元空间虚拟机采用了组块分配的形式，同时区块的大小由类加载器类型决定。类信息并不是固定大小，因此有可能分配的空闲区块和类需要的区块大小不同，这种情况下可能导致碎片存在。元空间虚拟机目前并不支持压缩操作，所以碎片化是目前最大的问题。

常量池随永久代的变化

几种常量池：

（1）静态常量池：即*.class文件中的常量池，在Class文件结构中，最头的4个字节存储魔数，用于确定一个文件是否能被JVM接受，接着4个字节用于存储版本号，前2个为次版本号，后2个主版本号，再接着是用于存放常量的常量池，由于常量的数量是不固定的，所以常量池的入口放置一个U2类型的数据(constant_pool_count)存储常量池容量计数值。

这种常量池占用class文件绝大部分空间，主要用于存放两大类常量：字面量和符号引用量，字面量相当于Java语言层面常量的概念，如文本字符串、基础数据、声明为final的常值等；符号引用则属于编译原理方面的概念，包括了如下三种类型的常量：类和接口的全限定名、字段名称描述符、方法名称描述符。类的加载过程中的链接部分的解析步骤就是把符号引用替换为直接引用，即把那些描述符（名字）替换为能直接定位到字段、方法的引用或句柄（地址）。

（2）运行时常量池：虚拟机会将各个class文件中的常量池载入到运行时常量池中，即编译期间生成的字面量、符号引用，总之就是装载class文件。为什么它叫运行时常量池呢？因为这个常量池在运行时，里面的常量是可以增加的。如：“+”连接字符生成新字符后调用 intern（）方法(???)、生成基础数据的包装类型等等。

（3）字符串常量池：字符串常量池可以理解为是分担了部分运行时常量池的工作。加载时，对于class文件的静态常量池，如果是字符串就会被装到字符串常量池中。

（4）整型常量池：Integer，类似字符串常量池。管理-128--127的常量。类似的还有Character、Long等常量池（基本数据类型没有哦，Double、Float也没有常量池）

总结就是：

class文件有常量池存放这个类的信息，占用了大多数空间。但是运行时所有加载进来的class文件的常量池的东西都要放到运行时常量池，这个运行时常量池还可以在运行时添加常量。字符串常量池、Integer等常量池则是分担了运行时常量池的工作，

在永久代移除后，字符串常量池也不再放在永久代了，但是也没有放到新的方法区---元空间里，而是留在了堆里（为了方便回收？）。运行时常量池当然是随着搬家到了元空间里，毕竟它是装类的重要等信息的，有它的地方才称得上是方法区。