09_方法区

最新推荐文章于 2024-08-20 14:34:44 发布

Coder_yupeng

最新推荐文章于 2024-08-20 14:34:44 发布

阅读量100

点赞数

分类专栏： # JVM 文章标签： java jvm

本文链接：https://blog.csdn.net/weixin_43215305/article/details/120028825

版权

JVM 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

方法区

本文整理自尚硅谷宋红康老师在B站的视频，侵权即删。

本文的思维导图如下：

在这里插入图片描述

1 堆、栈和方法区的交互关系

以下以一段简单的代码说明堆、栈和方法区的交互关系：

per表示声明一个变量引用，存放于栈中；

new Person()表示创建一个Person类的对象，该对象存放于堆中；

Person表示上面的变量引用和对象对应的都是Person类，该类的类元数据位于方法区中。

Person  per = new Person();

在这里插入图片描述

2 方法区的理解

《Java虚拟机规范》中说明：“尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择进行圾收集或者进行压缩。”，但对于HotSpot虚拟机而言，方法区还有一个别名，叫做Non-Heap（非堆），目的就是要和堆分开。所以，方法区看作是一块独立于Java堆的内存空间。

方法区是各线程共享的内存区域。
方法区在JVM启动的时候被创建，它的实例的物理内存空间可以是不连续的。
方法区的大小，可以选择固定大小或者可扩展。如果方法区无法满足新的内存分配需求时，将抛出OOM异常。
方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，会导致方法区溢出，虚拟机会抛出内存溢出错误：java.lang.OutOfMemoryError: PermGen space或者java.lang.OutOfMemoryError: Metaspace，比例以下情况：
- 加载大量的第三方的jar包；
- Tomcat部署的工程过多（30-50个）；
- 大量动态的生成反射类。
关闭JVM就会释放该区域的内存。

方法区是虚拟机规范中提出的，不同的虚拟机可以有不同的实现，在HotSpot不同版本中方法区的演进如下：

在JDK7及以前，习惯上把方法区称为永久代（PermGen），从JDK8开始，使用元空间（Metaspace）作为方法区的实现。
- In JDK 8，classes metadata is now stored in the native heap and this space is called Metaspace.
本质上，方法区和永久代并不等价，这两个概念仅是对 hotspot而言的。《Java虚拟机规范》对如何实现方法区，不做统一要求，例如：BEA JRockit和IBMJ9中，就不存在永久代的概念。
- 现在来看，当年使用永久代，不是好的idea，导致Java程序更容易出现OOM（超过-XX:MaxPermsize上限）。
元空间的本质和永久代类似，都是对JVM规范中方法区的实现。两者的最大区别是：元空间不在虚拟机设置的内存中，而是使用本地内存。

在这里插入图片描述

3 设置方法区内存的大小

方法区的大小不是固定的，JVM可以根据应用的需要进行动态调整。

JDK7及之前：

通过-XX:Permsize来设置永久代的初始分配空间，默认值是20.75M。
通过-XX:MaxPermsize来设置永久代的最大可分配空间，32位机器默认是64M，64位机器模式是82M。
当JVM加载的类信息容量超过最大值，会报异常OutOfMemoryError: PermGen space。

JDK8及之后：

通过设置参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize来设置元空间的初始分配空间和最大可分配空间。
上述参数的默认值依赖于平台，Windows系统下，-XX:MetaspaceSize是21M，-XX:MaxMetaspaceSize的值是-1，即没有限制。
如果不指定元空间大小，使用默认值，方法区可能耗尽所有的可用系统内存。如果元空间发生溢出，虚拟机会抛出异常OutOfMemoryError:Metaspace。
通过-XX:Metaspacesize设置的初始元空间大小是一个初始的高水位线，一旦触及这个水位线，Full GC将会被触发并卸载不再使用的类，然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间，如果释放的空间不足，那么在不超过 MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值。所以，如果初始化的高水位线设置过低，高水位线调整情况会发生很多次，通过垃圾回收器的日志，可以观察到Full GC多次调用。为了避免频繁Full GC，建议将-XX:MetaspaceSize设置为一个相对较高的值。

如何解决方法区的OOM：

要解决OOM异常或heap space的异常，一般手段是通过内存映像分析工具（如 Eclipse Memory Analyzer）对dump出来的堆转储快照文件进行分析，重点是确认内存中的对象是否还都是必要存活的，即要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。
如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链，就能找到泄漏对象是通过怎样的路径与 GC Roots相关联，并导致垃圾收集器无法自动回收它们的。掌握泄漏对象的类型信息，以及 GC Roots引用链的信息后，就可以比较准确地定位出泄漏代码的位置。
如果不存在内存泄漏，即内存中的对象确实都还必须存活着，就应当根据机器物理内存，检查虚拟机的堆参数（-Xmx与-Xms），看是否还可以调大；从代码上检査是否存在某些对象生命周期过长、持有状态时间过长的情况（其实也算是内存泄漏），尝试减少程序运行期的内存消耗。

