https://gitee.com/vectorx/NOT…

https://codechina.csdn.net/qq…

https://github.com/uxiahnan/N…

[toc]

1. 概述

类加载器是 JVM 执行类加载机制的前提。

ClassLoader 的作用：

ClassLoader 是 Java 的外围组件，所有的 Class 都是由 ClassLoader 进行加载的，ClassLoader 负责通过各种形式将 Class 信息的二进制数据流读入 JVM 外部，转换为一个与指标类对应的 java.lang.Class 对象实例。而后交给 Java 虚拟机进行链接、初始化等操作。因而，ClassLoader 在整个装载阶段，只能影响到类的加载，而无奈通过 ClassLoader 去扭转类的链接和初始化行为。至于它是否能够运行，则由 Execution Engine 决定。

1.1. 大厂面试题

<mark> 蚂蚁金服：</mark>

深入分析 ClassLoader，双亲委派机制

类加载器的双亲委派模型是什么？一面：双亲委派机制及应用起因

<mark> 百度：</mark>

都有哪些类加载器，这些类加载器都加载哪些文件？

手写一个类加载器 Demo

Class 的 forName（“java.lang.String”）和 Class 的 getClassLoader（）的 Loadclass（“java.lang.String”）有什么区别？

<mark> 腾讯：</mark>

什么是双亲委派模型？

类加载器有哪些？

<mark> 小米：</mark>

双亲委派模型介绍一下

<mark> 滴滴：</mark>

简略说说你理解的类加载器一面：讲一下双亲委派模型，以及其长处

<mark> 字节跳动：</mark>

什么是类加载器，类加载器有哪些？

<mark> 京东：</mark>

类加载器的双亲委派模型是什么？

双亲委派机制能够突破吗？为什么

1.2. 类加载器的分类

类的加载分类：显式加载 vs 隐式加载

class 文件的显式加载与隐式加载的形式是指 JVM 加载 class 文件到内存的形式。

• 显式加载指的是在代码中通过调用 ClassLoader 加载 class 对象，如间接应用 Class.forName(name)或 this.getClass().getClassLoader().loadClass()加载 class 对象。
• 隐式加载则是不间接在代码中调用 ClassLoader 的办法加载 class 对象，而是通过虚拟机主动加载到内存中，如在加载某个类的 class 文件时，该类的 class 文件中援用了另外一个类的对象，此时额定援用的类将通过 JVM 主动加载到内存中。

在日常开发以上两种形式个别会混合应用。

// 隐式加载
User user=new User();
// 显式加载，并初始化
Class clazz=Class.forName("com.test.java.User");
// 显式加载，但不初始化
ClassLoader.getSystemClassLoader().loadClass("com.test.java.Parent"); 

1.3. 类加载器的必要性

个别状况下，Java 开发人员并不需要在程序中显式地应用类加载器，然而理解类加载器的加载机制却显得至关重要。从以下几个方面说：

• 防止在开发中遇到 java.lang.ClassNotFoundException 异样或 java.lang.NoClassDefFoundError 异样时，不知所措。只有理解类加载器的 加载机制才可能在出现异常的时候疾速地依据谬误异样日志定位问题和解决问题
• 须要反对类的动静加载或须要对编译后的字节码文件进行加解密操作时，就须要与类加载器打交道了。
• 开发人员能够在程序中编写自定义类加载器来从新定义类的加载规定，以便实现一些自定义的解决逻辑。

1.4. 命名空间

何为类的唯一性？

$\color{red}{对于任意一个类，都须要由加载它的类加载器和这个类自身一起确认其在 Java 虚拟机中的唯一性。}$ 每一个类加载器，都领有一个独立的类名称空间：$\color{red}{比拟两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。}$ 否则，即便这两个类源自同一个 Class 文件，被同一个虚拟机加载，只有加载他们的类加载器不同，那这两个类就必然不相等。

命名空间

• 每个类加载器都有本人的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成
• 在同一命名空间中，不会呈现类的残缺名字（包含类的包名）雷同的两个类
• 在不同的命名空间中，有可能会呈现类的残缺名字（包含类的包名）雷同的两个类

在大型利用中，咱们往往借助这一个性，来运行同一个类的不同版本。

1.5. 类加载机制的基本特征

双亲委派模型。但不是所有类加载都恪守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比方 JDK 外部的 ServiceProvider/ServiceLoader 机制，用户能够在规范 API 框架上，提供本人的实现，JDK 也须要提供些默认的参考实现。例如，Java 中 JNDI、JDBC、文件系统、Cipher 等很多方面，都是利用的这种机制，这种状况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器。

