1、概述

ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的链接和初始化行为。至于它是否可以运行，则由Execution Engine（执行引擎）决定。

2、类加载器的必要性

一般情况下，Java开发人员并不需要在程序中显式地使用类加载器，但是了解类加载器的加载机制却显得至关重要。从以下几个方面说：

避免在开发中遇到java.lang.ClassNotFoundException异常或java.lang.NoClassDefFoundError异常时，手足无措。只有了解类加载器的加载机制才能够在出现异常的时候快速地根据错误异常日志定位问题和解决问题

需要支持类的动态加载或需要对编译后的字节码文件进行加解密操作时，就需要与类加载器打交道了。

开发人员可以在程序中编写自定义类加载器来重新定义类的加载规则，以便实现一些自定义的处理逻辑。

3、类的加载器分类

JVM支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。

从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分，在程序中我们最常见的类加载器结构主要是如下情况：

除了顶层的启动类加载器外，其余的类加载器都应当有自己的“父类”加载器。

不同类加载器看似是继承（Inheritance）关系，实际上是包含关系。在下层加载器中，包含着上层加载器的引用。

// 看下ClassLoader的定义
class ClassLoader{
    //父类加载器
    ClassLoader parent;
    public ClassLoader(ClassLoader parent){
        this.parent = parent;
    }
}

扩展类加载器和应用程序加载器，都是间接继承至ClassLoader并且通过构造方法，将自己的父类传入。

正是由于子类加载器中包含着父类加载器的引用，所以可以通过子类加载器的方法获取对应的父类加载器。

注意：

启动类加载器通过C/C++语言编写，而自定义类加载器都是由Java语言编写的，虽然扩展类加载器和应用程序类加载器是被jdk开发人员使用java语言来编写的，但是也是由java语言编写的，所以也被称为自定义类加载器

3.1、引导类加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）

这个类加载使用C/C++语言实现的，嵌套在JVM内部。

它用来加载Java的核心库（JAVAHOME/jre/lib/rt.jar或sun.boot.class.path路径下的内容）。用于提供JVM自身需要的类。

并不继承自java.lang.ClassLoader，没有父加载器。

出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

加载扩展类和应用程序类加载器，并指定为他们的父类加载器。

3.2、扩展类加载器

扩展类加载器（Extension ClassLoader）

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。

继承于ClassLoader类

父类加载器为启动类加载器

从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

3.3、应用程序类加载器

应用程序类加载器（系统类加载器，AppClassLoader）

java语言编写，由sun.misc.Launcher$AppClassLoader实现

继承于ClassLoader类

父类加载器为扩展类加载器

它负责加载环境变量classpath或系统属性java.class.path 指定路径下的类库

应用程序中的类加载器默认是系统类加载器。

它是用户自定义类加载器的默认父加载器

通过ClassLoader的getSystemClassLoader()方法可以获取到该类加载器

3.4、用户自定义类加载器

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式。

体现Java语言强大生命力和巨大魅力的关键因素之一便是，Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包，也可以是网络上的远程资源。

通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。

同时，自定义加载器能够实现应用隔离，例如Tomcat，Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C程序要好太多，想不修改C/C程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想。

自定义类加载器通常需要继承于ClassLoader。

4、测试不同的类的加载器

代码：

/**
 * @author liuchao
 * @date 2023/3/21
 */
public class Test_01 {

