JVM元空间(方法区)_元空间方法区-优快云博客

本文链接：https://blog.youkuaiyun.com/braverlionet/article/details/112440250

一. 背景

编写本次 JVM 章程, 因没有找到合适及透明的文章讲解JVM,零一下定决心既然没人做从零到一的过程, 那我来做,编学边分享本次学习的过程, 先和同学们说一下本次JVM章程几乎全是概念,其实大家背下来理解即可,希望会对各位学习的童鞋们带来帮助

注意 : 本次 HotSpot VM 讲解基于 JDK8 讲解,期间会进行与JDK6版本进行对比

`公众号 : 倔强小狮子(最新发布)`

在这里插入图片描述

方法区

1. 线程共享与非共享角度查看运行时数据区结构图

在这里插入图片描述

2.一个对象在JVM中存储分配

在这里插入图片描述

3.方法区的理解

尽管所有的方法区逻辑上是属于堆空间的一部分,但是一些简单的实现可能不会选择区垃圾收集或者进行压缩的,但是对于HotSpotJVM而言,方法区还有一个别名 Non-Heap(非堆),目的就是和堆分开
所以方法区看作是一块独立与Java堆内存的空间
方法区(Method Area) 与Java堆一样,是各个线程共享的内存空间区域
方法区在JVM启动的时候就创建的,并且它的实际物理内存空间中和Java堆区一样都是不连续的
方法区的大小和堆空间一样都是可以进行固定大小或者可扩展的
方法区的大小决定了系统可以保存多少个类,如果系统定了太多的类,导致方法区溢出,虚拟机同样也会出现OOM错误) java.lang.OutOfMemoryError:PermGen space 或者 java.lang.OutOfMemorError:Metaspce
出现以上错误原因 : 加载大量的第三方jar包,Tomcat部署的工程过多,大量动态的生成反射类
方法去的生命周期随着JVM启动而创建,关闭而释放内存区域

4.HotSpotVM方法区的演进

在之前讲过堆空间中提到,jdk7到jdk8的的升级版本中,元空间是方法区的一种具体落地实现,元空间顶替了方法区
本质上方法区和永久代并不等价,仅是对HotspotVM而言的,在 Java虚拟机规范对如果实现方法区,不做统一要求,例如 : BEA JRockit / IBM J9 中不存在永久代的概念
现在看来,当前使用的永久代,不是个好的idea,导致了Java程序更容易出现OOM(超过 -XX:MaxPermSize 上限,致命伤害)

4.1 JDK8完全废除方法区(永久代)

上述说到方法区并不是一个好的 idea,到了JDK8终于废除了永久代的概念,改成与 JRockit, J9一样的本地内存中实现元空间(Metasoce)来替代,注意是本地内存
元空间的本质和永久代类似,都是对JVM规范中方法去的实现,不过元空间与永久代最大的区别在于 : 元空间不在使用虚拟机内部内存,而是直接使用本地内存
永久代,元空间并不是名字变了,及其内部结构也进行了调整
不要高兴太早,JVM虚拟机规范中提到虽然使用本地内存当方法区的内存分配条件,可是大幅度的降低了OOM错误出现(几乎不可能出现,除非服务器内存占满)

5.JDK7-8方法区内存大小调整

上诉讲到方法区的大小必是固定大小的,JVM可以根据应用的需要动态调整

5.1 JDK7及以前

通过 -XX:PremSize来设置方法区(永久代)初始分配内存,默认是20.75M
-XX:MaxPermsSize 来设置用方法去的最大内存,32位机器默认64M,64位机器默认82M
当JVM加载类信息容量超过 -XX:MaxPermSize这个值,是会出现 OOM的

5.2 JDK8及以后(重点)

