深入理解JVM——深入解析虚拟机类加载机制_虚拟机编译时需要类加载

1. 概述

Java虚拟机把描述类的数据从Class文件中加载到内存，并对数据进行校验、转换解析和初始化，最终形参了可以被虚拟机直接使用的Java类型，这个过程乘坐虚拟机打的类加载机制。与那些在编译时需要进行连接的语言不同，Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间才会完成的，这种策略会在提前编译时遇到额外的困难，也会让类加载时稍微增加一些性能开销，但是却为Java应用提供了极高的扩展性和灵活性，Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。

1. 类加载的时机

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载、验证、准备、解析、初始化、使用和卸载七个阶段，其中验证、准备、解析三个部分统称为连接。如图

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）。

关于在什么情况下需要开始类加载过程的第一个阶段“加载”，《Java虚拟机规范》中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

1. 遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有：

·使用new关键字实例化对象的时候。

·读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候。

·调用一个类型的静态方法的时候。

1. 使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化。

1. 当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

1. 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

1. 当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。

6）当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。对于这六种会触发类型进行初始化的场景，《Java虚拟机规范》中使用了一个非常强烈的限定语 ——“有且只有”，这六种场景中的行为称为对一个类型进行主动引用。除此之外，所有引用类型的方式都不会触发初始化，称为被动引用。下面举三个例子来说明何为被动引用，分别见代码清单7-1、代码清单7-2和代码清单7-3。

上述代码运行之后，只会输出“SuperClass init！”，而不会输出“SubClass init！”。对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。至于是否要触发子类的加载和验证阶段，在《Java虚拟机规范》中并未明确规定，所以这点取决于虚拟机的具体实现。对于HotSpot虚拟机来说，可通过-XX：+TraceClassLoading参数观察到此操作是会导致子类加载的。