<mark> 可见性 </mark>，子类加载器能够拜访父加载器加载的类型，然而反过来是不容许的。不然，因为短少必要的隔离，咱们就没有方法利用类加载器去实现容器的逻辑。

<mark> 单一性 </mark>，因为父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中反复加载。然而留神，类加载器“街坊”间，同一类型依然能够被加载屡次，因为相互并不可见。

1.6. 类加载器之间的关系

Launcher 类外围代码

Launcher.ExtClassLoader var1;
try {var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {throw new InternalError("Could not create extension class loader", var10);
}

try {this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {throw new InternalError("Could not create application class loader", var9);
}

Thread.currentThread().setContextClassLoader(this.loader);

• ExtClassLoader 的 Parent 类是 null
• AppClassLoader 的 Parent 类是 ExtClassLoader
• 以后线程的 ClassLoader 是 AppClassLoader

$\color{red}{留神，这里的 Parent 类并不是 Java 语言意义上的继承关系，而是一种蕴含关系}$

<hr/>

2. 类的加载器分类

JVM 反对两种类型的类加载器，别离为疏导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。

从概念上来讲，自定义类加载器个别指的是程序中由开发人员自定义的一类类加载器，然而 Java 虚拟机标准却没有这么定义，而是将所有派生于抽象类 ClassLoader 的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分，在程序中咱们最常见的类加载器构造次要是如下状况：

• 除了顶层的启动类加载器外，其余的类加载器都该当有本人的“父类”加戟器。
• 不同类加载器看似是继承（Inheritance）关系，实际上是蕴含关系。在上层加载器中，蕴含着下层加载器的援用。

父类加载器和子类加载器的关系：

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);
    }
}

正是因为子类加载器中蕴含着父类加载器的援用，所以能够通过子类加载器的办法获取对应的父类加载器

留神：

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

2.1. 疏导类加载器

<mark> 启动类加载器（疏导类加载器，Bootstrap ClassLoader）</mark>

• 这个类加载应用 C /C++ 语言实现的，嵌套在 JVM 外部。
• 它用来加载 Java 的外围库（JAVAHOME/jre/lib/rt.jar 或 sun.boot.class.path 门路下的内容）。用于提供 JVM 本身须要的类。
• 并不继承自 java.lang.ClassLoader，没有父加载器。
• 出于平安思考，Bootstrap 启动类加载器只加载包名为 java、javax、sun 等结尾的类

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

  
  
  应用 -XX:+TraceClassLoading 参数失去。

启动类加载器应用 C ++ 编写的？Yes！

• C/C++：指针函数 & 函数指针、C++ 反对多继承、更加高效
• Java：由 C ++ 演变而来，（C++）–版，单继承

System.out.println("＊＊＊＊＊＊＊＊＊＊启动类加载器＊＊＊＊＊＊＊＊＊＊");
// 获取 BootstrapclassLoader 可能加载的 api 的门路
URL[] urLs = sun.misc.Launcher.getBootstrapcLassPath().getURLs();
for (URL element : urLs) {System.out.println(element.toExternalForm());
}
// 从下面的门路中随便抉择一个类，来看看他的类加载器是什么：疏导类加载器
ClassLoader classLoader = java.security.Provider.class.getClassLoader();
System.out.println(classLoader);

执行后果：

2.2. 扩大类加载器

<mark> 扩大类加载器（Extension ClassLoader）</mark>

• Java 语言编写，由 sun.misc.Launcher$ExtClassLoader 实现。
• 继承于 ClassLoader 类
• 父类加载器为启动类加载器

• 从 java.ext.dirs 零碎属性所指定的目录中加载类库，或从 JDK 的装置目录的 jre/lib/ext 子目录下加载类库。如果用户创立的 JAR 放在此目录下，也会主动由扩大类加载器加载。

System.out.println("＊＊＊＊＊＊＊＊＊＊＊扩大类加载器＊＊＊＊＊＊＊＊＊＊＊");
String extDirs =System.getProperty("java.ext.dirs");
for (String path :extDirs.split( regex:";")){System.out.println(path);
}

// 从下面的门路中随便抉择一个类，来看看他的类加载器是什么：扩大类加载器
lassLoader classLoader1 = sun.security.ec.CurveDB.class.getClassLoader();
System.out.print1n(classLoader1); //sun.misc. Launcher$ExtCLassLoader@1540e19d

执行后果：

2.3. 零碎类加载器

<mark> 应用程序类加载器（零碎类加载器，AppClassLoader）</mark>