元空间区域大小可以使用 -XX:MetaSpaceSize 和 -XX:MaxMetaspaceSize指定的
默认值依赖平台的, 测试发现, windows下, -XX:MetaspaceSize 是21M, -XXMaxMetaspaceSize的值默认是 -1(即使没有限制)
与方法区不同,如果不指定大小,默认情况下,虚拟机会耗尽可用的系统内存,如果元空间发生溢出,虚拟机一样会出现 OutOfMemoryError:MetaSpace 错误
-XX:MetaspaceSize : 设置初始的元空间大小,对于一个64位的服务器端JVM来说,其默认值是-XX:MetaspaceSize 值21M,这就是一个高水位线,一旦触发这个高水位线,Full GC就会被触发并且卸载没有用的类(及这些对应的类加载器也不在存活),然后这个高水位线将会被重置,新的高水位线取决于GC释放后了多少元空间(调优重点注意),如果释放的空间不足,那么在不超过-XXMaxMetaspaceSize设置的值情况下会适当提高该值,如果释放的空间过多将会降低该值
如果初始的高位线过低,上述的高位线情况会出现很多次,通过垃圾回收收集日志可以观察到Full GC多次调用,为了避免频繁的GC,建议将 -XX:XX:MetaspaceSize 设置要给相对较高的值( 元空间不足是会触发 Full GC,调优中重点注意 )
下面是 Java虚拟机规范中提高的方法区内存泄漏实例
代码举例 : 自己测试下吧


import jdk.internal.org.objectweb.asm.ClassWriter;
import jdk.internal.org.objectweb.asm.Opcodes;

/**
 * @Authror Lionet
 * @Date 2021/1/10 21:42
 * @Description
 * JDK8 : 中
 * -XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10M
 * jdk6中 :
 * -XX : PermSize=10M -XXMaxPermSize=10
 */

public class PcDemo extends ClassLoader {
    public static void main(String[] args) {

        int j = 0;
        try {
            PcDemo pcDemo = new PcDemo();
            for (int i = 0; i < 100000; i++) {
                // 创建 ClassWriter 对象,用于生成类二进制字节码
                ClassWriter classWriter = new ClassWriter(0);
                // 指定版本号,public, 类名,包名, 父类,接口
                classWriter.visit(Opcodes.V1_6, Opcodes.ACC_PUBLIC,
                        "Class" + i, null, "java/lang/Object", null);
                // 返回 byte[]
                byte[] code = classWriter.toByteArray();
                // Class 对象
                pcDemo.defineClass("Class" + i, code, 0, code.length);
                j++;
            }
        } catch (ClassFormatError classFormatError) {
            classFormatError.printStackTrace();
            System.out.println(j);

        }

    }
}

5.3 如果解决这些OOM(重点重点)

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

6.元空间的内部结构

在这里插入图片描述

深入理解Java虚拟机书中对元空间存储描述 : 用于储存已被虚拟机加载的 类型信息,常量, 静态变量(类变量), 即时编译器编译后的代码缓存 等

6.1 类型信息

对每一个加载的类型(l类Class,接口Interface, 枚举enum,注解annotation),JVM在方法区储存以下类型信息 :
① 这个类型的完整有效的全限定类名(包名.类名)
② 直接父类的完整有效的全限定类名(对于interface或者java.lang.Object,都没有父类)
③ 这个类型的修饰符( public, abstract, final的某子集)
④ 直接接口的一个有序列表

6.3 域(Field,字段)信息

JVM必须在元空间中保存类型的所有域相关信息及域的声明顺序
域的相关信息包括 : 域名称,域类型,域修饰符( public, private, protected, static, final, volatile, transient的某子集)

6.4方法信息

方法名称,方法返回类型(或 void)
方法参数的数量,和类型(按照顺序,后期会深入代码体现)
方法的修饰符 ( public, private, protected, static, final, synchronization, native, abstract 的一个子集)
方法的字节码( bytecodes), 操作数栈,局部变量表(abstract 和 native 方法除外)
异常表 (abstract 和 native 方法除外), 每个异常处理的开始位置,结束位置,代码处理在程序计数器中的偏移量地址,被捕获的异常类的常量池索引

