Explicación detallada del área de métodos de JVM

¡Acostúmbrate a escribir juntos! Este es el segundo día de mi participación en el "Nuggets Daily New Plan · April Update Challenge", haz clic para ver los detalles del evento .

Hola a todos, soy programador senior, me enfoco en compartir conocimientos sobre big data, algoritmos, java, python, etc. Bienvenidos a intercambiar y aprender conmigo. contáctame

Hemos actualizado el subsistema de carga de clases de JVM y la pila de máquinas virtuales en la serie de artículos de JVM Hoy, hablemos sobre el área de métodos de JVM.

Primero, echemos un vistazo a la interacción entre el área del método y el montón y la pila.

El usuario se almacena en el meta espacio, que también se puede decir que está en el área de método
El usuario variable se almacena en la tabla de variables locales de la pila de Java
new User() se almacena en el montón de Java

comprensión del área del método

Está claramente establecido en la "Especificación de la máquina virtual de Java" que "aunque todas las áreas de métodos son lógicamente parte del montón, algunas implementaciones simples pueden no optar por realizar la recolección de basura o la compresión". Pero para la máquina virtual HotSpot, el área de métodos también tiene un alias llamado Non-Heap (non-heap), que está destinado a estar separado del montón.

Por lo tanto, el área de métodos se puede considerar como un espacio de memoria independiente del montón de Java.

El área de método almacena principalmente la Clase, y el montón almacena principalmente el objeto instanciado.

El área de método, como el montón de JAVA, es un área compartida por cada subproceso.
El área de método se crea cuando se inicia la JVM y su espacio de memoria física real puede ser discontinuo como el montón de JAVA.
El tamaño del área del método, como el espacio de almacenamiento dinámico, puede ser fijo o ampliable.
El tamaño del área de métodos determina cuántas clases puede guardar el sistema.Si el sistema define demasiadas clases y el área de métodos se desborda, la máquina virtual también generará un error de desbordamiento de memoria.
1. Cargue una gran cantidad de paquetes jar de terceros
2. Demasiados proyectos desplegados por Tomcat
3. Un montón de clases de reflexión generadas dinámicamente
Cerrar la JVM liberará esta área de memoria

Evolución de las áreas de método en HotSpot

En JDK1.7 y versiones anteriores, se acostumbra llamar al área de método generación permanente. A partir de JDK 1.8, la generación permanente se reemplaza por el metaespacio. Después de JDK1.8, el metaespacio se almacena en la memoria fuera del montón.

《Java虚拟机规范》中，对如何实现方法区，没有做统一的要求。例如，IBM J9 中就不存在永久代的概念。从JDK1.8之后，HotSpot虚拟机完全废弃了永久代的概念，改用与 J9 一样在本地内存中实现的元空间来代替。

元空间的本质与永久代类似，都是对虚拟机规范中的方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存。

设置方法区大小与OOM

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

jdk7及之前：

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

jdk8以后：

元数据大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize指定。与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出，虚拟机一样会抛出异常 OutOfMemoryError: Metaspace。

-XX:MetaspceSize：设置初始的元空间大小。对于一个 64 位的服务器端的 JVM，其默认值是 21M。这是初始的高水位线，一旦触及这个水位线，FullGC 将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置。新的高水位线的值取决于 GC 后释放了多少元空间。如果释放的空间不足，那么在不超过 MaxMetaspaceSize 时，适当的提高该值。如果释放的空间过多，则适当的降低该值。

如果初始化的高水位线设置过低，上述高水位线调整情况就会发生很多次。通过垃圾回收器的日志可以观察到 FullGC 多次调用。为了避免频繁的 GC ，建议将 -XX:MetaspaceSize 设置为一个相对较高的值。

如何解决OOM

要解决 OOM 异常或 Heap Space 的异常，一般的手段是首先通过内存分析工具（Eclipse Memory Analyzer）对 dump 出来的堆转存快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄露（Memory Leak）还是内存溢出（Memory Overflow）。

内存泄露就是指有大量的引用指向了一些对象，但是这些对象以后不会再被使用了，由于此时它们还和 GC Roots 有关联，所以导致以后这些对象也不会被回收，这就是内存泄露的问题。

如果是内存泄漏，可进一步通过工具查看泄漏对象到 GC Roots 的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots 相关联并导致垃圾收集器无法自动回收他们。掌握了泄漏对象的类型信息，以及 GCRoots 引用链的信息，就可以比较准确的定位出泄漏代码的位置。
如果不存在内存泄漏，换句话说就是内存中的对象确实都还必须存活着，那就应当检查虚拟机的堆参数（-Xms 和 -Xmx），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

方法区的内部结构

方法区中主要存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

类型信息

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

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

域信息

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