    public static void main(String[] args) {
        //获取系统该类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        //sun.misc.Launcher$AppCLassLoader@18b4aac2
        System.out.println("1-" + systemClassLoader);
        //获取扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        //sun.misc. Launcher$ExtCLassLoader@1540e19d
        System.out.println("2-" + extClassLoader);
        //试图获取引导类加载器：失败
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        //null
        System.out.println("3-" + bootstrapClassLoader);

        //##################################
        try {
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            //null
            System.out.println("4-" + classLoader);
            //自定义的类默认使用系统类加载器
            ClassLoader classLoader1 = Class.forName("Test_01").getClassLoader();
            //sun.misc.Launcher$AppClassLoader@18b4aac2
            System.out.println("5-" + classLoader1);

            //关于数组类型的加载：使用的类的加载器与数组元素的类的加载器相同
            String[] arrstr = new String[10];
            //null：表示使用的是引导类加载器
            System.out.println("6-" + arrstr.getClass().getClassLoader());

            Test_01[] arr1 = new Test_01[10];
            //sun.misc. Launcher$AppcLassLoader@18b4aac2
            System.out.println("7-" + arr1.getClass().getClassLoader());

            int[] arr2 = new int[10];
            //null:
            System.out.println("8-" + arr2.getClass().getClassLoader());
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

站在程序的角度看，引导类加载器与另外两种类加载器（系统类加载器和扩展类加载器）并不是同一个层次意义上的加载器，引导类加载器是使用C++语言编写而成的，而另外两种类加载器则是使Java语言编写而成的。由于引导类加载器压根儿就不是一个Java类，因此在Java程序中只能打印出空值。

数组类的Class对象，不是由类加载器去创建的，而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说，是通过Class.getClassLoader()返回的，与数组当中元素类型的类加载器是一样的；如果数组当中的元素类型是基本数据类型，数组类是没有类加载器的。

5、ClassLoader源码解析

ClassLoader与现有类的关系：

除了虚拟机自带的加载器外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

5.1、ClassLoader的主要方法

//返回该类加载器的超类加载器
public final ClassLoader getParent()

//加载名称为name的类，返回结果为java.lang.Class类的实例。如果找不到类，
//则返回 ClassNotFoundException异常。该方法中的逻辑就是双亲委派模式的实现
public Class<?> loadClass(String name) throws ClassNotFoundException

//查找二进制名称为name的类，返回结果为java.lang.Class类的实例。
//这是一个受保护的方法，JVM鼓励我们重写此方法，需要自定义加载器遵循双亲委托机制，
//该方法会在检查完父类加载器之后被loadClass()方法调用。
protected Class<?> findClass(String name) throws ClassNotFoundException

//根据给定的字节数组b转换为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，
//其中byte数组b是ClassLoader从外部获取的。
//这是受保护的方法，只有在自定义ClassLoader子类中可以使用。
protected final Class<?> defineClass(String name, byte[] b,int off,int len)

//链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析。
//链接阶段主要是对字节码进行验证，
//为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。
protected final void resolveClass(Class<?> c)

//查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例。这个方法是final方法，无法被修改。
protected final Class<?> findLoadedClass(String name)

//它也是一个ClassLoader的实例，这个字段所表示的ClassLoader也称为这个ClassLoader的双亲。
//在类加载的过程中，ClassLoader可能会将某些请求交予自己的双亲处理。
private final ClassLoader parent;

6、Class.forName()与ClassLoader.loadClass()区别

Class.forName()

Class.forName()：是一个静态方法，最常用的是Class.forName(String className);

根据传入的类的全限定名返回一个Class对象。该方法在将Class文件加载到内存的同时，会执行类的初始化。

Class.forName("com.test.java.Helloworld");

ClassLoader.loadClass()

ClassLoader.loadClass()：这是一个实例方法，需要一个ClassLoader对象来调用该方法。

该方法将Class文件加载到内存时，并不会执行类的初始化，直到这个类第一次使用时才进行初始化。该方法因为需要得到一个ClassLoader对象，所以可以根据需要指定使用哪个类加载器。

Classloader cl = ......; cl.loadClass("com.test.java.Helloworld");

7、双亲委派模型

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。

此模型规定了类加载的顺序是：引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

7.1、此模型的优势与劣势

双亲委派机制优势

避免类的重复加载，确保一个类的全局唯一性

Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。

保护程序安全，防止核心API被随意篡改

双亲委派机制劣势

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

8、Java9新特性

为了保证兼容性，JDK9没有从根本上改变三层类加载器架构和双亲委派模型，但为了模块化系统的顺利运行，仍然发生了一些值得被注意的变动。

①、扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器(platform class loader)。可以通过classLoader的新方法getPlatformClassLoader()来获取。
JDK9是基于模块化进行构建(原来的rt.jar和tools.jar被拆分成数十个JMOD文件)，其中的Java类库就已天然地满足了可扩展的需求，那自然无须再保留<JAVA_HOME>\lib\ext目录，此前使用这个目录或者java.ext.dirs系统变量来扩展JDK功能的机制已经没有继续存在的价值了。

②、平台类加载器和应用程序类加载器都不再继承自java.net.URLClassLoader。
现在启动类加载器、平台类加载器、应用程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader。

注意：如果有程序直接依赖了这种继承关系，或者依赖了URLClassLoader类的特定方法，那代码很可能会在JDK9及更高版本的JDK中崩溃。

③、在Java9中，类加载器有了名称。该名称在构造方法中指定，可以通过getName()方法来获取。平台类加载器的名称是platform，应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。

④、启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器（以前是C++实现），但为了与之前代码兼容，在获取启动类加载器的场景中仍然会返回null，而不会得到BootClassLoader实例。

⑤、类加载的委派关系也发生了变动。当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。

Java中类ClassLoader(加载器)全解