Java 虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到 Java 虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。其实现被被称为类加载器（ClassLoader）。类加载器在类层次划分、OSGi、程序热部署、代码加密等领域有广泛的使用场景。

类与类加载器

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在 Java 虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。比如两个类来源于同一个 Class 文件，被同一个 Java 虚拟机加载，但只要加载它们的类加载器不同，那这两个类就必定不相等。如果没有注意到类加载器的影响，在某些情况下可能会产生具有迷惑性的结果。

public class ClassLoaderTest {
    public static void main(String[] args) throws Exception {
        ClassLoader myLoader = new ClassLoader() {
            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {
                try {
                    String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
                    InputStream is = getClass().getResourceAsStream(fileName);
                    if (is == null) {
                        return super.loadClass(name);
                    }
                    byte[] bytes = new byte[is.available()];
                    is.read(bytes);
                    return defineClass(name, bytes, 0, bytes.length);
                } catch (IOException e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };
        Object obj = myLoader.loadClass("ClassLoaderTest").newInstance();
        System.out.println(obj.getClass());
        System.out.println(obj.getClass().getClassLoader());
        System.out.println(obj instanceof ClassLoaderTest);
    }
}

运行结果为：

从第一行可以看到这个对象确实是类 ClassLoaderTest 实例化出来的，但第二行的输出结果为 false。这是因为 Java 虚拟机中同时存在了两个 ClassLoaderTest 类，一个是由虚拟机的应用程序类加载器所加载的，另外一个是由我们自定义的类加载器加载的，虽然它们都来自同一个 Class 文件，但在 Java 虚拟机中仍然是两个互相独立的类，做对象所属类型检查时的结果自然为 false。

ClassLoader 是一个抽象类，它抽象了 Class 的加载流程。在 ClassLoader 的实例变量中有一个名为 parent 的字段，它也是一个 ClassLoader 的实例，用于表示这个 ClassLoader 的父类加载器。

该抽象类主要有以下几个核心方法：

/**
 * 通过类名加载这个类的Class实例，如果找不到类则抛出ClassNotFoundException异常。
 */
public Class<?> loadClass(String name) throws ClassNotFoundException
/**
 * 通过类名查找这个类的实例，该方法会在loadClass()方法中被调用，通常用于自定义查找类的逻辑。
 */
protected Class<?> findClass(String name) throws ClassNotFoundException
/**
 * 根据给定的字节码流定义一个类实例，其中byte数组b是ClassLoader从外部获取的。
 */
protected final Class<?> defineClass(String name, byte[] b, int off, int len)

三层类加载器

站在 Java 虚拟机的角度来看，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用 C++ 语言实现，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由 Java 语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。

1. 启动类加载器

启动类加载器（Bootstrap ClassLoader）负责加载存放在 <JAVA_HOME>\lib 目录或者被 -Xbootclasspath 参数所指定的路径中存放的，而且是 Java 虚拟机能够识别的类库加载到虚拟机的内存中。

- Xbootclasspath/a:/Users/book/easyCoding/byJdk/src

启动类加载器是由 C++ 实现的，没有对应的 Java 对象，因此启动类加载器无法被 Java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给启动类加载器去处理，那直接使用 null 代替即可。例如 java.lang.ClassLoader 的 getClassLoader() 方法，其代码实现明确说明了以 null 值来代表引导类加载器的约定规则。

除了启动类加载器外，其他的类加载器都是 java.lang.ClassLoader 的子类，因此有对应的 Java 对象。这些类加载器需要先由另一个类加载器，比如启动类加载器，加载至 Java 虚拟机中才能执行类加载。

2. 扩展类加载器

扩展类加载器（Extension ClassLoader）是在类 sun.misc.Launcher$ExtClassLoader 中以 Java 代码的形式实现的。它负责加载 <JAVA_HOM E>\lib\ext 目录或者被 java.ext.dirs 系统变量所指定的路径中所有的类库。

java -Djava.ext.dirs=your_ext_dir HelloWorld

扩展类加载器是一种 Java 系统类库的扩展机制，JDK 的开发团队允许用户将具有通用性的类库放置在 ext 目录里以扩展 Java SE 的功能，在 JDK 9 之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于扩展类加载器是由 Java 代码实现的，开发者可以直接在程序中使用扩展类加载器来加载 Class 文件。

3. 应用类加载器

应用程序类加载器（Application ClassLoader）由 sun.misc.Launcher$AppClassLoader 来实现。由于应用程序类加载器是 ClassLoader 类中的 getSystemClassLoader() 方法的返回值，所以有些场合中也称它为系统类加载器。它负责加载应用程序路径（指虚拟机参数 -cp/-classpath、系统变量 java.class.path 或环境变量 CLASSPATH 所指定的路径）下的类，开发者同样可以直接在代码中使用这个类加载器。

如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。但是它同样是可能修改的，如果我们指定了 java.system.class.loader 参数，JDK 内建的应用类加载器就会成为定制加载器的父亲，这种方式通常用在类似需要改变双亲委派模式的场景。

java -Djava.system.class.loader=com.yourcorp.YourClassLoader HelloWorld

在 JDK 9 之前的 Java 应用都是由这三种类加载器互相配合来完成加载的，如果用户认为有必要，还可以加入自定义的类加载器来进行拓展，典型的如增加除了磁盘位置之外的 Class 文件来源，或者通过类加载器实现类的隔离、重载等功能。这些类加载器之间的协作关系通常如下图所示。

通过 System.getProperty(“java.class.path”) 可以获取类加载器加载的所有路径，以下为输出示例：

双亲委派模型

上图展示的各种类加载器之间的层次关系被称为类加载器的双亲委派模型（Parents Delegation Model）。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承的关系来实现的，而是通常使用组合关系来复用父加载器的代码。

类加载器的双亲委派模型在 JDK 1.2 时期被引入，并被广泛应用于此后几乎所有的 Java 程序中，但它并不是一个具有强制性约束力的模型，而是 Java 设计者们推荐给开发者的一种类加载器实现的最佳实践。

1. 工作过程

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

2. 优点

使用双亲委派模型来组织类加载器之间的关系，一个显而易见的好处就是 Java 中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.lang.Object，它存放在 rt.jar 之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都能够保证是同一个类。

反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为 java.lang.Object 的类并放在程序的 ClassPath 中，那系统中就会出现多个不同的 Object 类，程序将会变得一片混乱。但实际上用户自己编写的 java.lang.Object 类，最终也是先交由启动类加载器去加载，此时根据类的全限定名会在 rt.jar 包中找到这个类，所以用户自己实现的类可以正常编译，但永远无法被加载运行。

3. 实现方式

双亲委派模型对于保证 Java 程序的稳定运作极为重要，但它的实现却异常简单，用以实现双亲委派模型的代码只有短短十余行，全部集中在 java.lang.ClassLoader 的 loadClass() 方法之中，如下代码所示：

protected Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // 首先，检查请求的类是否已经被加载过
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    // 如果有父类加载器，则请求父类加载器加载
                    c = parent.loadClass(name, false);
                } else {
                    // 如果没有父类加载器，则使用启动类加载器加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 如果父类加载器抛出ClassNotFoundException 
                // 说明父类加载器无法完成类加载请求
            }
            if (c == null) {
                // 在父类加载器无法加载时，再调用本身的findClass方法来进行类加载
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

先检查请求加载的类型是否已经被加载过，若没有则调用父加载器的 loadClass() 方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载器加载失败，抛出 ClassNotFoundException 异常的话，才调用自己的 findClass() 方法进行加载。

private Class<?> findBootstrapClassOrNull(String name) {
    if (!checkName(name)) return null;
    return findBootstrapClass(name);
}
// 这是一个本地方法，因为启动类加载器是用C++写的
private native Class<?> findBootstrapClass(String name);

破坏双亲委派模型

由于双亲委派模型并不是一个具有强制性约束的模型，因此也有一些例外的情况，直到 Java 模块化出现为止，双亲委派模型主要出现过三次较大规模“被破坏”的情况。

1. 案例一

由于双亲委派模型在 JDK 1.2 之后才被引入，但是类加载器的概念和抽象类 java.lang.ClassLoader 则在 Java 的第一个版本中就已经存在，为了兼容已经存在的用户自定义类加载器的代码，只能在 JDK 1.2 之后的 java.lang.ClassLoader 中添加一个新的 protected 方法 findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在 loadClass() 中编写代码，因为 loadClass() 方法中定义了双亲委派的实现。

按照上面的代码中分析的 loadClass() 方法的逻辑，如果父类加载失败的话会调用自己的 findClass() 方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

2. 案例二

双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题，但如果有基础类型又要调用回用户的代码那该怎么办呢？一个典型的例子便是 JNDI 服务，JNDI 的代码由启动类加载器完成加载，但 JNDI 又需要调用由其他厂商实现并部署在应用程序的 ClassPath 下的 JNDI 服务提供者接口（Service Provider Interface，SPI）的代码，但是启动类加载器是不可能认识、加载这些代码的，那该怎么办呢？

为此 Java 的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过 java.lang.Thread 类的 setContextClassLoader() 方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

JNDI 服务使用这个线程上下文类加载器去加载所需的 SPI 服务代码，因为线程上下文类加载器默认设置的是应用程序类加载器，因此可以扫描 classpath 目录下类，这是一种父类加载器（启动类加载器）去请求子类加载器（应用程序类加载器）完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。

Java 中涉及 SPI 的加载基本上都采用这种方式来完成，例如 JNDI、JDBC 等。不过当 SPI 的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在 JDK 6 时提供了 java.util.ServiceLoader 类，以 META-INF/services 中的配置信息，辅以责任链模式，这才算是给 SPI 的加载提供了一种相对合理的解决方案。

public static <T> ServiceLoader<T> load(Class<T> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

3. 案例三

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的，这里的动态性是指：代码热替换、模块热部署等。比如 OSGi 通过类加载器实现热部署。

OSGi 实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（Bundle）都有一个自己的类加载器，当需要更换一个 Bundle 时，就把 Bundle 连同类加载器一起换掉以实现代码的热替换。在 OSGi 环境下，类加载器不再是双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。

自定义类加载器

谈到类加载器，绕不过的一个话题是自定义类加载器。自定义类加载器主要的场景有：实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。

我们可以总体上简单理解自定义类加载过程：

通过 findClass 根据指定名称，找到其二进制实现，这里往往就是自定义类加载器会“定制”的部分。
然后通过 defineClass 创建 Class 对象，并完成类加载过程，即二进制信息到 Class 对象的转换，这部分我们无需自己实现，它是 final 方法。有了 Class 对象，后续完成加载过程就顺理成章了。

参考案例：https://www.baeldung.com/java-classloaders

虚拟机类加载器