【JVM第五篇--运行时数据区】方法区
写在前面的话：本文是在观看尚硅谷JVM教程后，整理的学习笔记。其观看地址如下：尚硅谷2020最新版宋红康JVM教程
一、栈、堆、方法区的关系
虚拟机运行时的数据区如下所示：
即方法区是属于线程共享的内存区域。
我们可以通过如下代码来简单分析方法区和栈、堆之间的关系。
有代码：
Person person = new Person();
其对应关系图如下：
即源程序代码运行后，字节码文件中的Person类的元数据被虚拟机加载后放在了方法区。类加载的最终产物，一个对象实例new Person()，则是被放在了堆中。而person则是new Person()这个对象实例的引用，其位于虚拟机栈中的局部变量表（或称为本地变量表）里。
类的元数据：Person类所在的Class字节码文件中的类的方法代码、变量名、方法名、访问权限、返回值等等，元数据并不是类的Class对象，Class对象根据元数据生成。
由此可知，变量person位于虚拟机栈中的某个栈帧的局部变量表里，其类型为引用类型。该引用指向Java堆中的对象实例new Person()。而new Person()则包含一个指向类的元数据的指针，类的元数据就存放在方法区中。
二、对方法区的理解
1、方法区
方法区与Java堆一样，是线程共享的内存区域，它在JVM启动时创建。其实际的物理内存空间和Java堆区一样都是可以不连续的。
方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展。方法区的大小就决定了系统可以保存多少个类（因为方法区保存着类的元数据），如果定义的类太多，导致方法区溢出，虚拟机同样会抛出java.lang.OutOfMemoryError:PermGen space 或者 java.lang.OutOfMemoryError:Metaspace
当加载大量第三方jar包、Tomcat里部署的工程过多、大量动态的生成反射类都可能造成OOM
2、方法区的演变
在JDK7之前，习惯把方法区称为永久代，而在JDK8之后，又取消了永久代，改用元空间代替。但是，永久代、元空间和方法区不是等价的。永久代和元空间都是HotSpot虚拟机实现方法区的一种具体的方式而已。
元空间的本质与方法区类似，都是对JVM规范中方法区这一内存区域的一种实现。不过元空间与永久代的最大区别就是：元空间不在虚拟机设置的内存中，而是直接使用的本地内存。所以元空间的大小并不受虚拟机本身的内存限制，而是受制于计算机的直接内存。
当方法区无法满足新的内存分配的需求时，不论何种实现方式，都会抛出OOM异常。
三、方法区的内部结构
1、方法区中存储着什么？
方法区用于存储已被虚拟机加载的类型信息、方法信息、域信息、常量、静态变量、即时编译器编译后的代码缓存等等。
注意：静态变量在JDK7时就从方法区中移出，放到了堆中。
2、关于类型信息
对每个加载的类型（如类class，接口interface，枚举emun，注解annotation）来说，JVM必须在方法区存储以下信息：
①这个类型的完整有效的名称（全名=包名.类名）
②这个类型的直接父类的完整有效名（对于interfance或者java.lang.Object来说，都没有父类）
③这个类型的修饰符（如public、abstract、final等）
④这个类型直接接口的有序列表
3、关于域信息
JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。即该类型的作用范围的信息。
域的相关信息包括：域名称、域类型、域修饰符（public、protected、private、static、final、valatile、translation等）
4、关于方法信息
JVM必须保存所有方法的以下信息，以及它们的声明顺序：
①方法名称
②方法的返回类型
③方法参数的数量和类型（按顺序）
④方法的修饰符（public、static、final、synchronize、native、abstract等）
⑤方法的字节码、操作数栈、局部变量表等的大小（abstract和native方法除外）
⑥异常表（abstract和native方法除外）
- 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
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.num);
}
}
Class Order {
public static int count = 1;
public static final num = 2;
public static void hello(){
System.out.println("hello");
}
}
该代码可以正常打印出结果，由此可见，类变量被类的所有实例共享，即使没有对象实例也能够访问它。
类变量又有non-final类变量和全局常量两种。non-final类变量是未被final修饰的类变量，而全局常量就是有final修饰的类变量。如，上述代码中的count变量即为non-final类变量，而num变量则可称为全局常量。
一般的类变量和全局常量的区别就是：一般的类变量是在类加载的初始化阶段才赋予设置的字面量值（将count设置为count = 1），而全局常量是在编译时期就会被赋值为设置的字面量值（将num 设置为num = 2）。
需要注意的是，在JDK7及之后，字符串常量池以及静态变量就被从方法区中移出，放在了堆区。
6、关于常量池（class文件常量池和运行时常量池）
（1）、class文件常量池和运行时常量池
在方法区中，其内部包含有运行时常量池。
在一个字节码文件中，其内部则有class文件常量池。
方法区是虚拟机运行时产生的一块有特定作用的内存区域，而运行时常量池则存在于方法区中。字节码文件则是编译以后产生，class文件常量池是在编译后每个字节码文件都有的。
一个有效的字节码文件除了包含各个类的版本信息、字段、方法以及接口等描述信息外，还包含了一项信息就是常量池表（Constant Pool Table）,里面包含有各种字面量和对类型、域和方法的符号引用。
字面量和符号引用：
举个简单例子，String str = new String("你好");
上面的"你好"就是字面量，而str则为符号引用。
str符号引用需要在类加载的解析阶段转换为直接引用，因为str的值是可以变化的，我们不能在第一时间确定其真正的值，需要在动态运行中进行解析。
符号引用包含以下三类：
①类和接口的全限定名称
②字段的名称和描述符
③方法的名称和描述符
当一个字节码文件被加载到虚拟机后，字节码文件中的一些数据，如之前提到过的类型信息，域信息，方法信息等，就会被放置到方法区中。而字节码文件中的常量池则会进入方法区中的运行时常量池，其中的信息则会被方法区中的运行时常量池使用。
所以，要理解方法区，就需要了解字节码文件，因为加载类的信息就存放在方法区。而要理解方法区中的运行时常量池，就需要了解字节码文件中的常量池。
（2）、为什么要有class文件常量池
一个Java源文件中的类、接口等，在编译后都会产生一个字节码文件。而字节码文件需要数据支持，通常这种数据会很大，以至于不能直接存放到字节码中，换一种方式，可以将指向这些数据的符号引用存到字节码文件的常量池中，这样字节码只需使用常量池就可以在运行时通过动态链接找到相应的数据并使用。
比如，有代码如下：
public class SimpleClass{
public void sayHello(){
System.out.println("hello");
}
}
这个类在编译后生成的字节码文件大小为194字节，但里面却使用到了String类、System类、PrintStream类以及Object类等。显然，如果把这些类都放到编译后生成的字节码文件中，那么字节码文件的大小绝不仅仅只是194字节。
故在这个字节码文件中，对String类、System类等的引用都是符号引用，即用了一组符号来定位到这些使用到的类。这些符号引用就保存在字节码文件的常量池中，形成了一个常量池表。当字节码文件被加载时，在类加载过程中的解析阶段，这些符号引用才会被替换成直接引用。
（3）、运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分。当类加载到内存中后，JVM就会将class常量池中的内容存放到运行时常量池中,JVM为每个已加载的类或者接口都维护一个常量池，即运行时常量池是每个类都有一个。常量池中数据像数组一样，是通过索引访问的。
运行时常量池，相对于class常量池的另一个重要的特征就是具有动态性。Java并不要求常量必须在编译时才能产生，即并不是class文件常量池中的内容才能进入运行时常量池，在运行期间也同样可以将新的常量放入池中。比如，可以使用String.intern()动态生成字符串常量，String.intern()方法的作用就是当池中没有相应的字符串常量时，在运行时动态生成。
当创建类或接口的运行时常量池时，如果构造运行时常量所需的内存空间超过了方法区提供的最大值，JVM会抛出OOM异常。
三、方法区的演进
首先要知道，只有HotSpot虚拟机才有永久代。常见的虚拟机，如JRoctik、BEA等没有永久代的概念。原则上如何实现方法区属于虚拟机的实现细节，不受《Java虚拟机规范》的约束。
在HotSpot虚拟机中，方法区的变化情况如下:
| JDK6及以前 | 有永久代，字符串常量池、静态变量都存放在永久代上 |
| JDK7 | 有永久代，但字符串常量池、静态变量被从永久代中移出，放到了堆中 |
| JDK8及以后 | 无永久代，改用元空间代替，但字符串常量池，静态变量依然放在堆中 |
如图
字符串常量池为什么要调整？
因为永久代的垃圾回收效率很低，在full gc时才会被回收 ，而full gc是在老年代空间不足时才会触发的。这就导致了字符串常量池的回收效率不高，而我们在开发中会有大量的字符串生成，若回收效率低，将导致永久代的内存不足。而放到堆中，更能及时回收内存。
四、方法区的垃圾回收
方法区的垃圾回收条件比较苛刻，但这部分区域的内存回收又确实是必要的。
方法区的垃圾回收主要分为两部分内容：常量池中废弃的常量和不再使用的类型。
Hotspot虚拟机堆常量池的回收策略是非常明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。
判断一个常量是否已被废弃是相对简单的，但是要判断一个类型是否不再被使用的条件就比较苛刻了。需要同时满足一下三个条件：
①该类的所有实例都已经被回收，也就是堆中不再有该类及其子类的实例。
②加载该类的类加载器已经被回收。
③该类对应的java.lang.class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
在JVM所创建的3个默认的类加载器 Bootstrap ClassLoader，Extension ClassLoader，Application ClassLoader 都不可能满足这些条件。因此，任何系统类（如String类）或者通过应用程序类加载器加载的类都不能在运行时被释放。
Java虚拟机允许在同时满足上述三个条件的无用类进行回收，但允许回收并不代表必然会被回收。
在大量使用反射、动态代理、动态生成JSP以及OSGI这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成太大的压力。
