[解密JVM-08] 运行时数据区域：方法区

1、前言

  本章内容讲的是运行时数据区最后一个内容：方法区。

  回顾一下运行时数据区的其他部分，例如虚拟机栈、堆等，和本章的方法区有什么联系呢？下面用一张图就可以大致说明了：

  类加载器加载 Class 文件，然后把类信息保存在方法区，我们 new 出来的对象的引用是保存在虚拟机栈的局部变量表当中，而对象的实体就在堆当中。

2、方法区的理解

2.1 简介

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

  方法区和堆一样，是线程共享的内存区域。
  方法区在 JVM 启动的时候被创建，并且它的实际物理内存空间和 Java 堆一样都可以是不连续的。
  方法区和堆一样，可以固定大小或者扩展大小。
  方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，那么 JVM 同样会抛出内存溢出错误：java.lang.OutOfMemoryError:PermGen space 或者 java.lang.OutOfMemoryError:Metaspace。

2.2 加载类的数量

  我们来启动一个源代码：

public class MethodAreaDemo {
    public static void main(String[] args) {
        System.out.println("start...");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("end...");
    }
}

  启动后使用 jvisualvm 工具，在监视界面打开可以看到：

  可以看到就这么简单的一个源代码，就加载了 1630 多个类。

2.3 永久代和元空间

  首先我们要明白一点：方法区是 JVM 规范中描述的，但是不同的 JVM 有不同的实现，对这些实现也都有不同的名称。
  例如，在 JDK7 以前的 JVM 对方法区的实现中，把方法区称为永久代。在 JDK8 以后，方法区的实现叫做原空间。
  本质上，方法区和永久代不等价，前者是规范，后者是实现，仅是对 HotSpot 而言的。比如说对于 BEA Jrockit 或者 IBM J9 等 Java 虚拟机，它们对于方法区的实现就不是永久代，它们根本没有永久代这个概念。
  JDK 7 以前的是这样的：

  JDK 8 是这样的：

  到了 JDK8 以后，彻底废弃了永久代这个概念，和 JRockit、J9 一样，对方法区的实现用元空间（Metaspace）来代替。

  元空间的本质和永久代类似，都是对 JVM 规范中方法区的实现，不过元空间于永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存。
  不要误以为永久代和元空间只是名字不同，它们的内部结构也调整了。
  根据《Java 虚拟机规范》规定，如果方法区无法满足新的内存分配需求，就要抛出 OOM 异常。

3、设置方法区大小与OOM

3.1 参数设置

  和其他内存一样，方法区的大小不一定是固定的，JVM 可以根据应用的需要动态调整。

  在 JDK7 以前，叫做调整永久代的大小，通过参数-XX:PermSize来设置永久代的初始大小，默认值是 20.75 M；通过参数-XX:MaxPermSize来设置永久代最大可分配空间，32位系统默认是 64 M，64 位系统默认是 82 M。

  在 JDK8 及以后，叫做调整元空间大小，通过参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize来分别设置初始大小和最大空间。元空间大小的默认值是依赖于平台的，在 Windows 系统下，初始大小是 21M，最大无上限，取决于本地内存。

  元空间和永久代不同，元空间如果不指定大小，在默认情况下，JVM 是会耗尽所有可用的系统本地内存。如果元空间溢出，JVM 同样抛出 OOM 错误。

  元空间的初始大小不设置默认 21 M，如果达到这个大小，Full GC就会被触发来卸载没用的类，然后这个初始大小会自动重新设置，设置大小取决于 GC 之后释放了多少元空间，释放的少，就提高一点，释放的多，就适当降低。

  如果元空间初始值设置的低，很容易触发 Full GC，为了避免频繁 Full GC，应该根据实际情况设置一个相对较高的值。

  下面通过代码来掩饰 JDK7 和 JDK8 的方法区溢出情况。

3.2 永久代或方法区的 OOM 显示

  在 JDK8 环境下，源代码如下：

public class OOMTest extends ClassLoader {
    public static void main(String[] args) {
        int j = 0;
        try {
            OOMTest test = new OOMTest();
            for (int i = 0; i < 10000; i++) {
                //创建ClassWriter对象，用于生成类的二进制字节码
                ClassWriter classWriter = new ClassWriter(0);
                //指明版本号，修饰符，类名，包名，父类，接口
                classWriter.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
                //返回byte[]
                byte[] code = classWriter.toByteArray();
                //类的加载
                test.defineClass("Class" + i, code, 0, code.length);//Class对象
                j++;
            }
        } finally {
            System.out.println(j);
        }
    }
}

  设置元空间大小：-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m，启动后结果如下：

  这个 Compressed class space 是元空间的一部分，后面章节详细介绍元空间的时候会讲到。

  在 JDK7 环境下，源代码为：

