首页 > 其他分享> > JVM类加载机制

JVM类加载机制

2021-12-31 09:32:34 作者：互联网

类加载的生命周期

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析、初始化，最终形成可被虚拟机直接使用的Java类型，这个过程便被成为Java虚拟机的加载机制。当一个类型从被加载到虚拟机内存开始，到卸载出内存为止，这样的整个生命周期经历加载、验证、准备、解析、初始化、使用、卸载七个阶段。而验证、准备、解析这三个阶段一般统称为“连接”，这些阶段的顺序图如下：

类加载声明周期的具体步骤如下：

加载
1. 通过一个类的全限定类名，来获取定义此类的二进制字节流。
2. 将这些字节流所代表的的静态存储结构，转化为方法区的运行时数据结构。
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问接口。
连接
1. 验证
  1. 文件格式验证：验证字节流是否符合class文件格式的规范
  2. 元数据验证
    1. 这个类是否有父类（Object除外）
    2. 这个类是否不允许被继承（被final修饰的类）
    3. 如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法
    4. 类的字段/方法是否与父类产生冲突
  3. 字节码验证
    1. 保证任意时刻操作数栈上的数据类型与指令代码序列都能配合工作
    2. 保证任何跳转指令都不会跳转到方法体以外的字节码指令上
    3. 保证方法体中的类型转换总是有效的
  4. 符号引用验证
    1. 符号引用中通过字符串描述的全限定名是否能找到对应的类。
    2. 在指定类中是否存在符合方法的字段描述及简单的名称所描述的方法和字段。
    3. 符号引用中的类、字段、方法的可访问性是否可以被当前类访问。
2. 准备
  1. 为类的静态变量分配内存，并初始化它们。
3. 解析：
  1. 把常量池中的符号引用转换为直接引用，该阶段会把一些静态方法（符号引用，比如main方法）替换为指向数据内存的指针或句柄（直接引用），这是所谓的静态链接过程（类加载期间完成），动态链接是指在运行期间完成的符号引用替换为直接引用。
初始化：为类的初始化变量赋值。
使用
卸载

在上面的七个阶段中，加载、验证、准备、初始化、卸载这五个阶段的顺序是确定的，类型的加载过程是必须按照这种顺序按部就班的开始，而解析阶段却不一定，它在某种特定的情况下，可以在初始化之后开始，这样设计的目的是为了支持Java语言的运行时动态绑定特性（动态绑定或晚期绑定）。

当类被加载到方法区之后，这其中主要包括：运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息。

类加载器的引用：这个类到类加载器的实例引用
对应class实例的引用：类加载器在加载类信息放到方法区之后，会创建一个对应Class类型对象实例方法堆中，作为开发人员访问方法区定义的入口和切入点。

触发初始化条件

触发初始化的条件：

遇到new、getstatic、putstatic或invokestatic这四条字节指令时，如果类型没有进行初始化，则需先触发其初始化阶段，那么生成四条指令的场景分别是：
- 使用new关键字实例化对象的场景
- 读取或设置一个对象的静态字段（被final修饰、已在编译器把编译结果放入常量池的静态字段除外）的时候。
- 调用一个类型的静态方法
使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有初始化，则需要先触发其初始化。
当类初始化的时候，如果发现其父类还没有初始化，则需要先触发其父类的初始化。
当使用JDK7新加入的动态语言支持时，如果一个java.lang.MethodHandler实例最后的结果解析为REF_getStatic、REF_putStatic、REF_invokeStatic、newInvokeSpecialStatic四种类型的方法句柄，并且这个方法的句柄对应的类型没有进行初始化，则需要先触发其初始化。
当虚拟机启动的时候，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会先初始化这个类。
当一个接口定义了JDK8新加入的默认方法（被default方法修饰的接口方法）时，如果这个接口的实现类发生了初始化，则需要先触发其初始化。

注意：接口初始化时，不要求其父类全部接口都完成了初始化，只有真正的使用到父类接口调用的时候（引用接口定义的常量）才会初始化。