• java 语言编写，由 sun.misc.Launcher$AppClassLoader 实现
• 继承于 ClassLoader 类
• 父类加载器为扩大类加载器
• 它负责加载环境变量 classpath 或零碎属性 java.class.path 指定门路下的类库
• $\color{red}{应用程序中的类加载器默认是零碎类加载器。}$
• 它是用户自定义类加载器的默认父加载器
• 通过 ClassLoader 的 getSystemClassLoader()办法能够获取到该类加载器

2.4. 用户自定义类加载器

<mark> 用户自定义类加载器 </mark>

• 在 Java 的日常利用程序开发中，类的加载简直是由上述 3 品种加载器相互配合执行的。在必要时，咱们还能够自定义类加载器，来定制类的加载形式。
• 体现 Java 语言弱小生命力和微小魅力的关键因素之一便是，Java 开发者能够自定义类加载器来实现类库的动静加载，加载源能够是本地的 JAR 包，也能够是网络上的近程资源。
• $\color{red}{通过类加载器能够实现十分绝妙的插件机制}$，这方面的理论利用案例举不胜举。例如，驰名的 OSGI 组件框架，再如 Eclipse 的插件机制。类加载器为应用程序提供了一种动静减少新性能的机制，这种机制毋庸从新打包公布应用程序就能实现。
• 同时，$\color{red}{自定义加载器可能实现利用隔离}$，例如 Tomcat，Spring 等中间件和组件框架都在外部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比 C /C++ 程序要好太多，想不批改 C /C++ 程序就能为其新增性能，简直是不可能的，仅仅一个兼容性便能阻挡住所有美妙的构想。
• 自定义类加载器通常须要继承于 ClassLoader。

<hr/>

3. 测试不同的类的加载器

每个 Class 对象都会蕴含一个定义它的 ClassLoader 的一个援用。
获取 ClassLoader 的路径

// 取得以后类的 ClassLoader
clazz.getClassLoader()
// 取得以后线程上下文的 ClassLoader
Thread.currentThread().getContextClassLoader()
// 取得零碎的 ClassLoader
ClassLoader.getSystemClassLoader()

阐明：

• 站在程序的角度看，疏导类加载器与另外两品种加载器（零碎类加载器和扩大类加载器）并不是同一个档次意义上的加
  载器，疏导类加载器是应用 C ++ 语言编写而成的，而另外两品种加载器则是应用 Java 语言编写而成的。因为疏导类加载
  器压根儿就不是一个 Java 类，因而在 Java 程序中只能打印出空值。
• 数组类的 Class 对象，不是由类加载器去创立的，而是在 Java 运行期 JVM 依据须要主动创立的。对于数组类的类加载器
  来说，是通过 Class.getClassLoader()返回的，与数组当中元素类型的类加载器是一样的；如果数组当中的元素类型
  是根本数据类型，数组类是没有类加载器的。

// 运行后果：null
String[] strArr = new String[6];
System.out.println(strArr.getClass().getClassLoader());

// 运行后果：sun．misc．Launcher＄AppCLassLoader@18b4aac2
ClassLoaderTest[] test=new ClassLoaderTest[1];
System.out.println(test.getClass().getClassLoader());

// 运行后果：null
int[]ints =new int[2];
System.out.println(ints.getClass().getClassLoader());

代码：

public class ClassLoaderTest1{public static void main(String[] args) {
        // 获取零碎该类加载器
        ClassLoader systemClassLoader=ClassLoader.getSystemCLassLoader();
        System.out.print1n(systemClassLoader);//sun.misc.Launcher$AppCLassLoader@18b4aac2
        // 获取扩大类加载器
        ClassLoader extClassLoader =systemClassLoader.getParent();
        System.out.println(extClassLoader);//sun.misc. Launcher$ExtCLassLoader@1540e19d
        // 试图获取疏导类加载器：失败
        ClassLoader bootstrapClassLoader =extClassLoader.getParent();
        System.out.print1n(bootstrapClassLoader);//null

        //##################################
        try{ClassLoader classLoader =Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader);
            // 自定义的类默认应用零碎类加载器
            ClassLoader classLoader1=Class.forName("com.atguigu.java.ClassLoaderTest1").getClassLoader();
            System.out.println(classLoader1);
            
            // 对于数组类型的加载：应用的类的加载器与数组元素的类的加载器雷同
            String[] arrstr = new String[10];
            System.out.println(arrstr.getClass().getClassLoader());//null：示意应用的是疏导类加载器
                
            ClassLoaderTest1[] arr1 =new ClassLoaderTest1[10];
            System.out.println(arr1.getClass().getClassLoader());//sun.misc. Launcher$AppcLassLoader@18b4aac2
            
