JVM 方法区(Method Area)

JVM 方法区

方法区的理解

运行时数据区：

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载
的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然《Java虚拟机规范》中把 方法区描述为堆的一个逻辑部分，但是它却有一个别名叫作==“非堆”（Non-Heap）==，目的是与Java堆区 分开来。

• 方法区（Method Area）与Java堆一样，是各个线程共享的内存区域。多个线程同时加载统一个类时，只能有一个线程能加载该类，其他线程只能等等待该线程加载完毕，然后直接使用该类，即类只能加载一次。
• 方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的。
• 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。
• 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：java.lang.OutofMemoryError:PermGen space或者java.lang.OutOfMemoryError:Metaspace
  • 加载大量的第三方的jar包
  • Tomcat部署的工程过多（30~50个）
  • 大量动态的生成反射类
• 关闭 JVM 就会释放这个区域的内存。

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

JVM运行时的结构图：

从线程的角度来看：

三者交互关系：

HotSpot中方法区的演进

在JDK 8以前，许多Java程序员都习惯在HotSpot虚拟机上开发、部署程序，很多人都更愿意把方法区称呼为“永久代”（Permanent Generation），或将两者混为一谈。本质上这两者并不是等价的，因为仅仅是当时的HotSpot虚拟机设 计团队选择把收集器的分代设计扩展至方法区，或者说使用永久代来实现方法区而已，这样使得HotSpot的垃圾收集器能够像管理Java堆一样管理这部分内存，省去专门为方法区编写内存管理代码的工作。但是对于其他虚拟机实现，譬如BEA JRockit、IBM J9等来说，是不存在永久代的概念的。

在Oracle收购了JRockit后就决定将JRockit的优点移植到HotSpot上，但因为两者对方法区实现的差异而面临诸多困难。在JDK6时就有放弃永久代，该用本地内存实现方法区的计划了。

要点说明：

1. 只有HotSpot才有永久代。BEA、JRockiit、IBM J9等来说，是不存在永久代概念的。原则上如何实现方法区属于虚拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。

2. HotSpot中方法区的变化：

   版本	变化说明
   jdk1.6及之前	有永久代（permanent generation），静态变量存放在永久代上。
   jdk1.7	有永久代，但已经逐步”去永久代“，字符串常量池、静态变量改为保存在堆当中
   jdk1.8及之后	无永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍然在堆当中

永久代为什么要使用元空间替换

• 随着Java8的到来，HotSpot VM中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间（Metaspace）。
• 由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。
• 这项改动是很有必要的，原因有：
  1. 为永久代设置空间大小是很难确定的。在某些场景下，如果动态加载类过多，容易产生Perm区的OOM。比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误。Exception in thread 'dubbo client x.x connector' java.lang.OutOfMemoryError:PermGen space而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。 因此，默认情况下，元空间的大小仅受本地内存限制。
  2. 对永久代进行调优是很困难的。方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再用的类型，方法区的调优主要是为了降低Full GC
     1. 有些人认为方法区（如HotSpot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK11时期的ZGC收集器就不支持类卸载）。
     2. 一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻**。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。

字符串常量池(StringTable)为什么要调整

JDK7中将StringTable放到了堆空间中。因为永久代的回收效率很低，在Full GC的时候才会执行永久代的垃圾回收，而Full GC是老年代的空间不足、永久代不足时才会触发。

这就导致StringTable回收效率不高，而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

方法区的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。

方法区的内部结构

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

类型信息

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

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

域（Field）信息

• JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
• 域的相关信息包括：域名称，域类型，域修饰符（public，private，protected，static，final，volatile，transient的某个子集）

方法（Method）信息

JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序：

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

代码举例

定义一个类，实现一些接口并且定义一些属性、方法、代码块。

import java.io.Serializable;

public class MethodAreaTest implements Serializable, Comparable {

    private int value;

    private double dValue;

    public int pValue;

    public static int num = 1;

    public static final String STATE = "200";

    public final int CODE = 999;

    public MethodAreaTest() {
    }

    public MethodAreaTest(int value, double dValue, int pValue) {
        this.value = value;
        this.dValue = dValue;
        this.pValue = pValue;
    }

    public MethodAreaTest(int value) {
        this.value = value;
    }

    static {
        int a;
    }