6.5 non-final 的类常量

静态变量和类关联一起,随着类的加载而加载,他们称为类数据逻辑的一部分
类变量被类的所有实例共享,即使没有类实例时也可以方法它

public class PcDemo extends ClassLoader {
    public static void main(String[] args) {

        Test test =null;
        Test.testFun();
        System.out.println("Test.num = " + Test.num);
    }
}
class Test{
    public static int num = 1;
    public static void testFun(){
        System.out.println("testFun");
    }
}

补充说明 : 全局常量 : static final 的类变量的处理方法则不同,每个全部常量在进行编译时候就进行分配了

7 运行时常量池与常量池

在这里插入图片描述

方法区,内部包含了运行时常量池。字节码文件,内部包含了常量池。
要弄清楚方法区,需要理解清楚ClassFile,因为加载类的信息都在方法区
要弄清楚方法区的运行时常量池,需要理解清楚ClassFile中的常量池。
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html
一个有效的字节码文件中除了包含类的版本信息,字段,方法及接口等描述信息外,还保存了一项信息那就是常量池变量表( Constant Pool Table ),包含各种字面量和对类型,域,方法的符号引用

7.1 为什么需要常量池

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

public class PcDemo{
    public   void  test() {
        System.out.println("测试");
    }
}

虽然只有206字节,但是里面却使用了 String,System,PrintStram及Object等结构,这里代码量其实很小了,如果代码量多,引用到的结构会更多,这里就需要常量池了

7.3. 常量池中有什么呢

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

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

在这里插入图片描述
2. 小结 : 常量池可以看做是一张表,虚拟机指令根据这张常量表找到要执行的类名,方法名,参数类型,字面量等类型

8. 运行时常量池

运行时常量池(Runtime Constant Pool)是方法区的一部分。
常量池表(constant Pool Table)是Class文件的一部分,用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。
运行时常量池在加载类和接口到虚拟机后,就会创建对应的运行时常量池。
JVM为每个已加载的类型(类或接口)都维护一个常量池。池中的数据项像数组项一样,是通过索引访问的。
运行时常量池中包含多种不同的常量,包括编译期就已经明确的数值字面量,也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了,这里换为真实地址,运行时常量池,相对于Class文件常量池的另一重要特征是:具备动态性。
例如 : string.intern() 运行时常量池类似于传统编程语言中的符号表(symbol table) ,但是它所包含的数据却比符号表要更加丰富一些。
当创建类或接口的运行时常量池时,如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值,则JVM会抛outofMemoryError错误
总之 : 在编译器JVM会为每一个Class文件创建一个常量池表,包含字面量和符号引用(代表真实地址的符号), 是通过索引来访问的,在Class文件通过类加载到JVM中,在元空间中创建对应的运行时常量池(保存在编译器已经明确的字面量及对象,字段,方法访问的真实地址(符号引用动态链接绑定)), 在运行期,通过动态链接(符号引用与真实地址进行绑定,栈中有讲解),这时候符号引用就会通过动态链接与运行时常量池中的真实地址了绑定了

9. 永久代(方法区)的演变

9.1 演变说明


JDK6	有永久代,静态变量存放在永久代
JDK7	有永久代,但已经初步出现"去永久代",字符串常量,静态变量移除保存在堆中
JDK8	无永久代,类信息,字段,方法,常量保存在本地内存元空间中,但字符串常量,静态变量仍在堆中

演变说明地址 : http://openjdk.java.net/jeps/122
很牛皮的解释为什么剔除永久代,因为JRockit 没有所以HotSpot 也没有,有兴趣的同学可以观看上面演变说明地址观看

This is part of the JRockit and Hotspot convergence effort. JRockit
customers do not need to configure the permanent generation (since
JRockit does not have a permanent generation) and are accustomed to
not configuring the permanent generation.