            int[] arr2 = new int[10];
            System.out.println(arr2.getClass().getClassLoader());//null:
        } catch (ClassNotFoundException e) {e.printStackTrace();
        }
    }
}

<hr/>

4. ClassLoader 源码解析

ClassLoader 与现有类的关系：

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

4.1. ClassLoader 的次要办法

抽象类 ClassLoader 的次要办法：（外部没有形象办法）

public final ClassLoader getParent()

返回该类加载器的超类加载器

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

加载名称为 name 的类，返回后果为 java.lang.Class 类的实例。如果找不到类，则返回 ClassNotFoundException 异样。该办法中的逻辑就是双亲委派模式的实现。

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

查找二进制名称为 name 的类，返回后果为 java.lang.Class 类的实例。这是一个受爱护的办法，JVM 激励咱们重写此办法，须要自定义加载器遵循双亲委托机制，该办法会在查看完父类加载器之后被 loadClass()办法调用。

• 在 JDK1.2 之前，在自定义类加载时，总会去继承 ClassLoader 类并重写 loadClass 办法，从而实现自定义的类加载类。然而在 JDK1.2 之后已不再倡议用户去笼罩 loadClass()办法，而是倡议把自定义的类加载逻辑写在 findClass()办法中，从后面的剖析可知，findClass()办法是在 loadClass()办法中被调用的，当 loadClass()办法中父加载器加载失败后，则会调用本人的 findClass()办法来实现类加载，这样就能够保障自定义的类加载器也合乎双亲委托模式。
• 须要留神的是 ClassLoader 类中并没有实现 findClass()办法的具体代码逻辑，取而代之的是抛出 ClassNotFoundException 异样，同时应该晓得的是 findClass 办法通常是和 defineClass 办法一起应用的。$\color{red}{个别状况下，在自定义类加载器时，会间接笼罩 ClassLoader 的 findClass()办法并编写加载规定，获得要加载类的字节码后转换成流，而后调用 defineClass()办法生成类的 Class 对象。}$

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

依据给定的字节数组 b 转换为 Class 的实例，off 和 len 参数示意理论 Class 信息在 byte 数组中的地位和长度，其中 byte 数组 b 是 ClassLoader 从内部获取的。这是受爱护的办法，只有在自定义 ClassLoader 子类中能够应用。

• defineClass()办法是用来将 byte 字节流解析成 JVM 可能辨认的 Class 对象（ClassLoader 中已实现该办法逻辑），通过这个办法不仅可能通过 class 文件实例化 class 对象，也能够通过其余形式实例化 class 对象，如通过网络接管一个类的字节码，而后转换为 byte 字节流创立对应的 Class 对象。
• $\color{red}{defineClass()办法通常与 findClass()办法一起应用，个别状况下，在自定义类加载器时，会间接笼罩 ClassLoader 的 findClass()办法并编写加载规定，获得要加载类的字节码后转换成流，而后调用 defineClass()办法生成类的 Class 对象}$

简略举例：

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

protected final void resolveClass(Class<?> c)

链接指定的一个 Java 类。应用该办法能够应用类的 Class 对象创立实现的同时也被解析。后面咱们说链接阶段次要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号援用转换为间接援用。

protected final Class<?> findLoadedClass(String name)

查找名称为 name 的曾经被加载过的类，返回后果为 java.lang.Class 类的实例。这个办法是 final 办法，无奈被批改。

private final ClassLoader parent;

它也是一个 ClassLoader 的实例，这个字段所示意的 ClassLoader 也称为这个 ClassLoader 的双亲。在类加载的过程中，ClassLoader 可能会将某些申请交予本人的双亲解决。

4.2. SecureClassLoader 与 URLClassLoader

接着 SecureClassLoader 扩大了 ClassLoader，新增了几个与应用相干的代码源（对代码源的地位及其证书的验证）和权限定义类验证（次要指对 class 源码的拜访权限）的办法，个别咱们不会间接跟这个类打交道，更多是与它的子类 URLClassLoader 有所关联。

后面说过，ClassLoader 是一个抽象类，很多办法是空的没有实现，比方 findClass()、findResource()等。而 URLClassLoader 这个实现类为这些办法提供了具体的实现。并新增了 URLClassPath 类帮助获得 Class 字节码流等性能。$\color{red}{在编写自定义类加载器时，如果没有太过于简单的需要，能够间接继承 URLClassLoader 类}$，这样就能够防止本人去编写 findClass()办法及其获取字节码流的形式，使自定义类加载器编写更加简洁。

4.3. ExtClassLoader 与 AppClassLoader