4 方法区的内部结构

一般来说，方法区存储以下内容：

类型信息、运行时常量池、静态变量、JIT代码缓存、域信息和方法信息等。

《深入理解Java虚拟机》书中对方法区存储内容描述如下：它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

A. 类型信息：

对每个加载的类型（类class、接口interface、枚举enum、注解annotation），JVM必须在方法区中存储以下类型信息：

这个类型的完整有效名称（全名=包名.类名）。
这个类型直接父类的完整有效名（对于interface或是java.lang. Object，都没有父类）。
这个类型的修饰符（ public, abstract,final的某个子集）。
这个类型实现接口的一个有序列表。

B. 域（Field）信息：

JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。

域的相关信息包括：

域名称
域类型
域修饰符（public，private，protected，static，final， volatile，transient的某个子集）。

C. 方法（Method）信息：

JVM必须在方法区中保存类型的所有方法的相关信息以及方法的声明顺序。

方法的相关信息包括：

方法名称
方法的返回类型（或void）
方法参数的数量和类型（按顺序）
方法的修饰符（public，private，protected，static，final，synchronized，native，abstract的一个子集）
方法的字节码（bytecodes）、操作数栈、局部变量表及大小（ abstract和native方法除外）
异常表（abstract和 native方法除外）
- 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

D. 静态变量（non-final的）

静态变量和类关联在一起，随着类的加载而加载，它们成为类数据在逻辑上的一部分。类变量被类的所有实例共享，即使没有类实例时你也可以访问它。

补充说明：被声明为final的静态变量的处理方法则不同，被static和final修饰的变量也称为全局变量，每个全局常量在编译的时候就会被赋值了。

public class Order {
        public static int num = 10;
        public static final int COUNT = 20;
}

通过javap命令反编译后的class文件：

在这里插入图片描述

E. 运行时常量池：

理解运行时常量池，需要了解字节码文件（ClassFile）中的常量池；方法区内部包含运行时常量池，字节码文件内部包含了常量池。

首先简单说明常量池：

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息，那就是常量池（ Constant Pool Table），包括各种字面量（数量值和字符串值）和对类型、域和方法的符号引用。常量池可以看做是一张表，虚拟机指令根据这张常量表，找到要执行的字面量、类名、方法名、参数类型等。

然后说明运行时常量池：

运行时常量池（Runtime Constant pool）是方法区的一部分。
常量池（Constant Pool Table）是class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
在加载类和接口到虚拟机后，就会创建对应的运行时常量池。
JVM为每个已加载的类型（类或接口）都维护一个运行时常量池，池中的数据项像数组项一样，是通过索引访问的。
运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，会转换为真实地址。
- 运行时常量池，相对于Class文件中的常量池的另一重要特征是：具备动态性。比如String.intern()方法会动态地向池中增加内容
运行时常量池类似于传统编程语言中的符号表（symbol table），但是它所包含的数据比符号表要更加丰富。
如果构造类或接口的运行时常量池时，所需的内存空间超过了方法区所能提供的最大值，则JVM会抛出OutOfMemoryError异常。

5 方法区的演进细节

HotSpot方法区在不同版本的变化：

版本	演进细节
JDK6及之前	方法区的实现为永久代，静态变量存放在永久代中，字符串常量池（StringTable）位于运行时常量池中。
JDK7	方法区的实现为永久代，但已经逐步“去永久代”，静态变量、字符串常量池移除，保存在堆中
JDK8	方法区的实现为本地内存的元空间，字符串常量池、静态变量仍在堆中

如下图所示：

JDK6及之前：

在这里插入图片描述

JDK7：

在这里插入图片描述

JDK8：

在这里插入图片描述

关于演进的几个问题：

A. 为什么用元空间替换永久代？

为永久代设置最大空间大小是难以确定的。
- 在某些场景下，如果动态加载类过多，容易产生Perm区的OOM：比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误；而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存，因此，默认情况下，元空间的最大大小仅受本地内存限制。
对永久代进行调优是很困难的。

B. 为什么调整字符串常量池的位置？

JDK7中将字符串常量池放到了堆空间中：因为永久代的回收效率很低，在Full GC时才会触发，而Full GC在老年代的空间不足、永久代不足时才会触发，这就导致字符串常量池回收效率不高；而我们开发中会有大量的字符串被创建，回收效率低会导致永久代内存不足。将字符串常量池放到堆里，能及时回收内存。

C. 几种不同的变量引用存放在哪里？

public class StaticObjTest {
    static class Test{
        // 静态变量
        // 一个java.lang.Class类型的对象实例引用了此变量
        static ObjectHolder staticObj = new ObjectHolder();
        // 实例变量
        ObjectHolder instanceObj = new ObjectHolder();

        void foo() {
            // 局部变量
            ObjectHolder localObj = new ObjectHolder()();
            System.out.println("done");
        }

    }

    private static class ObjectHolder{
    }

    public static void main(String[] args) {
        Test test = new StaticObjTest.Test();
        test.foo();
    }
}