JVM - 方法区

最新推荐文章于 2023-09-20 15:20:49 发布

Sadness°

最新推荐文章于 2023-09-20 15:20:49 发布

阅读量148

点赞数

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

本文链接：https://blog.csdn.net/y13672651519/article/details/112794392

版权

JVM 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

1 概述

《Java虚拟机规范》中说明：尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或进行压缩。但对于HotSpot JVM而言，方法区还有一个别名叫做Non-Heap非堆，目的就是要和堆分开。所以，方法区看做是一块独立于Java堆的内存空间
方法区与堆一样，是各个线程共享的内存区域
方法区在JVM启动的时候被创建，并且它的实际物理内存空间中和Java堆区一样都可以是不连续的
方法区的大小，与堆一样，可以选择固定大小或者可扩展
方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误，java.lang.OutOfMemoryError:PermGen space或者java.lang.OutOfMemoryError:Metaspace
关闭JVM就会释放这个方法区的内存

2 HotSpot中方法区的演进

在jdk7以前，习惯上把方法区称为永久代，jdk8开始，使用元空间取代了永久代
本质上，方法区和永久代并不等价，这仅是对Hotspot而言的。《Java虚拟机规范》对如何实现方法区，不做统一要求。例如，JRockit/IBM J9中不存在永久代的概念。现在来看，当年使用永久代，不是好的idea，导致Java程序更容易OOM(超过-XX:MaxPermSize上限)
到了jdk8，终于完全废弃了永久代的概念，改用与JRockit/IBM J9一样在本地内存中实现的元空间来代替
元空间的本质和永久代类似，都是对JVM规范中方法区的实现，不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存
永久代、元空间二者并不只是名字变了，内部结构也调整了
根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常

3 设置方法区大小

jdk7及以前：

-XX:PermSize=size：设置永久代初始分配空间，默认是20.75M
-XX:MaxPermSize=size：设置永久代最大可分配空间，32位机器默认是64M，64位机器是82M
可使用jps，jinfo -flag PermSize 进程号来查看永久代的大小

jdk8及以后：

-XX:MetaspaceSize=size：设置元空间初始分配空间，默认是21M左右
-XX:MaxMetaspaceSize=size：设置元空间最大可分配空间，默认是本机最大内存
与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存，如果元数据区发生溢出，虚拟机一样会抛出OOM:Metaspace异常
初始元空间大小-XX:MetaspaceSize默认值是21M，这就是初始的高水位线，一旦触及这个水位线，Full GC将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置。新的高水位线取决于GC后释放了多少元空间，如果释放的空间很少，那么在不超过MaxMetaspaceSize时，适当提高该值，如果释放的空间较多，则适当降低该值
如果初始化的高水位线设置过低，那么高水位线的调整就位发生很多次，所以GC也频繁了，所以要尽量将初始化值设高点

4 解决元空间的OOM

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

5 内部结构

它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等
这些信息可以通过class文件的反编译查看

类型信息：

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

域(Field)信息

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

方法信息

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

在这里插入图片描述

注意：全局常量static final修饰的变量在编译期间就会被分配，而static类变量在类加载的准备阶段，才会对其默认赋初值，在初始化阶段默认显式赋值。看如下例子：

public static int count = 1;
public static final int count1 = 2;

在这里插入图片描述

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

6 运行时常量池

在方法区中，内部包含了一个运行时常量池
字节码文件中，内部也包含了常量池，此常量池加载到方法区后就成为运行时常量池
一个Java源文件中的类、接口，编译后产生一个字节码文件，而Java中的字节码需要数据支持，通常这种数据会很大，以至于不能直接存储到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用，在动态链接的时候会用到运行时常量池
注意：运行时常量池一直在方法区中，并没有移动到堆内存；而字符串常量池原先在方法区的运行时常量池内，在java7之后移动到了堆内存中

public class SimpleClass {
    public void sayHello(){
        System.out.println("hello");
    }
}

在这里插入图片描述

虽然只有500字节，但是这里面却使用了String、System、PrintStream及Object等结构，这里代码量其实已经很小了，如果代码多，引用到的结构会更多，这里就需要使用常量池
常量池可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量（字面量就是真实的值）等类型
常量池表是class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中
运行时常量池在加载类和接口到虚拟机后，就会创建对应的运行时常量池，具有动态性
JVM为每个已加载的类型（类或接口）都维护一个常量池，池中的数据就像数组一样，是通过索引访问的
运行时常量池中包含多种不用的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析（对应类加载的阶段）后才能够获得的方法或者字段引用，此时不再是常量池中的符号引用了，这里换为真实地址或直接引用

对于以下程序，我们查看具体的执行流程

public class MethodAreaTest {
    public static void main(String[] args) {
        int x = 500;
        int y = 100;
        int a = x / y;
        int b = 50;
        System.out.println(a + b);
    }
}

在这里插入图片描述

7 方法区的演进

(1)首先明确，只有Hotspot才有永久代，对于JRockit、IBM J9来说，是不存在永久代的概念的，原则上如何实现方法区属于虚拟机的实现细节，不受《Java虚拟机规范》管束，并不要求统一
(2)Hotspot中方法区的变化

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

jdk1.6
在这里插入图片描述
jdk1.7

jdk1.8

随着Java8的到来，HotspotVM中再也见不到永久代了，但这并不意味着类的元数据信息也消失了，这些数据被转移到了一个与堆不想连的本地内存区域，这个区域叫做元空间
由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间

(3)为什么要使元空间替换掉永久代？

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

(4)StringTable(字符串常量池)为什么要调整到堆中？

jdk1.7将StringTable放到了堆空间中，因为永久代的回收频率很低，在Full GC的时候才会触发，而Full GC是老年代的空间不足、永久代不足时才会触发，这就导致StringTable回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。所以将其放进堆里，就能够及时回收内存

(5)方法区的垃圾收集

主要回收两部分内容：运行时常量池中废弃的常量和不再使用的类型
《Java虚拟机规范》没有明确说明方法区是否需要回收。
在Hotspot虚拟机中对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收
然而对一个类型能否被回收的判定条件是相当苛刻的，需要同时满足下面3个条件：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例；
- 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景；
- 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法
Java虚拟机被允许对满足上述3个条件的无用类型进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有了引用必然会被回收
在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力