理解完 URLClassLoader 后接着看看残余的两个类加载器，即拓展类加载器 ExtClassLoader 和零碎类加载器 AppClassLoader，这两个类都继承自 URLClassLoader，是 sun.misc.Launcher 的动态外部类。

sun.misc.Launcher 次要被零碎用于启动主应用程序，ExtClassLoader 和 AppClassLoader 都是由 sun.misc.Launcher 创立的，其类次要类构造如下：

咱们发现 ExtClassLoader 并没有重写 loadClass()办法，这足矣阐明其遵循双亲委派模式，而 AppClassLoader 重载了 loadClass()办法，但最终调用的还是父类 loadClass()办法，因而仍然恪守双亲委派模式。

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

Class.forName()

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

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

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

ClassLoader.loadClass()

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

• 该办法将 Class 文件加载到内存时，并不会执行类的初始化，直到这个类第一次应用时才进行初始化。该办法因为须要失去一个 ClassLoader 对象，所以能够依据须要指定应用哪个类加载器。

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

<hr/>

5. 双亲委派模型

5.1. 定义与实质

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

定义

如果一个类加载器在接到加载类的申请时，它首先不会本人尝试去加载这个类，而是把这个申请工作委托给父类加载器去实现，顺次递归，如果父类加载器能够实现类加载工作，就胜利返回。只有父类加载器无奈实现此加载工作时，才本人去加载。

实质

规定了类加载的程序是：疏导类加载器先加载，若加载不到，由扩大类加载器加载，若还加载不到，才会由零碎类加载器或自定义的类加载器进行加载。

5.2. 劣势与劣势

双亲委派机制劣势

• 防止类的反复加载，确保一个类的全局唯一性

  $\color{red}{Java 类随着它的类加载器一起具备了一种带有优先级的档次关系，通过这种层级关能够防止类的反复加载，当父亲曾经加载了该类时，就没有必要子 ClassLoader 再加载一次。}$

• 爱护程序平安，避免外围 API 被随便篡改

代码反对

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

（1）先在以后加载器的缓存中查找有无指标类，如果有，间接返回。

（2）判断以后加载器的父加载器是否为空，如果不为空，则调用 parent.loadClass(name，false)接口进行加载。

（3）反之，如果以后加载器的父类加载器为空，则调用 findBootstrapClassorNull(name)接口，让疏导类加载器进行加载。

（4）如果通过以上 3 条门路都没能胜利加载，则调用 findClass(name)接口进行加载。该接口最终会调用 java.lang.ClassLoader 接口的 defineClass 系列的 native 接口加载指标 Java 类。

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

举例

假如以后加载的是 java.lang.Object 这个类，很显然，该类属于 JDK 中外围得不能再外围的一个类，因而肯定只能由疏导类加载器进行加载。当]VM 筹备加载 javaJang.Object 时，JVM 默认会应用零碎类加载器去加载，依照下面 4 步加载的逻辑，在第 1 步从零碎类的缓存中必定查找不到该类，于是进入第 2 步。因为从零碎类加载器的父加载器是扩大类加载器，于是扩大类加载器持续从第 1 步开始反复。因为扩大类加载器的缓存中也肯定查找不到该类，因而进入第 2 步。扩大类的父加载器是 null，因而零碎调用 findClass（String），最终通过疏导类加载器进行加载。

思考

如果在自定义的类加载器中重写 java.lang.ClassLoader.loadClass(String)或 java.lang.ClassLoader.loadclass(String，boolean)办法，抹去其中的双亲委派机制，仅保留下面这 4 步中的第 l 步与第 4 步，那么是不是就可能加载外围类库了呢？

这也不行！因为 JDK 还为外围类库提供了一层爱护机制。不论是自定义的类加载器，还是零碎类加载器抑或扩大类加载器，最终都必须调用 java.lang.ClassLoader.defineclass(String，byte[]，int，int，ProtectionDomain)办法，而该办法会执行 preDefineClass()接口，该接口中提供了对 JDK 外围类库的爱护。

弊病

查看类是否加载的委托过程是单向的，这个形式尽管从构造上说比拟清晰，使各个 ClassLoader 的职责十分明确，然而同时会带来一个问题，即顶层的 ClassLoader 无法访问底层的 ClassLoader 所加载的类。

通常状况下，启动类加载器中的类为系统核心类，包含一些重要的零碎接口，而在利用类加载器中，为利用类。依照这种模式，利用类拜访零碎类天然是没有问题，然而零碎类拜访利用类就会呈现问题。比方在零碎类中提供了一个接口，该接口须要在利用类中得以实现，该接口还绑定一个工厂办法，用于创立该接口的实例，而接口和工厂办法都在启动类加载器中。这时，就会呈现该工厂办法无奈创立由利用类加载器加载的利用实例的问题。

