解密JVM（四）类加载

最新推荐文章于 2024-08-30 18:40:43 发布

LeslieGuGu

最新推荐文章于 2024-08-30 18:40:43 发布

阅读量305

点赞数 1

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

本文链接：https://blog.csdn.net/weixin_44050144/article/details/113642831

版权

JVM 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

文章目录

1.1类加载阶段

1.1.1加载

将类的字节码载入方法区（1.8后为元空间，在本地内存中）中，内部采用 C++ 的 instanceKlass 描述 java 类，它的重要ﬁeld 有：

_java_mirror 即 java 的类镜像，例如对 String 来说，它的镜像类就是 String.class，作用是把 klass 暴露给 java 使用
_super 即父类
_ﬁelds 即成员变量
_methods 即方法
_constants 即常量池
_class_loader 即类加载器
_vtable 虚方法表
_itable 接口方法

如果这个类还有父类没有加载，先加载父类
加载和链接可能是交替运行的
instanceKlass保存在方法区。JDK 8以后，方法区位于元空间中，而元空间又位于本地内存中
_java_mirror则是保存在堆内存中
InstanceKlass和*.class(JAVA镜像类)互相保存了对方的地址
类的对象在对象头中保存了*.class的地址。让对象可以通过其找到方法区中的instanceKlass，从而获取类的各种信息

1.1.2链接

验证

验证类是否符合 JVM规范，安全性检查

准备

为 static 变量分配空间，设置默认值

static变量在JDK 7以前是存储与instanceKlass末尾。但在JDK 7以后就存储在_java_mirror末尾了
static变量在分配空间和赋值是在两个阶段完成的。分配空间在准备阶段完成，赋值在初始化阶段完成
如果 static 变量是 ﬁnal 的基本类型，以及字符串常量，那么编译阶段值就确定了，赋值在准备阶段完成
如果 static 变量是 ﬁnal 的，但属于引用类型，那么赋值也会在初始化阶段完成

解析

解析的含义

将常量池中的符号引用解析为直接引用

未解析时，常量池中的看到的对象仅是符号，未真正的存在于内存中
解析以后，会将常量池中的符号引用解析为直接引用

1.1.3初始化

初始化阶段就是执行类构造器clinit()方法的过程，虚拟机会保证这个类的构造方法的线程安全

clinit()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的

注意：编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问，如
在这里插入图片描述
发生时机

类的初始化的懒惰的，以下情况会初始化

main 方法所在的类，总会被首先初始化
首次访问这个类的静态变量或静态方法时
子类初始化，如果父类还没初始化，会引发
子类访问父类的静态变量，只会触发父类的初始化
Class.forName
new 会导致初始化

以下情况不会初始化

访问类的 static ﬁnal 静态常量（基本类型和字符串）
类对象.class 不会触发初始化
创建该类对象的数组
类加载器的.loadClass方法
Class.forNamed的参数2为false时

验证类是否被初始化，可以看改类的静态代码块是否被执行

1.2类加载器

Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”（ClassLoader）

类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等

以JDK 8为例

名称	加载的类	说明
Bootstrap ClassLoader（启动类加载器）	JAVA_HOME/jre/lib	无法直接访问
Extension ClassLoader(拓展类加载器)	JAVA_HOME/jre/lib/ext	上级为Bootstrap，显示为null
Application ClassLoader(应用程序类加载器)	classpath	上级为Extension
自定义类加载器	自定义	上级为Application

启动类加载器

可通过在控制台输入指令，使得类被启动类加器加载

拓展类加载器

如果classpath和JAVA_HOME/jre/lib/ext 下有同名类，加载时会使用拓展类加载器加载。当应用程序类加载器发现拓展类加载器已将该同名类加载过了，则不会再次加载

双亲委派模式

