从JDK源码级别彻底剖析JVM类加载机制

最新推荐文章于 2024-01-29 10:51:48 发布

PengGao@PengGao

最新推荐文章于 2024-01-29 10:51:48 发布

阅读量221

点赞数

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

本文链接：https://blog.csdn.net/shuaigepengge/article/details/112171026

版权

JVM 专栏收录该内容

2 篇文章

订阅专栏

一、通过Java命令执行代码的大体流程如下：
在这里插入图片描述
类的生命周期
类的生命周期包括：加载、验证、准备、解析、初始化；

1、加载：获取到类的权限定名(包名+类名)，获取到类的.class文件的二进制字节流，使用到的类才会进行加载，例如：调用类的main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
2、验证：确保class文件的字节流包含的信息，符合当前虚拟机的要求，确保class文件的正确性。
3、准备：为类中的静态字段分配内存，并设置默认的初始值，比如：int类型的初始值为0。呗final修饰的static字段不会设置，因为final在编译的时候就分配了。
4、解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用。
5、初始化: 对类的静态变量初始化为指定的值，执行静态代码块。（若该类具有父类，jvm会保证父类的init先执行，然后在执行子类的init。）

在这里插入图片描述
类被加载到方法区后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息。
类加载器的引用：这个类到类加载器实例的引用
对应class实例的引用：类加载器在加载类信息放到方法区中后，会创建一个对应的Class 类型的对象实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
注意: 主类在运行过程中如果使用到其它类，会逐步加载这些类。
jar包或war包里的类不是一次性全部加载的，是使用到时才加载。

二、类加载器
注：类加载过程中主要是通过类加载器来实现

类加载器分类：引导类加载器、扩展类加载器、应用类加载器、自定义类加载器

1）引导类加载器（Bootstrap ClassLoader）：负责加载支撑JVM运行的位于jre的lib目录下的核心类库如：rt.jar、charsets.jar等

这个类加载器是使用C/C++语言实现的，嵌套在JVM内部，java程序无法直接操作这个类；
并不是继承自java.lang.ClassLoader，它没有父类加载器；
它加载扩展类加载器和应用程序类加载器

2）扩展类加载器（ExtClassLoader）：

Java实现，可以在java里获取，负责加载<JAVA_HOME>/lib/ext下的类
负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR 类包

3）应用程序类加载器（AppClassLoader）：

Java实现，负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类

4）自定义加载器：

负责加载用户自定义路径下的类包
继承java.lang.ClassLoader类，重写findClass()方法
如果没有太复杂的需求，可以直接继承URLClassLoader类，重写loadClass方法，具体可参考AppClassLoader和ExtClassLoader。

三、Launcher和BootStrapClassLoader之间的关系

重点1：Launcher作为JAVA应用的入口，根据双亲委派模型，Laucher是由JVM创建的，它的类加载器是BootStrapClassLoader，这是一个C++编写的类加载器，是java应用体系中最顶层的类加载器，负责加载JVM需要的一些类库(<JAVA_HOME>/lib)，而Launcher类在rt.jar中，正好处于该加载器的加载路径下。
代码验证如下：

package my.test;
import sun.misc.Launcher;
public class Test {

    public static void main(String[] args) {
        ClassLoader classLoader= Launcher.class.getClassLoader();
        System.out.println(classLoader);   //输出null

        ClassLoader testClassLoader = Test.class.getClassLoader();
        System.out.println(testClassLoader); // 输出 sun.misc.Launcher$AppClassLoader@19821f
    }
}

通过以上代码验证总结如下：

这里的classLoader是null，说明Launcher确实是BootstrapClassLoader加载的。
为何classLoader是null，说明Launcher确实是BootstrapClassLoader加载的？因为java.lang.Class类的getClassLoader()方法用于获取此实体的classLoader，该实体可以是类，数组，接口等。我们知道类加载器类型包括四种，分别是启动类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）、应用程序类加载器（Application ClassLoader）、用户自定义加载器，如果是后3种类型，一般会打印出具体的信息，而前面代码中的打印2条结果，第二条sun.misc.Launcher$AppClassLoader@19821f说明应用了程序类加载器，含有关键词‘AppClassLoader’，与此类似，如果是Ext或自定义类型，也有相关的关键词，而第一条为null，不是后3种的类型之一，据此反推第一条是Bootstrap ClassLoader。

四、类加载器初始化过程：

sun.misc.Launcher类是java的入口，在启动java应用的时候会首先创建Launcher类，创建Launcher类的时候会准备应用程序运行中需要的类加载器，位于jre/lib/rt.jar中。
sun.misc.Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个 sun.misc.Launcher实例。
在Launcher构造方法内部，其创建了两个类加载器，分别是 sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。

JVM默认使用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");
    。。。 。。。 //省略一些不需关注代码
}

五、类加载器双亲委派机制：
在这里插入图片描述
双亲委派机制举例描述：类加载其实就有一个双亲委派机制，加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则在自己的类加载路径中查找并载入目标类。比如我们的Math类，最先会找应用程序类加载器加载，应用程序类加载器会先委托扩展类加载器加载，扩展类加载器再委托引导类加载器，顶层引导类加载器在自己的类加载路径里找了半天没找到Math类，则向下退回加载Math类的请求，扩展类加载器收到回复就自己加载，在自己的类加载路径里找了半天也没找到Math类，又向下退回Math类的加载请求给应用程序类加载器，应用程序类加载器于是在自己的类加载路径里找Math类，结果找到了就自己加载了。。

AppClassLoader加载类的双亲委派机制源码如下：
AppClassLoader 的loadClass方法最终会调用其父类ClassLoader的loadClass方法，该方法的大体逻辑如下：

首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回
如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加载
如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的 findClass方法来完成类加载

//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 {
                    if (parent != null) { //如果当前加载器父加载器不为空则委托父加载器加载该类
                        c = parent.loadClass(name, false);
                    } else { //如果当前加载器父加载器为空则委托引导类加载器加载该类
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // 如果没有找到类，则抛出ClassNotFoundException
                    // 来自非空父类装入器
                }

                if (c == null) {
                    // 如果仍然没有找到，那么按顺序调用findClass
                    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;
        }
    }