论断

$\color{red}{因为 Java 虚拟机标准并没有明确要求类加载器的加载机制肯定要应用双亲委派模型，只是倡议采纳这种形式而已。}$ 比方在 Tomcat 中，类加载器所采纳的加载机制就和传统的双亲委派模型有肯定区别，当缺省的类加载器接管到一个类的加载工作时，首先会由它自行加载，当它加载失败时，才会将类的加载工作委派给它的超类加载器去执行，这同时也是 Serylet 标准举荐的一种做法。

5.3. 毁坏双亲委派机制

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

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

第一次毁坏双亲委派机制

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

因为双亲委派模型在 JDK 1.2 之后才被引入，然而类加载器的概念和抽象类 java.lang.ClassLoader 则在 Java 的第一个版本中就曾经存在，面对经存在的用户自定义类加载器的代码，Java 设计者们引入双亲委派模型时不得不做出一些斗争，$\color{red}{为了兼容这些已有代码，无奈再以技术手段防止 loadClass()被子类笼罩的可能性}$，只能在 JDK1.2 之后的 java.lang.ClassLoader 中增加一个新的 protected 办法 findClass()，并疏导用户编写的类加载逻辑时尽可能去重写这个办法，而不是在 loadClass()中编写代码。上节咱们曾经剖析过 loadClass()办法，双亲委派的具体逻辑就实现在这外面，依照 loadClass()办法的逻辑，如果父类加载失败，会主动调用本人的 findClass()办法来实现加载，这样既不影响用户依照本人的志愿去加载类，又能够保障新写进去的类加载器是合乎双亲委派规定的。

第二次毁坏双亲委派机制：线程上下文类加载器

双亲委派模型的第二次“被毁坏”是由这个模型本身的缺点导致的，双亲委派很好地解决了各个类加载器合作时根底类型的一致性问题（$\color{red}{越根底的类由越下层的加载器进行加载}$），根底类型之所以被称为“根底”，是因为它们总是作为被用户代码继承、调用的 API 存在，但程序设计往往没有相对不变的完满规定，如果有 $\color{red}{根底类型又要调用回用户的代码，那该怎么办呢？}$

这并非是不可能呈现的事件，一个典型的例子便是 JNDI 服务，JNDI 当初曾经是 Java 的规范服务，它的代码由启动类加载器来实现加载（在 JDK 1.3 时退出到 rt.jar 的），必定属于 Java 中很根底的类型了。但 JNDI 存在的目标就是对资源进行查找和集中管理，它须要调用由其余厂商实现并部署在应用程序的 ClassPath 下的 JNDI 服务提供者接口（Service Provider Interface，SPI）的代码，当初问题来了，$\color{red}{启动类加载器是绝不可能意识、加载这些代码的，那该怎么办？}$<u>（SPI：在 Java 平台中，通常把外围类 rt.jar 中提供内部服务、可由应用层自行实现的接口称为 SPI）</u>

为了解决这个窘境，Java 的设计团队只好引入了一个不太优雅的设计：$\color{red}{线程上下文类加载器（Thread Context ClassLoader）}$。这个类加载器能够通过 java.lang.Thread 类的 setContextClassLoader()办法进行设置，如果创立线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范畴内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文类加载器，程序就能够做一些“舞弊”的事件了。JNDI 服务应用这个线程上下文类加载器去加载所需的 SPI 服务代码，$\color{red}{这是一种父类加载器去申请子类加载器实现类加载的行为，这种行为实际上是买通了双亲委派模型的层次结构来逆向应用类加载器，曾经违反了双亲委派模型的一般性准则}$，但也是无可奈何的事件。，例如 JNDI、JDBC、JCE、JAXB 和 JBI 等。不过，当 SPI 的服务提供者多于一个的时候，代码就只能依据具体提供者的类型来硬编码判断，为了打消这种极不优雅的实现形式，在 JDK6 时，JDK 提供了 java.util.ServiceLoader 类，以 META-INF/services 中的配置信息，辅以责任链模式，这才算是给 SPI 的加载提供了一种绝对正当的解决方案。

默认上下文加载器就是利用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也能够拜访利用类加载器中的类。

第三次毁坏双亲委派机制

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

