Java类加载机制详解
本篇文章结合着【深入理解Java虚拟机】一书当中整理了本篇博客。
目录
-
- 一、前言
- 二、类加载的时机
-
- 2.1、类加载过程
- 2.2、什么时候类初始化？
- 2.3、被动引用不会初始化
- 三、类加载的过程
-
- 3.1、加载
- 3.2、验证
- 3.3、准备
- 3.4、解析
- 3.5、初始化
- 四、父类和子类初始化过程中的执行顺序
- 五、类加载器
-
- 4.1、类与类加载器
- 4.2、双亲委派模型
- 4.3、破坏双亲委派模型
- 六、Java模块化系统
一、前言
Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最 终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。
通俗点讲：new 一个对象的时候，首先得需要保证，new的这个对象的class已经加载到内存，疑问来了，为什么非得要加载到内存呢？我们在写程序的时候，new一个对象也没说非得加到内存当中啊，原因是JVM自带了类加载器这个功能，也就是在new的时候，会判断内存是否存在这个class类，如果有的话就不用加载，没有的话类加载器会自动加载，将class文件读到内存当中，所以我们不深层去了解，根本感知不到类加载器的作用。
在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成 的，这种策略让Java语言进行提前编译会面临额外的困难，也会让类加载时稍微增加一些性能开销， 但是却为Java应用提供了极高的扩展性和灵活性，Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
例如，编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类，从最基础的Applet、JSP到相对复杂的OSGi技术，都依赖着Java语言运行期类加载才 得以诞生。
二、类加载的时机
2.1、类加载过程
一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载 （Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化 （Initialization）、使用（Using）和卸载（Unloading）七个阶段，其中验证、准备、解析三个部分统称 为连接（Linking）。这七个阶段的发生顺序如下图所示。
加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按 照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始， 这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）。
2.2、什么时候类初始化？
关于在什么情况下需要开始类加载过程的第一个阶段“加载”，《Java虚拟机规范》中并没有进行 强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，《Java虚拟机规范》 则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之 前开始）：
-
遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始 化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有：
- 使用new关键字实例化对象的时候。
- 读取或设置一个类型的静态字段（
被final修饰、已在编译期把结果放入常量池的静态字段除外） 的时候。 - 调用一个类型的静态方法的时候。
-
使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需 要先触发其初始化。
-
当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
-
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先 初始化这个主类。
-
当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解 析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句 柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
-
当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有 这个接口的实现类发生了初始化，那该接口要在其之前被初始化。
这六种场景中的行为称为对一个类型进行主动引用。
2.3、被动引用不会初始化
除此之外，所有引用类型的方 式都不会触发初始化，称为被动引用。下面举三个例子来说明何为被动引用。
代码示例一：
package org.fenixsoft.classloading;
/**
* 被动使用类字段演示一：
* 通过子类引用父类的静态字段，不会导致子类初始化
*/
public class SuperClass {
static {
System.out.println("父类 init!");
}
public static int value = 123;
}
class SubClass extends SuperClass {
static {
System.out.println("子类 init!");
}
}
/**
* 非主动使用类字段演示
*/
class NotInitialization {
public static void main(String[] args) {
System.out.println(SubClass.value);
}
}
上述代码运行之后，只会输出“父类 init！”，而不会输出“子类 init！”。
得出结论：访问静态属性的时候，不管是通过子类还是父类来访问这个静态属性，只有静态属性所呆的类会被初始化。至于是否要触发子类的加载和验证阶段，在《Java虚拟机规 范》中并未明确规定。
代码示例二：
/**
* 被动使用类字段演示二：
* 通过数组定义来引用类，不会触发此类的初始化
*/
class NotInitialization {
public static void main(String[] args) {
SuperClass[] sca = new SuperClass[10];
}
}
为了节省版面，这段代码复用了代码示例一的SuperClass，运行之后发现没有输出“父类 init！”，说明并没有触发类org.fenixsoft.classloading.SuperClass的初始化阶段。
但是这段代码里面触发了 另一个名为“[Lorg.fenixsoft.classloading.SuperClass”的类的初始化阶段，对于用户代码来说，这并不是 一个合法的类型名称，它是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由 字节码指令newarray触发。
这个类代表了一个元素类型为org.fenixsoft.classloading.SuperClass的一维数组，数组中应有的属性 和方法（用户可直接使用的只有被修饰为public的length属性和clone()方法）都实现在这个类里。Java语 言中对数组的访问要比C/C++相对安全，很大程度上就是因为这个类包装了数组元素的访问。
代码示例三：
/**
* 被动使用类字段演示三：
* 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的 类的初始化
*/
public class ConstClass {
static {
System.out.println("ConstClass init!");
}
public static final String HELLOWORLD = "hello world";
}
/**
* 非主动使用类字段演示
*/
class NotInitialization {
public static void main(String[] args) {
System.out.println(ConstClass.HELLOWORLD);
}
}
上述代码运行之后，也没有输出“ConstClass init！”，原因是常量在编译阶段存入了常量池，已经彻底和类脱离了关系，也就是常量和类的关系 在编译成 Class文件后就已不存在任何联系了。常量已经不再属于这个类。
接口的加载过程与类加载过程稍有不同，针对接口需要做一些特殊说明：接口也有初始化过程， 这点与类是一致的，上面的代码都是用静态语句块“static{}”来输出初始化信息的，而接口中不能使 用“static{}”语句块，但编译器仍然会为接口生成“类构造器，用于初始化接口中所定义的 成员变量。接口与类真正有所区别的是前面讲述的六种“有且仅有”需要触发初始化场景中的第三种： 当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父 接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始 化（被default关键字修饰的接口方法这种情况除外）。
三、类加载的过程
接下来我们会详细了解Java虚拟机中类加载的全过程，即加载、验证、准备、解析和初始化这五 个阶段所执行的具体动作。
3.1、加载
“加载”（Loading）阶段是整个“类加载”（Class Loading）过程中的一个阶段，希望读者没有混淆 这两个看起来很相似的名词。在加载阶段，Java虚拟机需要完成以下三件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流。
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入 口。
“通过一个类的全限定名来获取定义此类的二进制字节流”这条规则，它并没有指明二 进制字节流必须得从某个Class文件中获取，确切地说是根本没有指明要从哪里获取、如何获取。许多举足轻重的Java技术都建立在这 一基础之上，例如：
- 从ZIP压缩包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
- 运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用 了ProxyGenerator.generateProxyClass()来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
- 由其他文件生成，典型场景是JSP应用，由JSP文件生成对应的Class文件。
- 可以从加密文件中获取，这是典型的防Class文件被反编译的保护措施，通过加载时解密Class文 件来保障程序运行逻辑不被窥探。
加载阶段既可以使用Java虚拟机里内置的引导类加 载器来完成，也可以由用户自定义的类加载器去完成，开发人员通过定义自己的类加载器去控制字节 流的获取方式（重写一个类加载器的findClass()或loadClass()方法），实现根据自己的想法来赋予应用 程序获取运行代码的动态性。
对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型最终还是要靠类加载器来完成加载，一个数组类（下面简称 为C）创建过程遵循以下规则：
- 如果数组的组件类型是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组C将被标 识在加载该组件类型的类加载器的类名称空间上。
- 如果数组的组件类型不是引用类型（例如int[]数组的组件类型为int），Java虚拟机将会把数组C 标记为与
引导类加载器关联。
加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段 尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的一部 分，这两个阶段的开始时间仍然保持着固定的先后顺序。
3.2、验证
验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚 拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。
编译器验证： Java语言本身是相对安全的编程语言（起码对于C/C++来说是相对安全的），将一个对象转型为它并未实现的类型、跳转到不存在的代码 行之类的事情，如果尝试这样去做了，编译器会毫不留情地抛出异常、拒绝编译。
字节码验证： 但前面也曾说过， Class文件并不一定只能由Java源码编译而来，Java代码无法做到的事情在字节码层面上都是可以实现的，至少 语义上是可以表达出来的。Java虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为 载入了有错误或有恶意企图的字节码流而导致整个系统受攻击甚至崩溃，所以验证字节码是Java虚拟 机保护自身的一项必要措施。
验证阶段的工作量在虚拟机的类加载过程中占了相当大 的比重。验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节 码验证和符号引用验证。
文件格式验证：该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符 合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的 验证之后，这段字节流才被允许进入Java虚拟机内存的方法区中进行存储，所以后面的三个验证阶段 全部是基于方法区的存储结构上进行的，不会再直接读取、操作字节流了。
元数据验证：这个阶段可能包括的验证点如下（内容比较多，只列了以下几点）：
- 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。
- 这个类的父类是否继承了不允许被继承的类（被final修饰的类）。
- 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
字节码验证：第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定 程序语义是合法的、符合逻辑的。
符号引用验证：主要作用是验证该类是否缺少或者被禁止访问它依赖的某些外部 类、方法、字段等资源。类、字段、方法的可访问性（private、protected、public、）是否可被当 前类访问。
如果 程序运行的全部代码（包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码）都 已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用
-Xverify:none参数来关闭大部分的 类验证措施，以缩短虚拟机类加载的时间。
3.3、准备
准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初 始值的阶段，从概念上讲，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区 本身是一个逻辑上的区域，在JDK 7及之前，HotSpot使用永久代来实现方法区时，实现是完全符合这 种逻辑概念的；而在JDK 8及之后，类变量则会随着Class对象一起存放在Java堆中。
关于准备阶段，还有两个容易产生混淆的概念笔者需要着重强调，首先是这时候进行内存分配的 仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其 次是这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：
public static int value = 123;
那变量value在准备阶段过后的初始值为0而不是123，因为这时尚未开始执行任何Java方法，而把 value赋值为123的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值 为123的动作要到类的初始化阶段才会被执行。下图列出了Java中所有基本数据类型的零值。
3.4、解析
解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程
-
符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可
-
直接引用（Direct References）：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄
符号引用与虚拟机实现的内存布局无关，直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。
如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这7类符号引用进行
符号引用要转换成直接引用才有效，这也说明直接引用的效率要比符号引用高。那为什么要用符号引用呢？这是因为类加载之前，javac会将源代码编译成.class文件，这个时候javac是不知道被编译的类中所引用的类、方法或者变量他们的引用地址在哪里，所以只能用符号引用来表示。
3.5、初始化
类的初始化阶段是类加载过程的最后一个步骤，除了在加载阶 段用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控 制。直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程 序。
进行准备阶段时，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通 过程序编码制定的主观计划去初始化类变量和其他资源。
初始化阶段就是执行类构造器。
编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问 到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访 问，如下所示。
由于父类的
public class Test {
static class Parent {
public static int A = 1;
static {
A = 2;
}
}
static class Sub extends Parent {
public static int B = A;
}
public static void main(String[] args) {
System.out.println(Sub.B);
}
}
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成 执行接口的， 因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也 一样不会执行接口的
Java虚拟机必须保证一个类的，如果多个线程同 时去初始化一个类，那么只会有其中一个线程去执行这个类的
public class Test {
static class DeadLoopClass {
static {
// 如果不加上这个if语句，编译器将提示“Initializer does not complete normally” 并拒绝编译
if (true) {
System.out.println(Thread.currentThread() + "init DeadLoopClass");
while (true) {
}
}
}
}
public static void main(String[] args) {
Runnable script = new Runnable() {
@Override
public void run() {
System.out.println(Thread.currentThread() + "start");
DeadLoopClass dlc = new DeadLoopClass();
System.out.println(Thread.currentThread() + " run over");
}
};
Thread thread1 = new Thread(script);
Thread thread2 = new Thread(script);
thread1.start();
thread2.start();
}
}
运行结果：
需要注意，其他线程虽然会被阻塞，但如果执行＜clinit＞()方法的那条线程退出
＜clinit＞()方法后，其他线程唤醒后则不会再次进入＜clinit＞()方法。同一个类加载器下，一个类型只会被初始化一 次。
四、父类和子类初始化过程中的执行顺序
代码示例：
public class InitDemo {
public static void main(String[] args) {
System.out.println("第一次实例化子类:");
new sub();
System.out.println("第二次实例化子类：");
new sub();
}
}
class Super{
static {
System.out.println("父类中的静态块");
}
{
System.out.println("父类中的非静态块");
}
Super(){
System.out.println("父类中的构造方法");
}
}
class sub extends Super{
static {
System.out.println("子类中的静态块");
}
{
System.out.println("子类中的非静态块");
}
sub(){
System.out.println("子类中的构造方法");
}
}
运行结果：
五、类加载器
Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节 流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动 作的代码被称为“类加载器”（Class Loader）。
4.1、类与类加载器
对于 任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，两个类来源于同一个 Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。
这里所指的“相等”，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance() 方法的返回结果，也包括了使用instanceof关键字做对象所属关系判定等各种情况。如果没有注意到类 加载器的影响，在某些情况下可能会产生具有迷惑性的结果，如下代码演示了不同的类加载器对 instanceof关键字运算的结果的影响。
代码示例：
package com.gzl.cn;
import java.io.IOException;
import java.io.InputStream;
public class ClassLoaderTest {
public static void main(String[] args) throws Exception {
ClassLoader myLoader = new ClassLoader() {
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
try {
String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream is = getClass().getResourceAsStream(fileName);
if (is == null) {
return super.loadClass(name);
}
byte[] b = new byte[is.available()];
is.read(b);
return defineClass(name, b, 0, b.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
}
}
};
Object obj = myLoader.loadClass("com.gzl.cn.ClassLoaderTest").newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof com.gzl.cn.ClassLoaderTest);
}
}
上面示例当中构造了一个简单的类加载器，尽管它极为简陋，但是对于这个演示来说已经足够。它可以加载与自己在同一路径下的Class文件，我们使用这个类加载器去加载了一个名 为“com.gzl.cn.ClassLoaderTest”的类，并实例化了这个类的对象。但在第二行的输出中却发现这个对象与类com.gzl.cn.ClassLoaderTest做所属 类型检查的时候返回了false。
这是因为Java虚拟机中同时存在了两个ClassLoaderTest类，一个是由虚拟 机的应用程序类加载器所加载的，另外一个是由我们自定义的类加载器加载的，虽然它们都来自同一 个Class文件，但在Java虚拟机中仍然是两个互相独立的类，做对象所属类型检查时的结果自然为 false。
注意：同一个类加载器下，一个类型只会被初始化一 次。
4.2、双亲委派模型
站在Java虚拟机的角度来看，只存在两种不同的类加载器：
- 一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；
- 另外一种就是由Java语言实现的类加载器，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。
站在Java开发人员的角度来看，类加载器就应当划分得更细致一些。自JDK 1.2以来，Java一直保 持着三层类加载器、双亲委派的类加载架构。
下图中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents Delegation Model）”。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用 组合（Composition）关系来复用父加载器的代码。
双亲委派模型的工作过程是：
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加 载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的 加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请 求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。
为什么使用双亲委派模型？
简单的来说：一个是安全性，另一个就是性能；（避免重复加载 和 避免核心类被篡改）
用户自定义一个java.lang.String类，该String类具有系统的String类一样的功能，只是在某个函数稍作修改。比如equals函数，这个函数经常使用，如果在这这个函数中，黑客加入一些“病毒代码”。并且通过自定义类加载器加入到JVM中。此时，如果没有双亲委派模型，那么JVM就可能误以为黑客自定义的java.lang.String类是系统的String类，导致“病毒代码”被执行。
而有了双亲委派模型，黑客自定义的java.lang.String类永远都不会被加载进内存。因为首先是最顶端的类加载器加载系统的java.lang.String类，最终自定义的类加载器无法加载java.lang.String类。
双亲委派模型对于保证Java程序的稳定运作极为重要，但它的实现却异常简单，用以实现双亲委 派的代码只有短短十余行，全部集中在java.lang.ClassLoader的loadClass()方法之中，代码如下：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先，检查请求的类是否已经被加载过了
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器抛出ClassNotFoundException
// 说明父类加载器无法完成加载请求，那就继续往下走
}
if (c == null) {
// 在父类加载器无法加载时
// 再调用本身的findClass方法来进行类加载
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;
}
}
启动类加载器（Bootstrap Class Loader）：引导类加载器，又叫启动类加载器。这个类加载器负责加载存放在 -Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够 识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。
扩展类加载器（Extension Class Loader）：
Java语言编写，由sun.misc.Launcher类的内部类ExtClassLoader类实现，派生于ClassLoader类，父加载器为引导类加载器。
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的jar包放在此目录下，也会自动由扩展类加载器加载。
应用程序类加载器（Application Class Loader）：
这个类加载器由 sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。
它负责加载用户类路径 （ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有 自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
4.3、破坏双亲委派模型
上文提到过双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的 类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java 模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。
这里所说的破坏指的是没有遵循自下而上的规则。也就是刚刚提到的双亲委派模型的工作过程。
第一次破坏：
在 jdk 1.2 之前，那时候还没有双亲委派模型，不过已经有了 ClassLoader 这个抽象类，所以已经有人继承这个抽象类，重写 loadClass 方法来实现用户自定义类加载器。
而在 1.2 的时候要引入双亲委派模型，为了向前兼容， loadClass 这个方法还得保留着使之得以重写，新搞了个 findClass 方法让用户去重写，并呼吁大家不要重写 loadClass 只要重写 findClass。
这就是第一次对双亲委派模型的破坏，因为双亲委派的逻辑在 loadClass 上，但是又允许重写 loadClass，重写了之后就可以破坏委派逻辑了。
第二次破坏：
第二次破坏指的是 JNDI、JDBC 之类的情况。
首先得知道什么是 SPI(Service Provider Interface)，它是面向拓展的，也就是说我定义了个规矩，就是 SPI ，具体如何实现由扩展者实现。
像我们比较熟的 JDBC 就是如此。
MySQL 有 MySQL 的 JDBC 实现，Oracle 有 Oracle 的 JDBC 实现，我 Java 不管你内部如何实现的，反正你们这些数据库厂商都得统一按我这个来，这样我们 Java 开发者才能容易的调用数据库操作，所以在 Java 核心包里面定义了这个 SPI。
而核心包里面的类都是由启动类加载器去加载的，但它的手只能摸到
而 JDBC 的实现类在我们用户定义的 classpath 中，只能由应用类加载器去加载，所以启动类加载器只能委托子类来加载数据库厂商们提供的具体实现，这就违反了自下而上的委托机制。
具体解决办法是搞了个线程上下文类加载器 （Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方 法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内 都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
如下图就是JDBC加载驱动当中用到的上下文类加载器。
其实这里说的打破双亲规则，就是说用来加载spi实现用的是线程中的加载器(其实就是AppclassLoader)，当加载spi实现类时就没有继续调用父类加载器了，因为它知道父类就是找不到才找它去加载的，说这里违反了双亲规则。
第三次破坏：
这次破坏是为了满足热部署的需求，不停机更新这对企业来说至关重要，毕竟停机是大事。
OSGI 就是利用自定义的类加载器机制来完成模块化热部署，而它实现的类加载机制就没有完全遵循自下而上的委托，有很多平级之间的类加载器查找，具体就不展开了，有兴趣可以自行研究一下。
六、Java模块化系统
在JDK 9中引入的Java模块化系统（Java Platform Module System，JPMS）是对Java技术的一次重 要升级，此前，如果类路径中缺失了运行时依赖的类型，那就只能等程序运行到发生该类型的加载、链接 时才会报出运行的异常。而在JDK 9以后，如果启用了模块化进行封装，模块就可以声明对其他模块 的显式依赖，这样Java虚拟机就能够在启动时验证应用程序开发阶段设定好的依赖关系在运行期是否 完备，如有缺失那就直接启动失败，从而避免了很大一部分由于类型依赖而引发的运行时异常。
JDK 9中 的public类型不再意味着程序的所有地方的代码都可以随意访问到它们，模块提供了更精细的可访问性 控制，必须明确声明其中哪一些public的类型可以被其他哪一些模块访问，这种访问控制也主要是在类 加载过程中完成的。
其次是是扩展类加载器（Extension Class Loader）被平台类加载器（Platform Class Loader）取代。由于咱们一时半会也不会用JDK9，更多具体的我就不整理了。