双亲委派模式，即调用类加载器ClassLoader 的 loadClass 方法时，查找类的规则

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // 首先查找该类是否已经被该类加载器加载过了
        Class<?> c = findLoadedClass(name);
        //如果没有被加载过
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                //看是否被它的上级加载器加载过了 Extension的上级是Bootstarp，但它显示为null
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    //看是否被启动类加载器加载过
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
                //捕获异常，但不做任何处理
            }

            if (c == null) {
                //如果还是没有找到，先让拓展类加载器调用findClass方法去找到该类，如果还是没找到，就抛出异常
                //然后让应用类加载器去找classpath下找该类
                long t1 = System.nanoTime();
                c = findClass(name);

                // 记录时间
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

自定义类加载器

使用场景

想加载非 classpath 随意路径中的类文件
通过接口来使用实现，希望解耦时，常用在框架设计
这些类希望予以隔离，不同应用的同名类都可以加载，不冲突，常见于 tomcat 容器

步骤

继承ClassLoader父类
要遵从双亲委派机制，重写 ﬁndClass 方法
- 不是重写loadClass方法，否则不会走双亲委派机制
读取类文件的字节码
调用父类的 deﬁneClass 方法来加载类
使用者调用该类加载器的 loadClass 方法

破坏双亲委派模式

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK1.2面世以前的“远古”时代
- 建议用户重写findClass()方法，在类加载器中的loadClass()方法中也会调用该方法
双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的
- 如果有基础类型又要调用回用户的代码，此时也会破坏双亲委派模式
双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的
- 这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等

1.3运行期优化

分层编译
JVM 将执行状态分成了 5 个层次：

0层：解释执行，用解释器将字节码翻译为机器码
1层：使用 C1 即时编译器编译执行（不带 proﬁling）
2层：使用 C1 即时编译器编译执行（带基本的profiling）
3层：使用 C1 即时编译器编译执行（带完全的profiling）
4层：使用 C2 即时编译器编译执行

proﬁling 是指在运行过程中收集一些程序执行状态的数据，例如【方法的调用次数】，【循环的回边次数】等

即时编译器（JIT）与解释器的区别

解释器

将字节码解释为机器码，下次即使遇到相同的字节码，仍会执行重复的解释
是将字节码解释为针对所有平台都通用的机器码

即时编译器

将一些字节码编译为机器码，并存入 Code Cache，下次遇到相同的代码，直接执行，无需再编译
根据平台类型，生成平台特定的机器码

对于大部分的不常用的代码，我们无需耗费时间将其编译成机器码，而是采取解释执行的方式运行；另一方面，对于仅占据小部分的热点代码，我们则可以将其编译成机器码，以达到理想的运行速度。执行效率上简单比较一下 Interpreter < C1 < C2，总的目标是发现热点代码（hotspot名称的由来），并优化这些热点代码

逃逸分析
逃逸分析（Escape Analysis）简单来讲就是，Java Hotspot 虚拟机可以分析新创建对象的使用范围，并决定是否在 Java 堆上分配内存的一项技术

逃逸分析的 JVM 参数如下：

开启逃逸分析：-XX:+DoEscapeAnalysis
关闭逃逸分析：-XX:-DoEscapeAnalysis
显示分析结果：-XX:+PrintEscapeAnalysis

逃逸分析技
术在 Java SE 6u23+ 开始支持，并默认设置为启用状态，可以不用额外加这个参数
对象逃逸状态

全局逃逸（GlobalEscape）

即一个对象的作用范围逃出了当前方法或者当前线程，有以下几种场景：

对象是一个静态变量
对象是一个已经发生逃逸的对象
对象作为当前方法的返回值

参数逃逸（ArgEscape）

即一个对象被作为方法参数传递或者被参数引用，但在调用过程中不会发生全局逃逸，这个状态是通过被调方法的字节码确定的

没有逃逸

即方法中的对象没有发生逃逸

LeslieGuGu

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
解密JVM（四）类加载

文章目录1.1类加载阶段1.1.1加载1.1.2链接1.1.3初始化1.2类加载器1.3运行期优化1.1类加载阶段1.1.1加载将类的字节码载入方法区（1.8后为元空间，在本地内存中）中，内部采用 C++ 的 instanceKlass 描述 java 类，它的重要ﬁeld 有：_java_mirror 即 java 的类镜像，例如对 String 来说，它的镜像类就是 String.class，作用是把 klass 暴露给 java 使用_super 即父类_ﬁelds 即成员变量_m
复制链接

扫一扫