IBM 公司主导的 JSR-291(即 OSGiR4.2)实现模块化热部署的要害是它自定义的类加载器机制的实现，每一个程序模块 (osGi 中称为 Bundle) 都有一个本人的类加载器，当须要更换一个 Bundle 时，就把 Bund1e 连同类加载器一起换掉以实现代码的热替换。在 oSGi 环境下，类加载器不再双亲委派模型举荐的树状构造，而是进一步倒退为更加简单的网状结构。

当收到类加载申请时，OSGi 将依照上面的程序进行类搜寻：

1）$\color{red}{将以 java.* 结尾的类，委派给父类加载器加载。}$

2）$\color{red}{否则，将委派列表名单内的类，委派给父类加载器加载。}$

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

4）否则，查找以后 Bundle 的 ClassPath，应用本人的类加载器加载。

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

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

7）否则，类查找失败。

阐明：只有结尾两点依然合乎双亲委派模型的准则，其余的类查找都是在平级的类加载器中进行的

小结：这里，咱们应用了“被毁坏”这个词来形容上述不合乎双亲委派模型准则的行为，但这里“被毁坏”并不一定是带有贬义的。只有有明确的目标和充沛的理由，冲破旧有准则无疑是一种翻新。

正如：OSGi 中的类加载器的设计不合乎传统的双亲委派的类加载器架构，且业界对其为了实现热部署而带来的额定的高复杂度还存在不少争议，但对这方面有理解的技术人员根本还是能达成一个共识，认为OSGi 中对类加载器的使用是值得学习的，齐全弄懂了 OSGi 的实现，就算是把握了类加载器的精粹。

5.4. 热替换的实现

热替换是指在程序的运行过程中，不进行服务，只通过替换程序文件来批改程序的行为。$\color{red}{热替换的要害需要在于服务不能中断，批改必须立刻体现正在运行的零碎之中。}$ 基本上大部分脚本语言都是天生反对热替换的，比方：PHP，只有替换了 PHP 源文件，这种改变就会立刻失效，而无需重启 Web 服务器。

但对 Java 来说，热替换并非天生就反对，如果一个类曾经加载到零碎中，通过批改类文件，并无奈让零碎再来加载并重定义这个类。因而，在 Java 中实现这一性能的一个可行的办法就是灵活运用 ClassLoader。

留神：由不同 ClassLoader 加载的同名类属于不同的类型，不能互相转换和兼容。即两个不同的 ClassLoader 加载同一个类，在虚拟机外部，会认为这 2 个类是齐全不同的。

依据这个特点，能够用来模仿热替换的实现，基本思路如下图所示：

<hr/>

6. 沙箱平安机制

沙箱平安机制

• 保障程序平安
• 爱护 Java 原生的 JDK 代码

$\color{red}{Java 平安模型的外围就是 Java 沙箱（sandbox）}$。什么是沙箱？沙箱是一个限度程序运行的环境。

沙箱机制就是将 Java 代码 $\color{red}{限定在虚拟机（JVM）特定的运行范畴中，并且严格限度代码对本地系统资源拜访}$。通过这样的措施来保障对代码的无限隔离，避免对本地零碎造成毁坏。

沙箱次要限度系统资源拜访，那系统资源包含什么？CPU、内存、文件系统、网络。不同级别的沙箱对这些资源拜访的限度也能够不一样。

所有的 Java 程序运行都能够指定沙箱，能够定制安全策略。

6.1. JDK1.0 期间

在 Java 中将执行程序分成本地代码和近程代码两种，本地代码默认视为可信赖的，而近程代码则被看作是不受信的。对于授信的本地代码，能够拜访所有本地资源。而对于非授信的近程代码在晚期的 Java 实现中，平安依赖于 沙箱（Sandbox）机制。如下图所示 JDK1.0 平安模型

6.2. JDK1.1 期间

JDK1.0 中如此严格的平安机制也给程序的性能扩大带来阻碍，比方当用户心愿近程代码拜访本地零碎的文件时候，就无奈实现。

因而在后续的 Java1.1 版本中，针对平安机制做了改良，减少了 安全策略。容许用户指定代码对本地资源的拜访权限。

如下图所示 JDK1.1 平安模型

6.3. JDK1.2 期间

在 Java1.2 版本中，再次改良了平安机制，减少了 代码签名。不管本地代码或是近程代码，都会依照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限管制。如下图所示 JDK1.2 平安模型：

6.4. JDK1.6 期间

以后最新的平安机制实现，则引入了 域（Domain）的概念。

虚构机会把所有代码加载到不同的零碎域和利用域。$\color{red}{零碎域局部专门负责与要害资源进行交互}$，而各个利用域局部则通过零碎域的局部代理来对各种须要的资源进行拜访。虚拟机中不同的受爱护域（Protected Domain），对应不一样的权限（Permission）。存在于不同域中的类文件就具备了以后域的全副权限，如下图所示，最新的平安模型（jdk1.6）