为了节省版面，这段代码复用了代码清单7-1中的SuperClass，运行之后发现没有输出“SuperClass init！”，说明并没有触发org.fenixsoft.classloading.SuperClass的初始化阶段。但是这段代码里面触发了另一个名为“[Lorg.fenixsoft.classloading.SuperClass”的类的初始化阶段，对于用户代码来说，这并不是 一个合法的类型名称，它是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray触发。 这个类代表了一个元素类型为org.fenixsoft.classloading.SuperClass的一维数组，数组中应有的属性

和方法（用户可直接使用的只有被修饰为public的length属性和clone()方法）都实现在这个类里。Java语言中对数组的访问要比C/C++相对安全，很大程度上就是因为这个类包装了数组元素的访问[1]，而C/C++中则是直接翻译为对数组指针的移动。在Java语言里，当检查到发生数组越界时会抛出java.lang.ArrayIndexOutOfBoundsException异常，避免了直接造成非法内存访问。

上述代码运行之后，也没有输出“ConstClass init！”，这是因为虽然在Java源码中确实引用了ConstClass类的常量HELLOWORLD，但其实在编译阶段通过常量传播优化，已经将此常量的值“hello world”直接存储在NotInitialization类的常量池中，以后NotInitialization对常量ConstClass.HELLOWORLD的引用，实际都被转化为NotInitialization类对自身常量池的引用了。也就是说，实际上NotInitialization的Class文件之中并没有ConstClass类的符号引用入口，这两个类在编译成Class文件后就已不存在任何联系了

接口的加载过程与类加载过程稍有不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的，上面的代码都是用静态语句块“static{}”来输出初始化信息的，而接口中不能使用“static{}”语句块，但编译器仍然会为接口生成“<clinit>()”类构造器[2]，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是前面讲述的六种“有且仅有”需要触发初始化场景中的第三种：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

1. 类加载过程

加载

在加载阶段，Java虚拟机需要完成一下三件事情：

1. 通过一个类的全限定名来获取定义此类的二进制字节流
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3. 在内存中生成一个代表这个类的Java.lang Class对象，作为方法区这个类的各种数据的访问入口

相对于类加载过程的其他阶段，⾮数组类型的加载阶段(准确地说，是加载阶段中获取类的⼆进制字节流的动作)是开发⼈员可控性最强的阶段。加载阶段既可以使⽤Java虚拟机⾥内置的引导类加载器来完成，也可以由⽤户⾃定义的类加载器去完成，开发⼈员通过定义⾃⼰的类加载器去控制字节流的获取⽅式(重写⼀个类加载器的findClass()或loadClass()⽅法)，实现根据⾃⼰的想法来赋予应⽤程序获取运⾏代码的动态性。

对于数组类⽽⾔，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型(Element Type，指的是数组去掉所有维度的类型)最终还是要靠类加载器来完成加载，⼀个数组类(下⾯简称 为C)创建过程遵循以下规则:

如果数组的组件类型(Component Type，指的是数组去掉⼀个维度的类型，注意和前⾯的元素类型区分开来)是引⽤类型，那就递归采⽤本节中定义的加载过程去加载这个组件类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上(这点很重要，在7.4节会介绍，⼀个类型必须与类加载器⼀起确定唯⼀性)。

如果数组的组件类型不是引⽤类型(例如int[]数组的组件类型为int)，Java虚拟机将会把数组C标记为与引导类加载器关联。

数组类的可访问性与它的组件类型的可访问性⼀致，如果组件类型不是引⽤类型，它的数组类的可访问性将默认为public，可被所有的类和接⼝访问到。

1.⽂件格式验证

第⼀阶段要验证字节流是否符合Class⽂件格式的规范，并且能被当前版本的虚拟机处理。这⼀阶段可能包括下⾯这些验证点:

·是否以魔数0xCAFEBABE开头。

·主、次版本号是否在当前Java虚拟机接受范围之内。

·常量池的常量中是否有不被⽀持的常量类型(检查常量tag标志)。

·指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。

·CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。

·Class⽂件中各个部分及⽂件本身是否有被删除的或附加的其他信息。

实际上第⼀阶段的验证点还远不⽌这些，该验证阶段的主要⽬的是保证输⼊的字节流能正确地解析并存储于⽅法区之内，格式上符合描述⼀个Java类型信息的要求。这阶段的验证是基于⼆进制字节流进⾏的，只有通过了这个阶段的验证之后，这段字节流才被允许进⼊Java虚拟机内存的⽅法区中进⾏存储，所以后⾯的三个验证阶段全部是基于⽅法区的存储结构上进⾏的，不会再直接读取、操作字节流了。

2.元数据验证

第⼆阶段是对字节码描述的信息进⾏语义分析，以保证其描述的信息符合《Java语⾔规 范》的要求，这个阶段可能包括的验证点如下:

·这个类是否有⽗类(除了java.lang.Object之外，所有的类都应当有⽗类)。

·这个类的⽗类是否继承了不允许被继承的类(被final修饰的类)。

·如果这个类不是抽象类，是否实现了其⽗类或接⼝之中要求实现的所有⽅法。

·类中的字段、⽅法是否与⽗类产⽣⽭盾(例如覆盖了⽗类的final字段，或者出现不符合规则的⽅法重载，例如⽅法参数都⼀致，但返回值类型却不同等)。

第⼆阶段的主要⽬的是对类的元数据信息进⾏语义校验，保证不存在与《Java语⾔规范》定义相悖的元数据信息。

1. 字节码验证

第三阶段是整个验证过程中最复杂的⼀个阶段，主要⽬的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。在第⼆阶段对元数据信息中的数据类型校验完毕以后，这阶段就要对类的⽅法体(Class⽂件中的Code属性)进⾏校验分析，保证被校验类的⽅法在运⾏时不会做出危害虚拟机安全的⾏为，例如:

·保证任意时刻操作数栈的数据类型与指令代码序列都能配合⼯作，例如不会出现类似于“在操作栈放置了⼀个int类型的数据，使⽤时却按long类型来加载⼊本地变量表中”这样的情况。

·保证任何跳转指令都不会跳转到⽅法体以外的字节码指令上。

·保证⽅法体中的类型转换总是有效的，例如可以把⼀个⼦类对象赋值给⽗类数据类型，这是安全的，但是把⽗类对象赋值给⼦类数据类型，甚⾄把对象赋值给与它毫⽆继承关系、完全不相⼲的⼀个数据类型，则是危险和不合法的。

如果⼀个类型中有⽅法体的字节码没有通过字节码验证，那它肯定是有问题的;但如果⼀个⽅法体通过了字节码验证，也仍然不能保证它⼀定就是安全的。即使字节码验证阶段中进⾏了再⼤量、再严密的检查，也依然不能保证这⼀点。

4.符号引⽤验证

最后⼀个阶段的校验⾏为发⽣在虚拟机将符号引⽤转化为直接引⽤的时候，这个转化动作将在连接的第三阶段——解析阶段中发⽣。符号引⽤验证可以看作是对类⾃身以外(常量池中的各种符号引⽤)的各类信息进⾏匹配性校验，通俗来说就是，该类是否缺少或者被禁⽌访问它依赖的某些外部 类、⽅法、字段等资源。本阶段通常需要校验下列内容:

·符号引⽤中通过字符串描述的全限定名是否能找到对应的类。

·在指定类中是否存在符合⽅法的字段描述符及简单名称所描述的⽅法和字段。

·符号引⽤中的类、字段、⽅法的可访问性(private、protected、public、<package>)是否可被当前类访问。

符号引⽤验证的主要⽬的是确保解析⾏为能正常执⾏，如果⽆法通过符号引⽤验证，Java虚拟机将会抛出⼀个 java.lang.IncompatibleClassChangeError 的⼦类异常 ， 典型的如 : java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。验证阶段对于虚拟机的类加载机制来说，是⼀个⾮常重要的、但却不是必须要执⾏的阶段，因为验证阶段只有通过或者不通过的差别，只要通过了验证，其后就对程序运⾏期没有任何影响了。如果程序运⾏的全部代码(包括⾃⼰编写的、第三⽅包中的、从外部加载的、动态⽣成的等所有代码)都已经被反复使⽤和验证过，在⽣产环境的实施阶段就可以考虑使⽤-Xverify: none参数来关闭⼤部分的类验证措施，以缩短虚拟机类加载的时间。

准备:

准备阶段是正式为类中定义的变量(即静态变量，被static修饰的变量)分配内存并设置类变量初始值的阶段。从概念上讲，这些变量所使⽤的内存都应当在⽅法区中进⾏分配，但必须注意到⽅法区本身是⼀个逻辑上的区域，在JDK 7及之前，HotSpot使⽤永久代来实现⽅法区时，实现是完全符合这 种逻辑概念的; ⽽在JDK 8及之后，类变量则会随着Class对象⼀起存放在Java堆中，这时候“类变量在 ⽅法区”就完全是⼀种对逻辑概念的表述了。

关于准备阶段，还有两个容易产⽣混淆的概念笔者需要着重强调，⾸先是这时候进⾏内存分配的仅包括类变量，⽽不包括实例变量，实例变量将会在对象实例化时随着对象⼀起分配在Java堆中。其次是这⾥所说的初始值“通常情况”下是数据类型的零值，假设⼀个类变量的定义为:

public static int value = 123;

那变量value在准备阶段过后的初始值为0⽽不是123，因为这时尚未开始执⾏任何Java⽅法，⽽把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()⽅法之中，所以把value赋值为123的动作要到类的初始化阶段才会被执⾏。

上⾯提到在“通常情况”下初始值是零值，那⾔外之意是相对的会有某些“特殊情况”: 如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量值就会被初始化为 ConstantValue属性所指定的初始值，假设上⾯类变量value的定义修改为:

public static final int value = 123;

编译时Javac将会为value⽣成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。

解析:

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

·符号引⽤(Symbolic References): 符号引⽤以⼀组符号来描述所引⽤的⽬标，符号可以是任何形式的字⾯量，只要使⽤时能⽆歧义地定位到⽬标即可。符号引⽤与虚拟机实现的内存布局⽆关，引⽤的⽬标并不⼀定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同， 但是它们能接受的符号引⽤必须都是⼀致的，因为符号引⽤的字⾯量形式明确定义在《Java虚拟机规范》的Class⽂件格式中。

·直接引⽤(Direct References): 直接引⽤是可以直接指向⽬标的指针、相对偏移量或者是⼀个能间接定位到⽬标的句柄。直接引⽤是和虚拟机实现的内存布局直接相关的，同⼀个符号引⽤在不同虚拟机实例上翻译出来的直接引⽤⼀般不会相同。如果有了直接引⽤，那引⽤的⽬标必定已经在虚拟机的内存中存在。虚拟机实现可以根据需要来⾃⾏判断，到底是在类被加载器加载时就对常量池中的符号引⽤进⾏解析，还是等到⼀个符号引⽤将要被使⽤前才去解析它。类似地，对⽅法或者字段的访问，也会在解析阶段中对它们的可访问性(public、protected、private 、< package > ) 进⾏检查。对同⼀个符号引⽤进⾏多次解析请求是很常⻅的事情，除invokedynamic指令以外，虚拟机实现可以对第⼀次解析的结果进⾏缓存，譬如在运⾏时直接引⽤常量池中的记录，并把常量标识为已解析状态，从⽽避免解析动作重复进⾏。⽆论是否真正执⾏了多次解析动作，Java虚拟机都需要保证的是 同⼀个实体中，如果⼀个符号引⽤之前已经被成功解析过，那么后续的引⽤解析请求就应当⼀直能够成功;同样地，如果第⼀次解析失败了，其他指令对这个符号的解析请求也应该收到相同的异常，哪怕这个请求的符号在后来已成功加载进Java虚拟机内存之中。

不过对于invokedynamic指令，上⾯的规则就不成⽴了。当碰到某个前⾯已经由

invokedynamic指令触发过解析的符号引⽤时，并不意味着这个解析结果对于其他invokedynamic指令也同样⽣效。因为invokedynamic指令的⽬的本来就是⽤于动态语⾔⽀持，它对应的引⽤称为“动态调⽤点限定符(Dynamically-Computed Call Site Specifier)”，这⾥“动态”的含义是指必须等到程序实际运⾏到这条指令时，解析动作才能进⾏。相对地，其余可触发解析的指令都是“静态”的，可以在刚刚完成加载阶段，还没有开始执⾏代码时就提前进⾏解析。

解析动作主要针对类或接⼝、字段、类⽅法、接⼝⽅法、⽅法类型、⽅法句柄和调⽤点限定符这7类符号引⽤进⾏。

初始化：

类的初始化阶段是类加载过程的最后⼀个步骤，之前介绍的⼏个类加载的动作⾥，除了在加载阶段⽤户应⽤程序可以通过⾃定义类加载器的⽅式局部参与外，其余动作都完全由Java虚拟机来主导控制。直到初始化阶段，Java虚拟机才真正开始执⾏类中编写的Java程序代码，将主导权移交给应⽤程序。

进⾏准备阶段时，变量已经赋过⼀次系统要求的初始零值，⽽在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。我们也可以从另外⼀种更直接的形式来表达: 初始化阶段就是执⾏类构造器<clinit>()⽅法的过程。<clinit>()并不是程序员在Java代码中直接编写的⽅法，它是Javac编译器的⾃动⽣成物。

·<clinit>()⽅法是由编译器⾃动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产⽣的，编译器收集的顺序是由语句在源⽂件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前⾯的静态语句块可以赋值，但是不能访问。

<clinit>()⽅法与类的构造函数(即在虚拟机视⻆中的实例构造器<init>()⽅法)不同，它不需要显式地调⽤⽗类构造器，Java虚拟机会保证在⼦类的<clinit>()⽅法执⾏前，⽗类的<clinit>()⽅法已经执⾏完毕。因此在Java虚拟机中第⼀个被执⾏的<clinit>()⽅法的类型肯定是java.lang.Object。

·<clinit>()⽅法对于类或接⼝来说并不是必需的，如果⼀个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类⽣成<clinit>()⽅法。

接⼝中不能使⽤静态语句块，但仍然有变量初始化的赋值操作，因此接⼝与类⼀样都会⽣成 <clinit>()⽅法。但接⼝与类不同的是，执⾏接⼝的<clinit>()⽅法不需要先执⾏⽗接⼝的<clinit>()⽅法， 因为只有当⽗接⼝中定义的变量被使⽤时，⽗接⼝才会被初始化。此外，接⼝的实现类在初始化时也⼀样不会执⾏接⼝的<clinit>()⽅法。

同⼀个类加载器下，⼀个类型只会被初始化⼀次。

4. 类加载器

Java虚拟机设计团队有意把类加载阶段中的“通过⼀个类的全限定名来获取描述该类的⼆进制字节流”这个动作放到Java虚拟机外部去实现，以便让应⽤程序⾃⼰决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”(Class Loader)。

类与类加载器:

类加载器虽然只⽤于实现类的加载动作，但它在Java程序中起到的作⽤却远超类加载阶段。对于任意⼀个类，都必须由加载它的类加载器和这个类本身⼀起共同确⽴其在Java虚拟机中的唯⼀性，每⼀个类加载器，都拥有⼀个独⽴的类名称空间。这句话可以表达得更通俗⼀些: ⽐较两个类是否“相等”，只有在这两个类是由同⼀个类加载器加载的前提下才有意义，否则，即使这两个类来源于同⼀个Class⽂件，被同⼀个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

双亲委派模型:

站在Java虚拟机的⻆度来看，只存在两种不同的类加载器: ⼀种是启动类加载器(Bootstrap ClassLoader)，这个类加载器使⽤C++语⾔实现，是虚拟机⾃身的⼀部分;另外⼀种就是其他所有的类加载器，这些类加载器都由Java语⾔实现，独⽴存在于虚拟机外部，并且全都继承⾃抽象类 java.lang.ClassLoader。

站在Java开发⼈员的⻆度来看，类加载器就应当划分得更细致⼀些。⾃JDK 1.2以来，Java⼀直保持着三层类加载器、双亲委派的类加载架构。

·启动类加载器(Bootstrap Class Loader): 前⾯已经介绍过，这个类加载器负责加载存放在<JAVA_HOME>\lib⽬录，或者被-Xbootclasspath参数所指定的路径中存放的，⽽且是Java虚拟机能够识别的(按照⽂件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib⽬录中也不会被加载)类库加载到虚拟机的内存中。启动类加载器⽆法被Java程序直接引⽤，⽤户在编写⾃定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使⽤null代替即可。

·扩展类加载器(Extension Class Loader): 这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载

<JAVA_HOME>\lib\ext⽬录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。根据“扩展类加载器”这个名称，就可以推断出这是⼀种Java系统类库的扩展机制，JDK的开发团队允许⽤户将具有通⽤性的类库放置在ext⽬录⾥以扩展Java SE的功能，在JDK 9之后，这种扩展机制被模块化带来的天然的扩展能⼒所取代。由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使⽤扩展类加载器来加载Class⽂件。

·应⽤程序类加载器(Application Class Loader): 这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应⽤程序类加载器是ClassLoader类中的getSystemClassLoader()⽅法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载⽤户类路径(ClassPath)上所有的类库，开发者同样可以直接在代码中使⽤这个类加载器。如果应⽤程序中没有⾃定义过⾃⼰的类加载器，⼀般情况下这个就是程序中默认的类加载器。

图7-2中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型(Parents Delegation Model)”。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有⾃⼰的⽗类加载器。不过这⾥类加载器之间的⽗⼦关系⼀般不是以继承(Inherit ance)的关系来实现的，⽽是通常使⽤组合(Composition)关系来复⽤⽗加载器的代码。

双亲委派模型的⼯作过程是: 如果⼀个类加载器收到了类加载的请求，它⾸先不会⾃⼰去尝试加载这个类，⽽是把这个请求委派给⽗类加载器去完成，每⼀个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当⽗加载器反馈⾃⼰⽆法完成这个加载请求(它的搜索范围中没有找到所需的类)时，⼦加载器才会尝试⾃⼰去完成加载。

使⽤双亲委派模型来组织类加载器之间的关系，⼀个显⽽易⻅的好处就是Java中的类随着它的类加载器⼀起具备了⼀种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，⽆论哪⼀个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进⾏加载，因此Object类在程序的各种类加载器环境中都能够保证是同⼀个类。反之，如果没有使⽤双亲委派模型，都由各个类加载器⾃⾏去加载的话，如果⽤户⾃⼰也编写了⼀个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的⾏为也就⽆从保证，应⽤程序将会变得⼀⽚混乱。如果读者有兴趣的话，可以尝试去写⼀个与rt.jar类库中已有类重名的Java类，将会发现它可以正常编译，但永远⽆法被加载运⾏。

这段代码的逻辑清晰易懂: 先检查请求加载的类型是否已经被加载过，若没有则调⽤⽗加 载器的loadClass()⽅法，若⽗加载器为空则默认使⽤启动类加载器作为⽗加载器。假如⽗类加载器加载失败，抛出ClassNotFoundException异常的话，才调⽤⾃⼰的findClass()⽅法尝试进⾏加载。

破坏双亲委派模型:

双亲委派模型的第⼀次“被破坏”其实发⽣在双亲委派模型出现之前——即JDK 1.2⾯世以前的“远古”时代。由于双亲委派模型在JDK 1.2之后才被引⼊，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第⼀个版本中就已经存在，⾯对已经存在的⽤户⾃定义类加载器的代码，Java设计者们引⼊双亲委派模型时不得不做出⼀些妥协，为了兼容这些已有代码，⽆法再以技术⼿段避免loadClass()被⼦类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加⼀个新的protected⽅法findClass()，并引导⽤户编写的类加载逻辑时尽可能去重写这个⽅法，⽽不是在loadClass()中编写代码。上节我们已经分析过loadClass()⽅法，双亲委派的具体逻辑就实现在这⾥⾯，按照loadClass()⽅法的逻辑，如果⽗类加载失败，会⾃动调⽤⾃⼰的findClass()⽅法来完成加载，这样既不影响⽤户按照⾃⼰的意愿去加载类，⼜可以保证新写出来的类加载器是符合双亲委派规则的。

双亲委派模型的第⼆次“被破坏”是由这个模型⾃身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的⼀致性问题(越基础的类由越上层的加载器进⾏加载)，基础类型之所以被称为“基础”，是因为它们总是作为被⽤户代码继承、调⽤的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型⼜要调⽤回⽤户的代码，那该怎么办呢? 为了解决这个困境，Java的设计团队只好引⼊了⼀个不太优雅的设计: 线程上下⽂类加载器 (Thread ContextClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()⽅法进⾏设置，如果创建线程时还未设置，它将会从⽗线程中继承⼀个，如果在应⽤程序的全局范围内都没有设置过的话，那这个类加载器默认就是应⽤程序类加载器。JNDI服务使⽤这个线程上下⽂类加载器去加载所需的SPI服务代码，这是⼀种⽗类加载器去请求⼦类加载器完成类加载的⾏为，这种⾏为实际上是打通了双亲委派模型的层次结构来逆向使⽤类加载器，已经违背了双亲委派模型的⼀般性原则，但也是⽆可奈何的事情。Java中涉及SPI的加载基本上都采⽤这种⽅式来完成，例如JNDI、JDBC、JCE、 JAXB和JBI等。