这是「死磕P7」系列第 006 篇文章，欢迎大家来跟我一起 死磕 100 天，争取在 2025 年来临之际，给自己一个交代。

接上篇，上一篇介绍了 JVM 类加载过程及类的生命周期，回顾一下：

死磕P7: JVM类加载那些事儿，一起探知类的前世今生（一）-CSDN博客

类加载过程用到一个叫做类加载器的东西，所谓类加载器（Class Loader），其实就是一段代码。

这段代码的主要功能就是：通过一个类的全限定名来获取类的二进制字节流。

类与类加载器

对于任意一个类，都必须由其「类加载器」和「该类本身」共同确定它在 JVM 中的唯一性。

若要比较两个类是否相等，前提是这两个类必须是由同一个类加载器加载。

这里的「相等」，包括 equals、isAssignableFrom、isInstance 等方法，还有 instanceof 关键字。

即类加载器负责加载所有的类，其为所有被载入内存中的类生成一个java.lang.Class实例对象。一旦一个类被加载入JVM中，同一个类就不会被再次载入了。

类加载器

JVM预定义有三种类加载器，当一个 JVM启动的时候，Java开始使用如下三种类加载器：

• 启动类加载器（Bootstrap ClassLoader）

• 扩展类加载器（Extension ClassLoader）

• 应用程序类加载器（Application ClassLoader）

当然，用户也可以自定义类加载器~有时候会有用，关注公&号：新质程序猿，后面会介绍到。

启动类加载器（Bootstrap ClassLoader）

负责加载 JAVA_HOME\lib 目录，或者 -Xbootclasspath 参数指定路径下，且被 JVM 识别的类库。

用来加载java的核心库，此类加载器并不继承于java.lang.ClassLoader，不能被java程序直接调用，代码是使用C++编写的，是虚拟机自身的一部分。

扩展类加载器（Extension ClassLoader）

由 sun.misc.Launcher$ExtClassLoader 类实现,负责加载 JAVA_HOME\lib\ext 目录，或者 java.ext.dirs 系统变量指定的路径中的类库。

应用程序类加载器（Application ClassLoader）

由 sun.misc.Launcher$AppClassLoader 类实现，加载用户类路径（ClassPath）下所有的类库，默认的系统类加载器（若没有自定义过类加载器，一般使用该类进行加载）。

说到类加载器，就不得不提「双亲委派模型」

双亲委派模型

双亲委派模型的工作流程大致如下：

若一个类加载器准备去加载类时，它首先不会自己尝试去加载这个类，而是将其委派给父类加载器，父加载器亦是如此，直至启动类加载器；仅当父加载器无法加载该类的时候，子加载器才会尝试自己进行加载。

有点啃老的意味哈，哈哈哈！（后面有实际示例）

双亲委派模型的实现代码在 java.lang.ClassLoader 类的 loadClass 方法中，如下：

类加载器加载Class经过如下步骤：

1. 检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。

2. 如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。

3. 请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。

4. 请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。

5. 当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。

6. 从文件中载入Class，成功后跳至第8步。

7. 抛出ClassNotFountException异常。

8. 返回对应的java.lang.Class对象。

为什么要采用双亲委派模型？这样做有什么好处呢？

Java 类随着类加载器有了层级关系，把最基础的类，例如 java.lang.Object，交给最顶端的类加载器加载，保证在各个加载器环境中都是同一个 Object 类。

破坏双亲委派模型

双亲委派模型可以理解为一个规范，然而某些地方由于某些原因并未遵循这个规范。对于那些没有遵循该规范的地方，就是破坏了双亲委派模型。

破坏双亲委派模型的行为大致有三次（看不懂没关系，我也没太懂，看最后的示例即可）

第一次

由于“双亲委派模型”是 JDK 1.2 引入的，但类加载和 java.lang.ClassLoader 类在此之前就已经存在了，为了兼容已有代码，双亲委派模型做了妥协。

由于 ClassLoader 类的 loadClass 方法可以直接被子类重写，这样的类加载机制就不符合双亲委派模型了。

如何实现兼容呢？在 ClassLoader 类添加了 findClass 方法，并引导用户重写该方法，而非 loadClass 方法。

第二次

双亲委派模型的类加载都是自底向上的（越基础的类由越上层的加载器来加载），但有些场景可能会出现基础类型要反回来调用用户代码，这个场景如何解决呢？

一个典型的例子就是 JNDI （启动类加载器加载）服务，其目的是调用其它厂商实现并部署在应用程序 ClassPath 下的服务提供者接口（Service Provider Interface，SPI）。启动类加载器是不认识这些 SPI 的，如何解决呢？

Java 团队引入了一个线程上下文类加载器（Thread Context ClassLoader），可以设置类加载器，在启动类加载器不认识的地方，调用其它类加载器去加载。这其实也打破了双亲委派模型。

比如 JDBC 的类加载机制。

第三次

第三次破坏是对程序动态性的追求导致的，代码热替换（Hot Swap）、模块热部署（Hot Deployment）等。典型的如 IBM 的 OSGi 模块化热部署。

自定义类加载器

自定义 MyClassLoader

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;

public class MyClassLoader extends ClassLoader {

    // 重写 findClass 方法
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        byte[] classData = loadClassData(name);
        if (classData == null) {
            throw new ClassNotFoundException();
        }
        return defineClass(name, classData, 0, classData.length);
    }

    // 读取 class 文件
    private byte[] loadClassData(String className) {
        String fileName = "/Users/hyx/Documents/workspace/github/hello/out/production/hello" +
                File.separatorChar + className.replace('.', File.separatorChar) + ".class";
        try {
            FileInputStream inputStream = new FileInputStream(fileName);
            ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
            byte[] buffer = new byte[1024];
            int length;
            while ((length = inputStream.read(buffer)) != -1) {
                outputStream.write(buffer, 0, length);
            }
            return outputStream.toByteArray();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }
}

