03_类加载器

类加载器

本文整理自尚硅谷宋红康老师在B站的视频，侵权即删。

本文的思维导图如下：

1 概述

类加载器ClassLoader是JWM执行类加载机制的前提，作用是：

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

2 类加载器的分类

JVM支持两种类型的类加载器：引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader)。

从概念上来讲，自定义类加载器一般是指程序中由开发人员定义的类加载器，但是虚拟机规范中的定义是，将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器，自定义类加载器都是由Java语言编写，所以扩展类加载器(Extension ClassLoader)和应用程序类加载器(Application ClassLoader)也被称为自定义类加载器；引导类加载器也称为启动类加载器，由C/C++语言编写。

常见的类加载器结构如下：

说明：

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

• 这里的“父类”不是指类的继承关系，子加载器和父加载器之间的关系是包含关系，子加载器包含着父加载器的引用，所以通过子加载器的方法可以获取对应的父加载器。

  class ClassLoader{
      ClassLoader parent; // 父加载器
      
      public ClassLoader(ClassLoader parent){
          this.parent = parent;
      }
  }
  
  class ParentClassLoader extends ClassLoader{
      public ParentClassLoader(ClassLoader parent){
          super(parent);
      }
  }
  
  class ChildClassLoader extends ClassLoader{
      public ChildClassLoader(ClassLoader parent){ //parent = new ParentClassLoader();
          super(parent);
      }
  }
  

2.1 引导类加载器

引导类加载器(Bootstrap ClassLoader)，也称为启动类加载器：

• 使用C/C++语言实现的，嵌套在JVM内部。
• 用来加载Java的核心库（ JAVA HOME/jre/lib/rt.jar或sun.boot.c1ass.path路径下的内容）。用于提供JVM自身需要的类。
• 不继承自java.lang.Classloader，没有父加载器。
• 出于安全考虑， 启动类加载器只加载包名为java、 javax、sun等开头的类。
• 加载扩展类加载器和应用程序类加载器，并指定为扩展类加载器的父类加载器。

测试某个类，通过设置-XX:+TraceClassLoading参数可得到类的加载过程：

2.2 扩展类加载器

扩展类加载器(Extension ClassLoader)：

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

• 继承于Classloader类。

  • 

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

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

2.3 应用程序类加载器

应用程序类加载器(Application ClassLoader)，也称为系统类加载器：

• Java语言编写，由sun.misc. Launcher$AppClassloader实现。
• 继承于Classloader类。
• 父类加载器为扩展类加载器。
• 负责加载环境变量classpath或系统属性java.class.path指定路径下的类库。
• 应用程序中的类加载器默认是此类加载器。
• 它是用户自定义类加载器的默认父加载器。
• 通过Classloader#getSystemClassloader()方法可以获取到该类加载器，所以也称系统类加载器。

2.4 用户自定义类加载器

用户自定义类加载器(User ClassLoader)：

• 在Java的日常应用程序开发中，类的加载几乎是由上述三种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式。
• 体现Java语言强大生命力和巨大魅力的关键因素之一便是，Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包，也可以是网络上的远程资源。
• 通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。
• 自定义加载器能够实现应用隔离，例如 Tomcat, Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好，想不修改C/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想。
• 自定义类加载器通常需要继承于ClassLoader。

3 测试不同的类加载器

每个Class实例都持有一个定义它的ClassLoader的引用，获取ClassLoader的途径：

// 获取当前类的ClassLoader
clazz.getClassLoader();

// 获取当前线程上下文的ClassLoader
// 结果是应用程序类加载器，Launcher.java源码中有体现
Thread.currentThread().getContextClassLoader();

// 获取系统的ClassLoader
// 结果是应用程序类加载器
ClassLoader.getSystemClassLoader()

说明：

引导类加载器与另外两种类加载器（应用程序类加载器和扩展类加载器）并不是同一个层次意义上的加载器，引导类加载器是使用C++语言编写而成的，而另外两种类加载器则是使用Java语言编写而成的。由于引导类加载器根本不是一个Java类，因此在Java程序中，如果试图获取引导类加载器，只能打印出空值。