类加载器和双亲委派

类加载的过程主要是由类加载器来完成的，Java的类加载器有如下几种：

引导类加载器：负责加载支撑JVM中位于JRE的lib目录下的核心类库，比如rt.jar、charsets.jar等
扩展类加载器：负责加载支撑JVM中位于JRE的lib目录下的ext扩展目录中的jar类包（这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现）
应用程序类加载器：负责加载ClassPath路径下的所有类包
自定义类加载器：负责加载用户自定义路径下的类包

类加载器的初始化过程

当应用程序启动时，会创建JVM启动器sun.misc.Launcher实例，该类是由引导类加载器负责加载创建其他类加载器。在Launcher类的构造方法内部，创建了两个类加载器，分别是：sun.misc.Launcher.ExtClassLoader（扩展类加载器）和sun.misc.Launcher.AppClassLoader（应用类加载器）。在JVM中默认使用Launche类中的sun.misc.Launcher#getClassLoader方法返回类加载器AppClassLoader的实例来加载我们的应用程序。那就来看下Launcher的构造器代码，如下：

public Launcher() {
    Launcher.ExtClassLoader var1;
    try {
        // 构造扩展类加载器，在构造过程中将其父类加载器设置为null
        var1 = Launcher.ExtClassLoader.getExtClassLoader();
    } catch (IOException var10) {
        throw new InternalError("Could not create extension class loader", var10);
    }

    try {
        // 构造应用类加载器，在构造过程中将其父类加载器设置为ExtClassLoader，
        // Launcher 的loader属性是AppClassLoader，一般都是由这个类加载器加载应用程序的
        this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
    } catch (IOException var9) {
        throw new InternalError("Could not create application class loader", var9);
    }
    
    Thread.currentThread().setContextClassLoader(this.loader);
    String var2 = System.getProperty("java.security.manager");
    // 省略非核心代码
}

双亲委派机制

类加载器双亲委派模型图如下：

JVM中的类加载是一种双亲委派机制，就是如果某一个类加载器在收到加载请求的时候，首先不会自己去尝试加载这个类，而是先把请求委派给加载器去完成，每一层次的类加载器都是如此，因此所有的类加载请求都会传送至最顶层的引导类加载器中，当父类加载器反馈自己无法完成加载请求的时候，子加载器才会尝试自己去完成加载。

接下来我们来看一下启动类加载器AppClassLoader加载类的双亲委派机制的源码，在AppClassLoader中的sun.misc.Launcher.AppClassLoader#loadClass中会调用期父类的java.lang.ClassLoader#loadClass(java.lang.String, boolean)方法，该方法的答题逻辑如下：

首先，检查指定名称的类是否已经加载过，如果加载过，则直接返回。
如果这个类没有被加载过，那么还需再判断下是否有父类加载器，如果有父类加载器，则由父类加载器加载。
如果父类加载器及BootstrapClassLoader加载器没有找到指定类，那么便会代用当前类加载器的java.lang.ClassLoader#findClass方法来完成类加载。

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // 检查当前类加载器是否已经加载类该类
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {// 如果当前类加载器不为空，则委托父类加载器加载该类
                    c = parent.loadClass(name, false);
                } else {
                    // 如果当前加载器的父加载器为空，在委托引导类加载器来加载该类
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            }

            if (c == null) {
                long t1 = System.nanoTime();
                // 调用URLClassLoader的findClass方法在加载器的类陆经理查找并加载该类
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

为什么设计双亲委派机制

沙箱安全机制：自己定义的和JDK中类名一样的类是不会被加载的，这样可以防止核心API库被随意篡改。
避免类的重复加载：当父加载器已经加载该类时，子加载器就无需再加载该类了，这样便可以保证被加载类的唯一性。

标签：初始化,Launcher,sun,misc,JVM,机制,方法,加载
来源： https://blog.csdn.net/zfy163520/article/details/122249469