public class OOMTest extends ClassLoader {
    public static void main(String[] args) {
        int j = 0;
        try {
            OOMTest test = new OOMTest();
            for (int i = 0; i < 10000; i++) {
                //创建ClassWriter对象，用于生成类的二进制字节码
                ClassWriter classWriter = new ClassWriter(0);
                //指明版本号，修饰符，类名，包名，父类，接口
                classWriter.visit(Opcodes.V1_7, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
                //返回byte[]
                byte[] code = classWriter.toByteArray();
                //类的加载
                test.defineClass("Class" + i, code, 0, code.length);//Class对象
                j++;
            }
        } finally {
            System.out.println(j);
        }
    }
}

  设置启动参数为：-XX:PermSize=5m -XX:MaxPermSize=5m，启动后效果如下：

  可见，永久代溢出。

3.3 OOM 的解决思路

  针对方法区的溢出，如何来处理呢？

  1、要解决 OOM 异常或 heap space 异常，一般是先通过内存映像工具对 dump 出来的堆转储快照进行分析，重点是确认内存中的对象是否必要的，即先确定到底是内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。

  2、如果是内存泄漏，可用进一步使用工具查看泄漏对象到 GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与 GC Roots 相关联导致垃圾收集器无法自动回收它们。掌握了泄漏对象的类型信息，以及 GC Roots 引用链的信息，就可以比较准确地定位出泄漏代码的位置。

  3、如果是内存溢出，就应当检查 JVM 的堆参数（-Xmx 和 -Xms），与物理内存对比看是否还可以调大一点，从代码上检查是否存在一些对象的生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

4、方法区的内部结构

4.1 简介

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

4.2 类型信息

  这里说的类型包括：类 Class、接口 Interface、枚举 enum、注解 annotation。
  这些都可以单独称为一个 Class 文件。

  对每个加载的类型，JVM 必须在方法区存储以下的 Class 文件的信息：
  1、这个类型的完整有效名称（全名=包名.类名）；
  2、这个类型直接父类的完整有效名称（接口或者 Object 类没有父类）；
  3、这个类型的修饰符（public、abstract、final的某个子集）；
  4、这个类型直接接口的一个有序列表。

  既然 JVM 可以从 Class 获取上面4个信息，说明这 4 个信息已经存储在 Class 字节码文件当中。
  我们写一段源代码：

package pers.klb.jvmdemo;

/**
 * @program: JvmDemo2020
 * @description: 测试方法区的内部结构
 * @author: Meumax
 * @create: 2020-07-19 20:23
 **/
public class TestInnerStructure extends MyClass implements MyInterface01, MyInterface02 {
    public static final String name = "123";
    public static int a = 1;
    public String b;