测试代码：

public class GetClassLoaderTest {
    @Test
    public void testA() {
        // 获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader); // sun.misc.Launcher$AppClassLoader@18b4aac2

        // 获取扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader); // sun.misc.Launcher$ExtClassLoader@5305068a

        // “试图”获取引导类加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader); // null

        /***************************************/
        try {
            // “试图”获取引导类加载器
            ClassLoader bootstrapClassLoader1 = Class.forName("java.lang.String").getClassLoader();
            System.out.println(bootstrapClassLoader1); // null

            // 自定义类的默认使用应用程序类加载器
            ClassLoader classLoader = Class.forName("com.yupeng.classloadertest.GetClassLoaderTest").getClassLoader();
            System.out.println(classLoader); // sun.misc.Launcher$AppClassLoader@18b4aac2

            // 数组类的加载：使用的类加载器与数组元素的类加载器相同
            String[] arrStr = new String[10];
            System.out.println(arrStr.getClass().getClassLoader()); // null

            GetClassLoaderTest[] arr = new GetClassLoaderTest[3];
            System.out.println(arr.getClass().getClassLoader()); // sun.misc.Launcher$AppClassLoader@18b4aac2

            // 数量元素为基本数据类型，得到的结果为null，因为基本数据有JVM内置，不是由类加载器加载
            int[] arrInt = new int[5];
            System.out.println(arrInt.getClass().getClassLoader()); // null
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

4 ClassLoader源码分析

4.1 ClassLoader的主要方法

(1) public final ClassLoader getParent()

该方法返回类加载器的父加载器。

(2) public Class<?> loadClass (String name) throws ClassNotFoundException

该方法加载名称为name的类，返回结果为java.lang.Class类的实例。如果找不到该类，则抛出ClassNotFoundException异常；该方法中的逻辑就是双亲委派机制的实现。

该方法会调用protected Class<?> loadClass(String name, boolean resolve)，实现如下：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    // 向上委托
                    c = parent.loadClass(name, false);
                } else {
                    // 父加载器为null，即parent为引导类加载器
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }

            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                long t1 = System.nanoTime();
                // 父加载器无法加载，则由自己加载
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getfindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getfindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

(3) protected Class<?> findClass(String name) throws ClassNotFoundException

该方法查找名称为name的类，返回结果为java.lang.Class类的实例；这是一个受保护的方法，需要自定义加载器时应遵循双亲委派机制，所以JVM鼓励我们重写此方法而不是重写loadClass()方法，该方法会在loadclass()方法中检查完父类加载器之后被调用。

在JDK1.2之前，自定义类加载时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载类。但是在JDK1.2之后，己不再建议用户去重写 loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中，从前面的分析可知， findClass()方法是在loadClass()方法中被调用的， loadclass()方法中父加载器加载失败后，则会调用自己的 findClass()方法来完成类加载，这样就可以保证自定义的类加载器也符合双亲委托模式。

需要注意的是，Classloader类中并没有实现findClass()方法的具体代码逻辑，取而代之的是抛出ClassNotFoundException异常，另外，findClass()方法通常是和defineClass()方法起使用的。一般情况下，在自定义类加载器时，会直接覆盖Classloader的findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用 defineClass()方法生成类的Class对象。

(4) protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError

该方法根据给定的字节数组b转换为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，其中byte数组b是classloader从外部获取的，比如可以通过class文件获得，也可以通过网络接收一个字节码，然后转换为byte字节流。这是受保护的方法，只有在自定义的ClassLoader子类中可以使用。

举例：

protected Class<?> findclass (String name) throws ClassNotFoundException {
    //获取类的字节数组
    byte[] classData = getclassData(name);
    if (classData = null){
        throw new ClassNotFoundException;
    } else {
        // 调用defineClass()生成class对象
        return defineClass(name, classData, 0, classData.length);
    }
}

(5) protected final void resolveClass(Class<?> c)

该方法可以使类的Class对象创建完成的同时，也被解析。链接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值，此方法同时将字节码文件中的符号引用转换为直接引用。

(6) protected final Class<?> findLoadedClass(String name)

该方法查找名称为name的己经被加载过的类，返回结果为java.lang.Class类的实例。这个方法是final方法，无法被修改。

(7) private final ClassLoader parent

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

4.2 SecureClassLoader与URLClassLoader

SecureClassLoader继承于ClassLoader，新增了几个与使用相关的代码源（对代码源的位置及其证书的验证）和权限定义类验证（主要指对class源码的访问权限）的方法，一般我们不会直接跟这个类打交道，更多是与它的子类URLClassloader有所关联。

前面说过， ClassLoader是一个抽象类，很多方法是空的没有实现，比如 findclass()、 findResource()等，而URLClassLoader这个实现类为这些方法提供了具体的实现；并新增了URLClassPath类，协助取得Class字节码流等功能。在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

4.3 ExtClassLoader和AppClassLoader

拓展类加载器ExtClassLoader和系统类加载器AppClassLoader，这两个类都继承自URLClassLoader，是sun.misc.Launcher的静态内部类。sun.misc. Launcher主要被系统用于启动主应用程序。

ExtClassLoader并没有重写loadclass()方法，这说明其遵循双亲委派模式，而 AppClassLoader重写了loadClass()方法，但最终调用的还是父类的loadclass()方法，因此依然遵守双亲委派模式。

4.4 Class.forName()与ClassLoader.loadClass()

Class.forName()：是一个静态方法，最常用的是Class.forName(String className)；根据传入的类的全限定名返回一个Class对象。该方法在将Class文件加载到内存的同时，会执行类的初始化。

ClassLoader.loadclass()：是一个实例方法，需要一个ClassLoader对象来调用该方法。该方法将Class文件加载到内存时，不会执行类的初始化，直到此类第一次主动使用时才进行初始化。该方法因为需要得到一个Classloader对象，所以可以根据需要指定使用哪个类加载器。如：

ClassLoader c1=...;
c1.loadclass("com.xxx.yyy");

5 双亲委派机制

5.1 定义与本质

类加载器用于把类加载到Java虚拟机中，从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。

定义：如果一个类加载器在接到加载某个类的请求时，首先查看系统是否已有此类，如果没有，它不会自己尝试去加载这个类，而是把这个请求任务委托给它的父类加载器去完成，如果父类加载器可以完成类加载任务，就成功返回；如果父类加载器无法完成此加载任务，由自己去加载，自己也无法完成，则由子加载器完成。

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

具体流程如下图所示：

5.2 优势与劣势

5.2.1 双亲委派机制的优势

双亲委派机制的优势如下：

• 避免类的重复加载，确保一个类的全局唯一性。
  • Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避兔类的重复加载，当父加载器已经加载了该类时，就没有必要子加载器再加载一次。
• 保护程序安全，防止核心API被随意篡改

代码说明：

双亲委派机制在java.lang.ClassLoader. loadClass(String, boolean)方法中体现。该方法的逻辑如下：

（1）先在当前加载器的缓存中查找有无目标类，如果有，直接返回；

（2）判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadclass(name, false)方法进行加载；

（3）反之，如果当前加载器的父类加载器为空，则调用 findBootstrapClassOrNull(name)方法，让引导类加载器进行加载；

（4）如果通过以上3条路径都没能成功加载，则调用 findClass(name0接口进行加载。该接口最终会调用java.lang. ClassLoader接口的defineClass方法加载目标类。

双亲委派的模型就隐藏在第2和第3步中。

举例：

假设当前要加载java.lang.Object这个类，很显然，该类属于JDk中非常核心的一个类，因此一定只能由引导类加载器进行加载。当JVM准备加载java.lang.Object时，JVM默认会使用系统类加载器去加载，按照上面加载的逻辑，在第1步从系统类的缓存中肯定查找不到该类，于是进入第2步，由于从系统类加载器的父加载器是扩展类加载器，不为空，所以扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也一定査找不到该类，因此进入第2步。扩展类的父加载器是null，因此系统调用 findBootstrapClassOrNull()，最终通过引导类加载器进行加载。

5.2.2 双亲委派机制的劣势

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

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

总结：

Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。

比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

6 破坏双亲委派机制

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。

在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。

6.1 破坏双亲委派机制1

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前一一即JDK1.2面世以前的“远古”时代。

由于双亲委派模型在JDK1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader在Java的第一个版本中就己经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在 loadClass()中编写代码。

上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照 loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的 findClass()方法来完成加载，这既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

以上简单来说就是JDK1.2之前还没有引入双亲委派机制，所以JDK1.2之前就是破坏双亲委派机制的情况。

6.2 破坏双亲委派机制2

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？

一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载，肯定属于Java中很基础的类型了；但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？（SPI：在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI）

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

有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JB1等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK6时，JDK提供了java.util. Serviceloader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

以上简单来说就是线程上下文类加载器让启动类加载器和系统类加载器直接联系起来了，中间的扩展类加载器被省略了，这就破坏了双亲委派机制，其中线程上下文类加载器就是系统类加载器。

6.3 破坏双亲委派机制3

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：**代码热替换(Hot Swap) 、模块热部署(Hot Deployment)**等。

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

当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

*1）将以java.开头的类，委派给父类加载器加载。

2）否则，将委派列表名单内的类，委派给父类加载器加载。

3）否则，将 Import列表中的类，委派给 Export这个类的 Bundle的类加载器加载。

4）否则，查找当前 Bundle的 ClassPath，使用自己的类加载器加载。

5）否则，查找类是否在自己的 Fragment Bundle中，如果在，则委派给 Fragment Bundle的类加载器加载。

6）否则，查找 Dynamic Import列表的 Bundle，委派给对应 Bundle的类加载器加载。

7）否则，类查找失败.

说明：只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的。

7 自定义类加载器

为什么要自定义类加载器：

• 隔离加载类

在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如：阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如：Tomcat这类web应用服务器，内部自定义了好几种类加载器，用于隔离同一个Web应用服务器上的不同应用程序。

• 修改类加载的方式

类的加载模型并非强制，除 Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载

• 扩展加载源

比如从数据库、网络、甚至是电视机机顶盒进行加载

• 防止源码泄漏

Java代码容易被编译和篡改，可以进行编译加密；那么类加载也需要自定义，还原加密的字节码。

自定义类加载器的常见场景：

• 实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是J ava EE和OSGI、JPMS等框架。
• 应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统；或者是需要自己操纵字节码，动态修改或者生成类型。

实现方式：

• Java提供了抽象类java.lang.ClsssLoader，所有用户自定义的类加载器都应该继承ClassLoader类。
• 其父类加载器默认是系统类加载器。
• 在自定义 ClassLoader的子类时候，我们常见的会有两种做法：
  • 方式一：重写loadClass()方法
  • 方式二：重写findClass()方法，推荐此方法

这两种方法本质上差不多，毕竟loadClass()也会调用 findClass()，但是从逻辑上讲，最好不要直接修改loadClass()的内部逻辑。建议的做法是只在 findClass()里重写自定义类的加载方法，根据参数指定类的名字，返回对应的Class对象的引用。

• loadclass()这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法会导致模型被破坏，容易造成问题。因此我们最好是在双亲委派模型框架内进行小范围的改动，不破坏原有的稳定结构。同时，也避免了自己重写loadclass()方法的过程中必须写双亲委托的重复代码，从代码的复用性来看，不直接修改这个方法始终是比较好的选择。
• 当编写好自定义类加载器后，便可以在程序中调用loadClass()方法来实现类加载操作。

8 JDK9新特性

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

(1) 扩展机制被移除

扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器(platform ClassLoader)。可以通过 ClassLoader的新方法getPlatformClassloader()来获取。

JDK9时基于模块化进行构建（原来的rt.jar和tools.jar被拆分成数十个JMOD文件），其中的Java类库就己天然地满足了可扩展的需求，那自然无须再保留JAVA HOME\lib\ext目录，此前使用这个目录或者java.ext.dirs系统变量来扩展JDK功能的机制己经没有继续存在的价值了。

(2) 类的继承关系发生改变

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

(3) 类加载器有了名称

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

(4) 启动类加载器的实现

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

(5) 类加载的委派关系

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