域的相关信息包括：域名称、域类型、域修饰符（public，private，protected，static，final，volatile，transiend的某个子集）

方法（Method）信息

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

方法名称
方法的返回类型（或 void）
方法参数的数量和类型（按顺序）
方法的修饰符（public，private，protected，static，final，synchronized，native，abstrat 的一个子集）
方法的字节码（bytecodes）、操作数栈、局部变量表及大小（abstract 和 native 方法除外）
异常表（abstract 和 native 方法除外）

non-final 的类变量

静态变量和类关联在一起，随着类的加载而加载，它们成为类数据在逻辑上的一部分。

类变量被类的所有实例共享，即使没有类实例时，你也可以访问它。

// non-final 的类变量
public class MethodAreaTest {
    public static void main(String[] args) {
       Student student=new Student();
       student=null;
       student.hello();
       System.out.println(student.gender);

    }
}
class Student{
    public static String name="张三";
    public static final String gender="男";
    public static void hello(){
        System.out.println("hello");
    }
}
复制代码

如上述代码所示，即使我们把 student 设置为 null，也不会出现空指针异常。

全局常量

全局常量就是使用 static final 进行修饰，每个全局常量在编译时就会被分配了。

运行时常量池 VS 常量池

顾名思义，运行时常量池就是指运行时的常量池。

方法区，内部包含了运行时常量池
字节码文件，内部包含了常量池
要弄清楚方法区，需要理解清楚 ClassFile，因为加载类的信息都在方法区
要弄清楚方法区的运行时常量池，就需要理解清楚 ClassFile 中的常量池

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述符信息外，还包含一项信息就是常量池表，包括各种字面量和对类型、域、方法的符号引用。

为什么需要常量池

一个 java 源文件中的类、接口，编译后产生一个字节码文件。而 java 中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用。

常量池中主要包括：

数量值
字符串值
类引用
字段引用
方法引用

总的来说，常量池可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

运行时常量池

运行时常量池是方法区的一部分。常量池表是 Class 文件的一部分，用于存放编译期生成的各种字面量和符合引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

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

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

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

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

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

HotSpot 虚拟机方法区的演进

jdk1.6及以前：有永久代，静态变量存储在永久代上。
jdk1.7 : 有永久代，但已经逐步在去“永久代”，字符串常量池、静态变量保存在堆中。
jdk1.8 : 无永久代，类型信息、字段、方法、常量保存在本地内存的元空间中，但字符串常量池、静态变量保存在堆中。

字符串常量池（StringTable）为什么要调整位置

jdk 1.7 中，将字符串常量池放到了堆空间中。因为永久代的回收效率很低，在 full gc 的时候才会触发。而 full gc 是老年代空间不足、永久代空间不足时才会触发，导致 StringTable 回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。而放到堆中，就能更及时的进行回收。

静态变量存放在哪里

静态引用对应的对象实体始终都存在堆空间中。

方法区的垃圾回收

有些人认为方法区是没有垃圾收集行为的，其实不然。《java 虚拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在。

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

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

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

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

HotSpot 虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。回收废弃常量和回收Java堆中的对象非常类似。（关于常量的回收比较简单，重点是类的回收）。

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

该类所有的实例都已经被回收，也就是 java 堆中不存在该类及其任意派生子类的实例。
El cargador de clases que cargó la clase ha sido reciclado Esta condición es difícil de lograr a menos que sea un escenario de cargador de clases alternativo bien diseñado, como OSGI, recarga de JSP, etc.
No se hace referencia al objeto java.lang.Class correspondiente a esta clase en ninguna parte, y no se puede acceder a los métodos de esta clase a través de la reflexión en ninguna parte.

La máquina virtual Java puede reciclar clases inútiles que cumplan con las tres condiciones anteriores. Lo que queremos decir aquí es solo "permitido", no lo mismo que objetos. Si no hay una referencia, inevitablemente se reciclará. Con respecto a si reciclar el tipo, la máquina virtual HotSpot proporciona el parámetro -Xnoclassgc para controlar.También puede usar -verbose:class y -XX:+TraceClassLoading, -XX:+TraceClassUnLoading para ver la información de carga y descarga de clases.

En escenarios en los que se utiliza una gran cantidad de marcos de bytecode, como reflexión, proxy dinámico y CGLib, y con frecuencia se generan dinámicamente cargadores de clases personalizados, como JSP y OSGI, la máquina virtual de Java generalmente necesita la capacidad de descargar tipos para garantizar que el El área del método no se verá afectada, causará una presión de memoria excesiva.

Al final

Hasta ahora, hemos terminado de hablar sobre el área de métodos de JVM, si crees que es bueno, vuelve a publicar, mira y dale me gusta.

Cuanto más sabes, más abierto de mente eres. Nos vemos la próxima vez.