类的加载篇

类的加载过程（生命周期）

1. Loading（装载）阶段

类的装载

所谓装载，简而言之就是将Java类的宇节码文件加载到机器内存中，并在内存中构建出Java类的原型：类模板对象

装载完成的操作

装载阶段，简言之，查找并加载类的二进制数据，生成CIass的实例

在加载类时，Java虚拟机必须完成以下3件事情

通过类的全名，获取类的二进制数据流
解析类的二进制数据流为方法区内的数据结构（Java类模型）
创建 java.lang. Class 类的实例，表示该类型。作为方法区这个类的各种数据的访问入口

什么是类模板对象

所谓类模板对象，其实就是 Java 类在 JVM 内存中的一个快照，JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样JVN在运行期便能通过类模板而获取 Java 类中的任意信息，能够对 Java 类的成员变量进行遍历，也能进行Java方法的调用

反射的机制即基于这一基础，如果 JVM 没有将 Java 类的声明信息存储起来，则 JVM 在运行期也无法反射

类模型的位罝

加载的类在 JVM 中创建相应的类结构，类结构会存储在方法区 (JDK1.8之前：永久代：JDK1.8及之后：元空间）

二进制流的获取方式

对于类的二进制数据流，虚拟机可以通过多种途径产生或获得（只要所读取的字节码符合JVM规范即可）

虚拟机可能通过文件系统读入一个class后缀的文件（最常见）
读入jar、zip等归档数据包，提取类文件
事先存放在数据库中的类的二进制数据
使用类似于HTTP之类的协议通过网络进行加载
在运行时生成一段Class的二进制信息等

在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为一个java. lang.Class的实例，如果输入数据不是ClassFile的结构，则会抛出CIassFormatError

Class实例的位置

类将 .class 文件加载至元空问后，会在堆中创建一个Java.lang.Class对象，用来封装类位于方法区内的数据结构，该CIass对象是在加载类的过程中创建的，每个类都对应有一个CIass类型的对象

数组类的加载

创建数组类的情况稍微有些特殊，因为数组类本身并不是由类加载器负责创建，而是由 JVM 在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类加载器去创建

创建数组类（下述简称A）的过程：

如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型
JVM 使用指定的元素类型和数组维度来创建新的数组类
如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定，否则数组类的可访问性将被缺省定义为public

2. Linking（链接）阶段

验证

验证阶段确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

文件格式验证验证字节流是否符合 Class 文件格式的规范，并且能被当前版本的虚拟机处理，验证点如下：
- 是否以魔数 0XCAFEBABE 开头。
- 主次版本号是否在当前虚拟机处理范围内。
- 常量池是否有不被支持的常量类型。
- 指向常量的索引值是否指向了不存在的常量。
- CONSTANT_Utf8_info 型的常量是否有不符合 UTF8 编码的数据。
- ......
元数据验证对字节码描述信息进行语义分析，确保其符合 Java 语法规范。
字节码验证本阶段是验证过程中最复杂的一个阶段，是对方法体进行语义分析，保证方法在运行时不会出现危害虚拟机的事件。
符号引用验证本阶段发生在解析阶段，确保解析正常执行。

准备

准备阶段是正式为类变量（或称“静态成员变量”）分配内存并设置初始值的阶段，这些变量（不包括实例变量）所使用的内存都在方法区中进行分配。

初始值“通常情况下”是数据类型的零值（0, null...），假设一个类变量的定义为：

public static int value = 123;

那么变量 value 在准备阶段过后的初始值为 0 而不是 123，因为这时候尚未开始执行任何 Java 方法。

存在“特殊情况”：如果类字段的字段属性表中存在 ConstantValue 属性，那么在准备阶段 value 就会被初始化为 ConstantValue 属性所指定的值，假设上面类变量 value 的定义变为：

public static final int value = 123;

那么在准备阶段虚拟机会根据 ConstantValue 的设置将 value 赋值为 123。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程

3. Initialization（初始化）阶段

类初始化阶段是类加载过程的最后一步，是执行类构造器 <clinit>() 方法的过程

该方法仅能由Java编译器生成并由 JVM 调用，程序开发者无法自定义一个同名的方法，更无法直接在 Java 程序中调用该方法，虽然该方法也是由字节码指令所组成

是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static {} 块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的

<clinit>()：只有在给类的中的static的变量显式赋值或在静态代码块中赋值才会生成此方法
<init>()：一定会出现在C1ass的method表中

子类加载前是先加载父类吗

在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<cIinit>总是在子类<clinit>之前被调用，也就是说，父类的static 块优先级高于子类

口诀：由父及子，静态先行

哪些类不会生成`<clinit>()`方法？

一个类中并没有声明任何的类变量，也没有静态代码块时
一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时
一个类中包含 static final 修饰的基本数据类型的字段，这些类宇段初始化语句采用编译时常量表达式

clinit 会造成死锁吗

对于<clinit>()方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性

虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>())方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕

正是因为函数<clinit>())带锁线程安全的，因此，如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，引发死锁。并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息

如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了,那么，当需要使用这个类时虚拟机会直接返口给它己经准备好的信息

类的主动使用

Class只有在必须要首次使用的时候才会被装载，Java虚拟机不会无条件地装载 Class类型，Java虚拟机规定：一个类或接口在初次使用前，必须要进行初始化，这里指的“使用”是指主动使用

主动使用只有下列几种情况：（即：如果出现如下的情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备己经完成

当创建一个类的实例时，比如使用new关键宇，或者通过反射、克隆、反序列化
当调用类的静态方法时，即当使用了字节码 invokestatic 指令
当使用类、接口的静态字段时(final修饰特殊考虑），比如，使用getstatic或者
putstatic指令。
当使用java. lang.reflect包中的方法反射类的方法时。比如：Class.forName (“com.atguigu. java. Test")
当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化
如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类
当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类

类的被动使用

除了以上的情况属于主动使用，其他的情况均属于被动使用，被动使用不会引起类的初始化，也就是说，并不是在代码中出现的类，就一定会被加载或者初始化，如果不符合主动使用的条件，类就不会初始化
当访问一个静态宇段时，只有真正声明这个字段的类才会被初始化，当通过子类引用父类的静态变量，不会导致子类初始化
通过数组定义类引用，不会触发此类的初始化
引用常量不会触发此类或接口的初始化，因为常量在链接阶段就己经被显式赋值了
调用 ClassLoader 类的子 loadClass() 方法加载一个类，并不是对类的主动使用，不会导致类的初始化
被动的使用，意味着不需要执行初始化环节，意味着没有<clinit>()的调用

4. 类的 Using（使用）

类、类的加執器、类的实例之间的关系

在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader(方法，就能获得它的类加载器

由此可见，代表某个类的C1ass实例与其类的加载器之间为双向关联关系

一个类的实例总是引用代表这个类的Class对象，在 Object 类中定义了 getClass() 方法，这个方法返回代表对象所属类的 Class对象的引用，此外，所有的 Java 类都有一个静态属性class，它引用代表这个类的Class对象

5. 类的 Unloading（卸载）

何种情况类会被卸载

一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期，当Sample类被加载、链接和初始化后，它的生命周期就开始了，当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期

类卸载在实际生产中的情况

启动类加载器加载的类型在整个运行期间是不可能被卸载的 (jvm和jls规范）
被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到 unreachable 的可能性极小
被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虛拟机的垃圾收集功能才可以做到。可以预想，稍微复架点的应用场景中(比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能），被加载的类型在运行期问也是几乎不太可能被卸载的(至少卸载的时间是不确定的)

综合以上三点，一个己经加载的类型被卸载的几率很小至少被卸载的时间是不确定的，同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能

方法区的垃圾回收

方头区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型

Hotspot虛拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收

判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于 “不再被使用的类” 的条件就比较苛刻了，要同时满足三个条件：

该类所有的实例都己经被回收。也就是Java堆中不存在该类及其任何派生子类的实例
加载该类的类加载器己经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如osGi、Jsp的重加载等，否则通常是很难达成的
该类对应的java.1ang. Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收

类的加载器

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

ClassLoader 作用

ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader 负责通过各种方式将 Class 信息的二进制数据流读入 JVM 内部，转换为一个与目标类对应的 java.lang.Class 对象实例。然后交给 Java 虚拟机进行链接、初始化等操作

因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过 CIassLoader 去改变类的链接和初始化行为，至于它是否可以运行，则由 Execution Engine 决定

类的显式加载与隐式加载

显式加载：指的是在代码中通过调用C1assLoader加载class对象，如直接使用Class.forName(name)或者this.getclass().getClassLoader().loadClass()加载class对象

隐式加载：不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的cIass文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载到内存中

加载的类是唯一的吗

何为类的唯一性？

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等

类加载机制的基本特征

通常类加载机制有三个基本特征

双亲委派模型，但不是所有类加载都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供些默认的参考实现，例如Java 中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用的这种机制，这种情況就不会用双亲委派模型去加载，而是利用所谓的上下文加载器
可见性，子类加载器可以访问父加载器加载的类型，但是反过来是不允许的，不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑
单一性，由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载，但是注意，类加载器 “邻居”间，同一类型仍然可以被加载多次，因为互相并不可见

类的加载器分类与测试

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

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

子父类的加载器的关系

除了顶层的启动类加载器外，其余的类加载器都应当有自己的 “父类”加载器，不同类加载器看似是继承 (Inheritance）关系，实际上是包含关系，在下层加载器中包含着上层加载器的引用

加载器介绍

引导类加载器

又称启动类加载器(引导类加载器，Bootstrap ClassLoader)

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

它用来加载Java的核心库（JAVA HOME/jre/ 1ib/rt. jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类，并不继承自java.lang .ClassLoader，没有父加载器

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

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

扩展类加载器

扩展类加载器 (Extension ClassLoader)

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
继承于 ClassLoader 类
父类加载器为启动类加载器
从 java.ext.dirs 系统属性所指定的目录中加裁类库，或从JDK的安装目录的jre/1ib/ext子目录下加载类库，如果用户创建的DAR放在此目录下，也会自动由扩展类加载器加载

系统类加载器

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

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

用户自定义加载器

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

如何获取类加载器

每个Class对象都会包含一个定义它的ClassLoader的一个引用

获取ClassLoader的途径

获得当前类的ClassLoader：clazz.getClassLoader()
获得当前线程上下文的ClassLoader：Thread. currentThread().getContextClassLoader()
获得系统的ClassLoader：ClassLoader.getSystemClassLoader()

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

ClassLoader 源码剖析

ClassLoader与现有类加载器的关系

ClassLoader的主要方法

SecureClassLoader与URLCLassLoader

ExtClassLoader与AppClassLoader

Class.forName()与ClassLoader.loadClass()对比

自定义类加载器

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

隔离加载类

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

修改类加载的方式

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

扩展加载源

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

防止源码泄漏

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

常见的应用场景

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

注意：
一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性，但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情，在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常

相关机制

双亲委派机制

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

定义

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

本质

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

源码分析

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

先在当前加载器的级存中查找有无且标类，如果有，直接返回
判断当前加载器的父加载器是否为空，如果不为空，则调用 parent.loadClass (name,false) 接口进行加载
反之，如果当前加载器的父类加载器为空，则调用 findBootstrapClassorNull (name)接口，让引导类加载器进行加载
如果通过以上3条路径都没能成功加载，则调用 findClass(name)接口进行加载，该接口最终会调用 java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类

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

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

恩考

如果在自定义的类加载器中重写 java.lang.ClassLoader.loadClass(String) 或java.lang.ClassLoader.loadClass (String， boolean)方法，抹去其中的双亲委派机制，仅保留上面这4步中的第1步与第4步，那么是不是就能够加载核心头库了呢？这也不行！因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器抑或扩展类加载器，最终都必须调用 java.lang.ClassLoader.defineclass (String, byte[J, int, int,protectionDomain)方法，而该方法会执行preDefineClass()接口，该接口中提供了对JDK核心类库的保护

双亲委派优势

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

双亲委派弊端

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

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

结论

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

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

如何破坏双亲委派机制

双亲委派模型的第一次“被破坏〞其实发生在双亲委派模型出现之前一—即JDK 1.2面世以前的“远古”时代，由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义
类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些己有代码，无法再以技术手段避免loadclass(）被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的
类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的

双亲委派模型的第二次 “被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为 “基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在己经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt. jar的），肯定属于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和JBI等，不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.Serviceloader类，以META-INF/ services中的配罝信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案

双亲委派模型的第三次 “被破坏”是由于用户对程序动态性的追求而导致的，如：代码热替换(Hot Swap）、模块热部署 (Hot Deployment)等，IBM公司主导的JSR-291（即oSGi R4.2）实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（osGi中称为Bundle）都有一个自己的类加载器，当需要更换-个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换，在osGi环境下，类加载器不再是双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构

沙箱安全机制

JDK9中类加载结构的新变化

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

扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器（platform class loader），可以通过ClassLoader的新方法 getPlatformClassLoader() 来获取

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

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