9.2 永久代为什么要被元空间替换

随着Java8的到来, HotSpot vM中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域,这个区域叫做元空间(Metaspace)
由于类的元数据分配在本地内存中,元空间的最大可分配空间就是系统可用内存空间。这项改动是很有必要的,原因有: 为永久代设置空间大小是很难确定的。在某些场景下,如果动态加载类过多,容易产生Perm区的00M。比如某个实际Web工程中,因为功能点比较多,在运行过程中,要不断动态加载很多类,经常出现致命错误。而元空间和永久代最大的区别在于 : 元空间不在虚拟机中,而是使用本地内存,因此默认情况下元空间的大小受本地内存的限制
对永久代进行调优是很困难的

10. 方法去的垃圾收集

有些人认为方法区如Hotspot虚拟机中的元空间或者永久代)是没有垃圾收集行为的,其实不然。《Java虚拟机规范》对方法区的约束是非常宽松的,提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在(如JDK 11时期的ZGC收集器就不支持类卸载)
一般来说这个区域的回收效果比较难令人满意,尤其是类型的卸载,条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中,曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。
方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型
先来说说方法区内常量池之中主要存放的两大类常量:字面量和符号引用。字面量比较接近Java语言层次的常量概念,如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念,包括下面三类常量: ① : 类和接口的全限定名 ② :字段的名称和描述符 ③: 方法的名称和描述符
Hotspot虚拟机对常量池的回收策略是很明确的,只要常量池中的常量没有被任何地方引用,就可以被回收。
回收废弃常量与回收Java堆中的对象非常类似。
判定一个常量是否“废弃”还是相对简单,而要判定一个类型是否属于“不再被使的类”的条件就比较苛刻了。需要同时满足下面三个条件: ① : 该类所有的实例都已经被回收,也就是Java堆中不存在该类及其任何派生子类实例。② : 加载该类的类加载器已经被回收,这个条件除非是经过精心设计的可替换类加器的场景,如OSGi、 JSP的重加载等,否则通常是很难达成的。③ : 该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方通反射访问该类的方法。
Java虚拟机被允许对满足上述三个条件的无用类进行回收,这里说的仅仅是“被允许”,而并不是和对象一样,没有引用了就必然会回收。关于是否要对类型进行回HotSpot虚拟机提供了-Xnoclassgc参数进行控制,还可以使用-verbose:class 以及 -XX:+Traceclass-Loading, -XS:+TraceclassUnLoading查看类加载和卸载信息
在大量使用反射、动态代理、CGLib等字节码框架,动态生成JSP以及OSGi这类频自定义类加载器的场景中,通常都需要Java虚拟机具备类型卸载的能力,以保证不会对方法区造成过大的内在压力

作者：专业于写这些入门到深层知识，提升我们的基本功，期待你的关注，和我一起学习
转载说明：未获得授权，禁止转载

JVM元空间(方法区)

一. 背景

公众号 : 倔强小狮子(最新发布)

文章目录

方法区

1. 线程共享与非共享角度查看运行时数据区结构图

2.一个对象在JVM中存储分配

3.方法区的理解

4.HotSpotVM方法区的演进

4.1 JDK8完全废除方法区(永久代)

5.JDK7-8方法区内存大小调整

5.1 JDK7及以前

5.2 JDK8及以后(重点)

5.3 如果解决这些OOM(重点重点)

6.元空间的内部结构

6.1 类型信息

6.3 域(Field,字段)信息

6.4方法信息

6.5 non-final 的类常量

7 运行时常量池与常量池

7.1 为什么需要常量池

7.3. 常量池中有什么呢

8. 运行时常量池

9. 永久代(方法区)的演变

9.1 演变说明

9.2 永久代为什么要被元空间替换

10. 方法去的垃圾收集

`公众号 : 倔强小狮子(最新发布)`