创建一个 Person 类

public class Person {
    static {
        // 当 Person 类初始化时，会打印该代码
        System.out.println("Person init!");
    }

    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

写一个 Hello 主类及 test1 方法

public class Hello {

    private static void test1() throws Exception {
        // 创建类加载器实例
        MyClassLoader myClassLoader1 = new MyClassLoader();
        // 加载 Person 类（注意这里是 loadClass 方法）
        Class<?> aClass1 = myClassLoader1.loadClass("Person");
        aClass1.newInstance(); // Person init!

        MyClassLoader myClassLoader2 = new MyClassLoader();
        Class<?> aClass2 = myClassLoader2.loadClass("Person");
        aClass2.newInstance();

        System.out.println("--->" + aClass1.getClassLoader()); // sun.misc.Launcher$AppClassLoader@18b4aac2
        System.out.println("--->" + aClass2.getClassLoader()); // sun.misc.Launcher$AppClassLoader@18b4aac2
        System.out.println("--->" + aClass1.equals(aClass2)); // true
    }

    public static void main(String[] args) throws Exception {
        System.out.println("Hello world!");
        test1();
    }
}

执行 main 方法

可以看到，这里虽然使用了两个类加载器实例加载 Person 类，但实际上 aClass1 和 aClass2 的类加载器并不是自定义的 MyClassLoader，而是 Launcher$AppClassLoader，即应用类加载器。为什么会是这个结果呢？

其实这就是前面分析的双亲委派模型，示意图如下：

大体流程分析：

1. 使用 MyClassLoader 加载 Person 类时，它会先委托给 AppClassLoader；

2. AppClassLoader 委托给 ExtClassLoader；

3. ExtClassLoader 委托给启动类加载器；

4. 但是，启动类加载器并不认识 Person 类，无法加载，于是就再反回来交给 ExtClassLoader；

5. ExtClassLoader 也无法加载，于是交给了 AppClassLoader；

6. AppClassLoader 可以加载 Person 类，加载结束。

非双亲委派模型类加载

还是上面的自定义类加载器，如何破坏双亲委派模型呢？把上面的 loadClass 方法换成 findClass 就行，示例代码：

Hello 主程序, 添加了一个 test2 方法

public class Hello {

    private static void test1() throws Exception {
        // 创建类加载器实例
        MyClassLoader myClassLoader1 = new MyClassLoader();
        // 加载 Person 类（注意这里是 loadClass 方法）
        Class<?> aClass1 = myClassLoader1.loadClass("Person");
        aClass1.newInstance(); // Person init!

        MyClassLoader myClassLoader2 = new MyClassLoader();
        Class<?> aClass2 = myClassLoader2.loadClass("Person");
        aClass2.newInstance();

        System.out.println("--->" + aClass1.getClassLoader()); // sun.misc.Launcher$AppClassLoader@18b4aac2
        System.out.println("--->" + aClass2.getClassLoader()); // sun.misc.Launcher$AppClassLoader@18b4aac2
        System.out.println("--->" + aClass1.equals(aClass2)); // true
    }

    private static void test2() throws Exception {
        MyClassLoader cl1 = new MyClassLoader();
        // 加载自定义的 Person 类
        Class<?> aClass1 = cl1.findClass("Person");
        // 实例化 Person 对象
        aClass1.newInstance(); // Person init!

        MyClassLoader cl2 = new MyClassLoader();
        Class<?> aClass2 = cl2.findClass("Person");
        aClass2.newInstance(); // Person init!

        System.out.println("--->" + aClass1); // class loader.Person
        System.out.println("--->" + aClass2); // class loader.Person

        System.out.println("--->" + aClass1.getClassLoader()); // loader.MyClassLoader@60e53b93
        System.out.println("--->" + aClass2.getClassLoader()); // loader.MyClassLoader@1d44bcfa

        System.out.println("--->" + aClass1.equals(aClass2)); // false
    }

    public static void main(String[] args) throws Exception {
        System.out.println("Hello world!");
        test1();
        test2();
    }
}

执行

这里创建了两个自定类加载器 MyClassLoader 的实例，分别用它们来加载 Person 类。

虽然两个打印结果都是 class loader.Person ，但类加载器不同，导致 equals 方法的结果是 false，原因就是二者使用了不同的类加载器。

根据 MyClassLoader 的代码，这里实际并未按照双亲委派模型的层级结构去加载 Person 类，而是直接使用了 MyClassLoader 来加载的。

总结

本文还是比较干的，类加载器其实就是用来加载 class 文件到内存，然后创建 Class 类实例的过程，Java 提供了 3 种自带的 类加载器，分别是 启动类加载器，扩展类加载器，应用程序类加载器，另外，用户可以自己自定义类加载器。

面试中常考的点之一就是「双亲委派模型」，其实也比较好理解，为了确保类的全局唯一性，只要有一个类加载器加载过了就不用再加载了。

破坏双亲委派的最典型也是最常见的就是自定义类加载器然后通过实现 findClass 方法了，你也可以去尝试一下，体验一下。

---

END

好了，今天的分享就到这里，关注公&号：新质程序猿，和我一起死磕 P7, 一起学习成长。

感谢大家的阅读，如果有任何异议的地方，欢迎指正，也欢迎大家公号找到我与我做朋友！

小福利

文末小福利，作为资深囤货达人，购置或转存了上千 T 的各种资源，反正我也学不完，如有需要，可以公号： 新质程序猿 找到我，直接送您，能帮助到大家也算是有所福报吧！