    public void method01(int arg1, int atg2) {
        try {
            arg1 = atg2 + 1;
            atg2 = arg1 - 1;
        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

interface MyInterface01 {

}

interface MyInterface02 {

}

class MyClass {

}

  解析字节码后：

4.3 域（Field）信息

  JVM 必须在方法区保存类型的所有域的相关信息以及域的声明顺序。
  域的相关信息包括：域名称、域类型、域修饰符。
  同理，既然是从 Class 文件中读取的，那字节码文件就应该已经有这些信息。

4.4 方法（Method）信息

  JVM 必须保存所有方法的以下信息，同域信息一样包括声明顺序：
  1、方法名称；
  2、方法的返回类型；
  3、方法参数的数量和类型；
  4、方法的修饰符；
  5、方法的字节码、操作数栈、局部变量表及大小；
  6、异常表
  我们看 Class 字节码文件的解析：

4.5 静态变量

  被 static 修饰的变量我们称为类变量，也叫静态变量，它随着类的加载而加载，它们称为类数据在逻辑上的一部分。类变量被类的所有实例共享，即使没有类实例，也可以访问它。
  比如一段代码如下：

public class MethodAreaTest {
    public static void main(String[] args) {
        Order order = null;
        order.hello();
        System.out.println(order.count);
        System.out.println(order.a);
    }
}

class Order {
    public int a;
    public static int count = 1;
    public static final int number = 2;

    public static void hello() {
        System.out.println("hello!");
    }
}

  运行结果如下：

  虽然 order 的实体为 null，但是它属于 Order 类型，可以调用类型相关的信息，而非类变量就必须要有实例对象才能调用了。
  我们前面学到类加载机制的时候知道，被声明 final 的类变量的处理方法是不同的，每一个全局常量在编译的时候就会被分配了，比如上面代码的 number ，在编译器，值就已经确定了，我们看字节码文件：

  static 修饰的变量会在链接阶段的准备步骤先赋值为零值，然后在初始化阶段赋值为代码写的值。其他变量跟着实例对象情况而定。

4.6 运行时常量池

  我们在看 Class 文件的时候，里面有一个常量池，这个常量池被加载到内存后，在方法区里叫做运行时常量池。

  Class 文件加载的信息都保存在方法区，字节码文件的常量池可以参考我在第一章介绍字节码文件结构的时候写的：[解密JVM-01] Class类文件的结构。
  一个有效的 Class 字节码文件除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息，就是常量池，它包含各种字面量和对类型、域和方法的符号引用。

  那为什么需要常量池呢？

  一个 Java 源文件中的类、接口，编译后产生一个字节码文件。而 Java 中的字节码需要数据支持，通常这种数据会很大，以至于不能直接存到字节码里，换另一种方式，可以存到常量池，字节码文件就包含了指向常量池的引用。在动态链接的时候就会用到运行时常量池，把符号引用转为直接引用。

  比如一段代码如下：

public class MethodAreaTest2 {
    public static void main(String[] args) {
        Object o = new Object();
    }
}

  其中，Object o = new Object();对应的指令为：

  new 后面跟着一个 #2，#2 的内容为右侧的注释。invokespecial 后面跟着一个 #1，#1 的内容也在右侧注释。即指令包含被操作的对象，这些对象在字节码文件中是以符号引用的方式表示的。

  到了动态链接，这些符号引用就会变为直接引用，即这些指令后面不会跟着符号，而是直接真实的地址。

  因此，常量池可以看成一个表，JVM 指令根据这张表找到要执行的类名、方法名、参数类型、字面量等类型。

  Class 字节码文件的常量池用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到运行时常量池中。
  JVM 为每一个已加载的类型（类或接口）都维护一个常量池，池中的数据项像数组项一样，通过索引访问。

  注意，运行时常量池包含多种不同的常量，包括编译器就已经确定的数值字面量，也包括运行期解析后才获得的方法或者字段引用。此时不再是常量池中的符号地址了，而是真实地址了。

  这里有一个特别需要注意的地方：方法区存的都是变量或者引用，即是地址，而对象实体全部都在堆区。

  同样，当创建的类或接口的运行时常量池时，如果构造运行时常量池的内存空间超过了方法区所能提供的最大值，直接 OOM。

5、方法区的演进细节

  首先要明确的时，只有 HotSpot 虚拟机在 JDK7 以前才有永久代。对于 BEA JRockit、IBM J9等来说，是不存在永久代的概念的。原则上，如何实现方法区属于虚拟机的实现细节，不做约束，也不要求统一。

  下面说明以下 HotSpot 虚拟机中方法区的变化：

  在 JDK6 以前，有永久代，静态变量放在永久代上。

  对于 JDK7 ，有永久代，但已经逐步“去永久代”，字符串常量池、静态变量被移除，保存在堆中。

  到了 JDK8 以后，没有永久代，类型信息、字段、方法、运行时常量池保存在本地内存的元空间中，但字符串常量池、静态变量仍在堆上。

  问题1：为什么会有这样的演进呢，设计者是基于什么样的考虑呢？

  1、永久代的空间大小很难把握，在某些场景下，如果动态加载的类过多，容易产生 OOM，而元空间并不在虚拟机内存中，而是使用本地内存，元空间的大小仅受本地内存的限制。
  2、永久代进行调优是很困难的。

  问题2：为什么要把字符串常量池从 JDK6 的运行时常量池中，变为 JDK7 和 JDK8 的堆中？

  因为永久代的回收效率太低了，在 Full GC 的时候才会触发，而上一章节已经学过，Full GC 是效率最差的，在堆的老年代空间不足或者 JDK7 以前的永久代不足时才会触发。这就导致字符串常量池回收效率不高，然后我们的开发中会有大量的字符串被创建、回收，如果放在 GC 触发频率低的地方，很容易导致永久代内存不足，如果放在 GC 频率高的堆中，可以及时回收内存。

6、方法区的垃圾回收

  《Java 虚拟机规范》堆方法区的约束是很宽松的，提到过可以不要求虚拟机在方法区实现垃圾收集。

  一般来说，方法区存储的是类型信息，而类型的卸载条件是不像对象那样，只要没有引用就直接当垃圾清理，类型的卸载条件相当苛刻，但是类型的卸载有时候又是必要的。方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量、不再使用的类型（类或接口）。

  常量池中主要存放两大类常量：字面量、符号引用。

  字面量：比较接近 Java 语言层次的常量的概念，比如文本字符串、被声明为 final 的常量的值等。
  符号引用：属于编译原理方面的概念，包括：类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。

  HotSpot 虚拟机对常量池的回收策略很明确：只要常量池中的常量没有被任何地方引用，则可以回收，回收废弃的常量和回收堆中的对象非常类似。

  判定一个常量是否被“废弃”还是相对简单的，但是要判断一个类型是否“不再被使用”可就难了，需要同时满足下面三个条件：
  1、该类的所有实例都已经被回收，即 Java 堆中不再存在该类及其任何派生子类的实例；
  2、加载该类的类加载器已经被会后，这一点很难达到，除非是精心设计的可替换类加载器的场景；
  3、该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

  即使达到上面三个条件，也仅仅是“可回收”的状态，并不像对象一样，没有引用就一定会被回收。关于类型是否回收，还要看是否设置相应的参数，HotSpot 提供了-Xnoclassgc参数进行控制。

  在大量使用反射、动态代理、CGLib 等字节码框架场景和动态生成 JSP 以及 OSGi 这类频繁自定义类加载器的场景中，通常需要 JVM 具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

7、小结

  本章详细讲解了方法区的相关内容，至此，运行时数据区的所有组成部分都介绍完毕。