<hr/>

7. 自定义类的加载器

7.1. 为什么要自定义类加载器？

• $\color{red}{隔离加载类}$

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

• $\color{red}{批改类加载的形式}$

  类的加载模型并非强制，除 Bootstrap 外，其余的加载并非肯定要引入，或者依据理论状况在某个工夫点进行按需进行动静加载

• $\color{red}{扩大加载源}$

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

• $\color{red}{避免源码透露}$

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

常见的场景

• 实现相似过程内隔离，类加载器实际上用作不同的命名空间，以提供相似容器、模块化的成果。例如，两个模块依赖于某个类库的不同版本，如果别离被不同的容器加载，就能够互不烦扰。这个方面的集大成者是 JavaEE 和 OSGI、JPMS 等框架。
• 利用须要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统。或者是须要本人操纵字节码，动静批改或者生成类型。

留神

在个别状况下，应用不同的类加载器去加载不同的功能模块，会进步应用程序的安全性。然而，如果波及 Java 类型转换，则加载器反而容易产生不美妙的事件。在做 Java 类型转换时，只有两个类型都是由同一个加载器所加载，能力进行类型转换，否则转换时会产生异样。

7.2. 实现形式

Java 提供了抽象类 java.lang.ClassLoader，所有用户自定义的类加载器都应该继承 ClassLoader 类。

在自定义 ClassLoader 的子类时候，咱们常见的会有两种做法:

• 形式一: 重写 loadClass()办法
• 形式二: 重写 findclass()办法

比照

• 这两种办法实质上差不多，毕竟 loadClass()也会调用 findClass()，然而从逻辑上讲咱们最好不要间接批改 loadClass()的外部逻辑。倡议的做法是只在 findClass()里重写自定义类的加载办法，依据参数指定类的名字，返回对应的 Class 对象的援用。
• loadclass()这个办法是实现双亲委派模型逻辑的中央，擅自批改这个办法会导致模型被毁坏，容易造成问题。$\color{red}{因而咱们最好是在双亲委派模型框架内进行小范畴的改变，不毁坏原有的稳固构造}$。同时，也防止了本人重写 loadClass()办法的过程中必须写双亲委托的反复代码，从代码的复用性来看，不间接批改这个办法始终是比拟好的抉择。
• 当编写好自定义类加载器后，便能够在程序中调用 loadClass()办法来实现类加载操作。

阐明

• 其父类加载器是零碎类加载器
• JVM 中的所有类加载都会应用 java.lang.ClassLoader.loadClass(String)接口 (自定义类加载器并重写 java.lang.ClassLoader.loadClass(String) 接口的除外)，连 JDK 的外围类库也不能例外。

<hr/>

8. Java9 新个性

为了保障兼容性，JDK9 没有从根本上扭转三层类加载器架构和双亲委派模型，但为了模块化零碎的顺利运行，依然产生了一些值得被留神的变动。

1. 扩大机制被移除，扩大类加载器因为向后兼容性的起因被保留，不过被重命名为平台类加载器 (platform class loader)。能够通过 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。

​ 如果有程序间接依赖了这种继承关系，或者依赖了 URLClassLoader 类的特定办法，那代码很可能会在 JDK9 及更高版本的 JDK 中解体。

1. 在 Java9 中，类加载器有了名称。该名称在构造方法中指定，能够通过 getName()办法来获取。平台类加载器的名称是 platform，利用类加载器的名称是 app。类加载器的名称在调试与类加载器相干的问题时会十分有用。
2. 启动类加载器当初是在 jvm 外部和 java 类库独特合作实现的类加载器（以前是 C ++ 实现），但为了与之前代码兼容，在获取启动类加载器的场景中依然会返回 null，而不会失去 BootClassLoader 实例。
3. 类加载的委派关系也产生了变动。当平台及应用程序类加载器收到类加载申请，在委派给父加载器加载前，要先判断该类是否可能归属到某一个零碎模块中，如果能够找到这样的归属关系，就要优先委派给负责那个模块的加载器实现加载。

代码：

public class ClassLoaderTest {public static void main(String[] args) {System.out.println(ClassLoaderTest.class.getClassLoader());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent().getParent());

        // 获取零碎类加载器
        System.out.println(ClassLoader.getSystemClassLoader());
        // 获取平台类加载器
        System.out.println(ClassLoader.getPlatformClassLoader());
        // 获取类的加载器的名称
        System.out.println(ClassLoaderTest.class.getClassLoader().getName());
    }
}