前言

在类的生命周期中，第一个阶段是就是类的加载阶段，在这个阶段，非数组类的二进制字节流被加载进内存中，并生成一个java.lang.Class对象。

本文主要论述发生在这一阶段的故事。

一. 类加载器

1.1 类加载器的种类

JVM 中内置了三个重要的 ClassLoader，除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader

（图）类加载器的层次关系

对于JVM来说，类加载器分为两种：

1. 启动类加载器：对于Hotsopt虚拟机来说，启动类加载器是用C++实现的，它属于虚拟机的一部分
2. 其他类加载器：这类加载器都使用Java语言实现，独立于虚拟机之外，并且全部继承于 java.lang.ClassLoader 这些类加载器需要由启动类加载到内存中才能去加载其他的类

对于开发者来说，类加载器可以分为三类：

1. 启动类加载器（Bootstrap ClassLoader）：负责加载 ${JAVA_HOME}/jre/lib 目录下，或者被 -Xbootclasspath 参数指定的路径中，能被虚拟机识别的类库；启动类加载器无法被开发人员使用。
2. 扩展类加载器（Extension ClassLoader）：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包；开发人员可以直接使用扩展类加载器。
3. 应用程序类加载器（Application ClassLoader）：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类；开发者可以直接使用该类加载器。

1.2 查询该类的类加载器

示例代码：

public class Test {
    public static void main(String[] args) {
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        System.out.println(classLoader);
        System.out.println(classLoader.getParent());
        System.out.println(classLoader.getParent().getParent());
    }
}

输出：

sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@4eec7777
null

第三个为null的原因是因为HotSopt的BootstrapClassLoader 是用C++实现的，找不到一个具体的对象

1.3 自定义类加载器

通常情况下，我们都是直接使用系统类加载器，但有些是有也需要我们自定义类加载器，比如通过网络传输的字节码文件，为了安全通过了加密处理，这时系统加载器就无法加载这些类了

除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader；如果我们要自定义自己的类加载器，只需要继承 ClassLoader即可

二. 双亲委派机制

每个类都有自己的类加载器，系统中的 ClassLoader 在协同工作的时候会默认使用 双亲委派机制

双亲委派机制：

1. 在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。
2. 加载的时候，首先会把该请求委派给父类加载器的 loadClass() 处理，当父类加载器为 null 时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器，所有的请求都会到达启动类加载器中。
3. 当请求到达BootstrapClassLoader 中，会自顶向下检查是否能被加载，直到有人说我可以。

2.1 双亲委派机制的代码实现

在 java.lang.ClassLoader 的 loadClass() 中

public Class<?> loadClass(String name)throws ClassNotFoundException {
        return loadClass(name, false);
}
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    // 首先判断该类型是否已经被加载
    Class c = findLoadedClass(name);
    if (c == null) {
        //如果没有被加载，就委托给父类加载或者委派给启动类加载器加载
        try {
            if (parent != null) {
                //如果存在父类加载器，就委派给父类加载器加载
                c = parent.loadClass(name, false);
            } else {
                //如果不存在父类加载器，就检查是否是由启动类加载器加载的类，通过调用本地方法native Class findBootstrapClass(String name)
                c = findBootstrapClass0(name);
            }
        } catch (ClassNotFoundException e) {
            // 如果父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能
            c = findClass(name);
        }
    }
    if (resolve) {
        resolveClass(c);
    }
    return c;
}

2.2 为什么要采用双亲委派机制

双亲委派机制，可以避免类被重复加载，特别是系统的核心类。

假如现在有人想替换系统级别的类：java.lang.String，在双亲委派机制下，它已经被BootstrapClassLoader 加载过了，其他类加载器没有机会再加载了。

因此，双亲委派模型保证了 Java 程序的稳定运行，也保证了 Java 的核心 API 不被篡改。

三. 总结

JVM的类加载机制，总结为以下几点：

1. 全盘委托机制：当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入
2. 缓存机制：缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，才会执行加载逻辑，并存入缓存区
3. 双亲委派机制：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上；如果父类加载器无法加载，再依次向下