    {
        int b;
    }


    public static void main(String[] args) {

    }

    public void method() {
        Object obj = new Object();
    }

    public int add(int a, int b) {
        return a + b;
    }

    private int sub(int a, int b) {
        return a - b;
    }

    @Override
    public int compareTo(Object o) {
        return 0;
    }
}

进用到编译生成的.class文件目录下：使用 javap -v MethodAreaTest.class > text.txt 命令将内容写到text.txt文件中，如果要查看私有结构还需要加入参数-p。

结果如下：

一些相关的符号引用信息都记录在常量池中：

然后下面的就是域信息，但是只有public类型的，没有使用参数p所以private类型的没有出现，方法也是一样。

接下来看构造器，构造器和方法一样，在这里都是一样的表示方式，只是在Java语言编程过程中将两者概念上进行了分离。

同样还有静态代码块，和方法信息一样，操作数栈，局部变量表大小以及参数都有记录。

non-final 类型的类变量

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

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

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

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

全局常量 static final

• 全局常量就是使用 static final 进行修饰。
• 被声明为final的类变量的处理方法则不同，每个全局常量在编译的时候就会被分配了。

运行时常量池

解释

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池表（Constant Pool Table），用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

• 方法区，内部包含了运行时常量池。

• 字节码文件，内部包含了常量池。（之前的字节码文件中已经看到了很多Constant pool的东西，这个就是常量池）

• 要弄清楚方法区，需要理解清楚ClassFile，因为加载类的信息都在方法区。

• 要弄清楚方法区的运行时常量池，需要理解清楚ClassFile中的常量池。

• 运行时常量池（Runtime Constant Pool）是方法区的一部分。

• 常量池表（Constant Pool Table）是Class字节码文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。（运行时常量池就是常量池在程序运行时的称呼）

• 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。

• JVM为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的。

• 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址。

• 运行时常量池，相对于Class文件常量池的另一重要特征是：具备动态性。

• 运行时常量池类似于传统编程语言中的符号表（symbol table），但是它所包含的数据却比符号表要更加丰富一些。

• 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则JVM会抛OutofMemoryError异常。

常量池和运行时常量池

==常量池和上面看到的一样，是在编译时生成的一些信息Constant pool，可以将其看作一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。==而运行时常量池就是字面意思，在运行期间存在的常量池。运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是说，并非预置入Class文件中常量池的内容才能进入方法区运行时常 量池，运行期间也可以将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的 intern() 方法。同样运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。

方法区的垃圾回收

• 有些人认为方法区（如Hotspot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK11时期的ZGC收集器就不支持类卸载）。

• 一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。

• 方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

• 先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用。字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量：

  • 类和接口的全限定名
  • 字段的名称和描述符
  • 方法的名称和描述符

• HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。

• 回收废弃常量与回收Java堆中的对象非常类似。（关于常量的回收比较简单，重点是类的回收）

类卸载

判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例。
• 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class 以及 -XX：+TraceClass-Loading、-XX：+TraceClassUnLoading查看类加载和卸载信息

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

常见面试题

1. 百度
   • 三面：说一下JVM内存模型吧，有哪些区？分别干什么的？
2. 蚂蚁金服：
   • Java8的内存分代改进
   • JVM内存分哪几个区，每个区的作用是什么？
   • 一面：JVM内存分布/内存结构？栈和堆的区别？堆的结构？为什么两个survivor区？
   • 二面：Eden和survior的比例分配
3. 小米：
   • jvm内存分区，为什么要有新生代和老年代
4. 字节跳动：
   • 二面：Java的内存分区
   • 二面：讲讲vm运行时数据库区
   • 什么时候对象会进入老年代？
5. 京东：
   • JVM的内存结构，Eden和Survivor比例。
   • JVM内存为什么要分成新生代，老年代，持久代。新生代中为什么要分为Eden和survivor。
6. 天猫：
   • 一面：Jvm内存模型以及分区，需要详细到每个区放什么。
   • 一面：JVM的内存模型，Java8做了什么改
7. 拼多多：
   • JVM内存分哪几个区，每个区的作用是什么？
8. 美团：
   • java内存分配
   • jvm的永久代中会发生垃圾回收吗？
   • 一面：jvm内存分区，为什么要有新生代和老年代？