jvm(7)-虚拟机类加载机制

【0】README

0.1）本文转自“深入理解jvm”，旨在学习  虚拟机类加载机制 的基础知识；

【1】概述

1）类加载机制：虚拟机把描述类的数据从Class 文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的类加载机制；

2）在java中： 类型的加载，链接和初始化过程都是在程序运行期间完成的；java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的；

3）看个荔枝：编写一个面向接口的应用程序，可以等到运行时再指定具体的实现类；用户可以通过java预定义的和自定义类加载器，让一个本地的应用程序可以在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分，这种组装应用程序的方式目前已广泛应用与 java 程序中了；

【2】类加载的时机

1）类的生命周期：类从被加载到虚拟机内存中开始，到卸载出内存位置，他的整个生命周期包括： 加载， 验证，准备，解析，初始化，使用和卸载7个阶段。其中验证，准备，解析3个部分统称为 链接，这7个阶段的发生顺序如下图所示：（干货——类的生命周期，共7个阶段）

对上图的分析（Analysis）：

• A1）加载，验证，准备，初始化，卸载这5个阶段的顺序是确定的；
• A2）解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持java的运行时绑定（也称动态绑定或晚期绑定）；

2）对于初始化阶段，虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行初始化（cases）：

• case1）遇到new， getstatic， putstatic, 或 invokestatic 这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化；生成这4条指令的最常见的java代码场景是：使用new关键字实例化对象的时候，读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候；
• case2）使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行初始化，则需要先触发其初始化；
• case3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化；
• case4）当虚拟机启动时，用户需要制定一个要执行的主类（包含main方法的那个类），虚拟机会先初始化这个主类；
• case5）当使用jdk1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic, REF_putStatic, REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化；

3）主动引用+被动引用

3.1）主动引用：对于这5种会触发类进行初始化的场景，虚拟机规范中使用了一个很强烈的限定语：有且只有， 这5种场景中的行为称为对一个类进行主动引用；

3.2）被动引用：除此之外， 所有引用类的方式都不会触发初始化，称为被动引用；

3.3）看个荔枝

• ex1）通过子类引用父类的静态字段，不会导致子类初始化： 

• public class SuperClass {//父类public static int value = 123;static {System.out.println("SuperClass init!");}}

  public class SubClass extends SuperClass {static {System.out.println("SubClass init!");}}

  public class NotInitialization {public static void main(String[] args) {System.out.println(SubClass.value);}/** * output:  * SuperClass init! * 123 * （通过子类引用父类的静态字段，不会导致子类初始化） */}

对于Sun HotSpot虚拟机来说，可通过 -XX:+TraceClassLoading 参数观察到此操作会导致子类的加载；

• ex2）无输出

运行之后发现并没有输出SuperClass init，说明并没有触发com.jvm.chapter7.Super Class的类的初始化，而触发了 Lcom.jvm.chapter7.SuperClass的类的初始化，对于用户代码来说，这并不是一个合法的类名称，它是由一个虚拟机自动生成的，继承自Object的子类，创建动作由字节码指令newarray 触发；

public class NotInitalization2 {public static void main(String[] args) {SuperClass[] sc_array = new SuperClass[10];}/** * output: nothing * （运行之后发现并没有输出SuperClass init，说明并没有触发com.jvm.chapter7.Super * Class的类的初始化，而触发了 Lcom.jvm.chapter7.SuperClass的类的初始化，对于用户 * 代码来说，这并不是一个合法的类名称，它是由一个虚拟机自动生成的，继承自Object的子类，创建动作由 * 字节码指令newarray 触发） */}

Lcom.jvm.chapter7.SuperClass 代表了类型为 com.jvm.chapter7.SuperClass 的一维数组。数组中应用的属性和方法都实现在这个类里。java中对数组的访问要比C或C++ 相对安全是因为这个类封装了数组元素的访问方法，而C或C++ 直接翻译为对数组指针的移动；

• ex3）无输出

• public class ConstClass {public static final String HELLOWORD = "hello world";static {System.out.println("ConstClass init");}}<strong></strong>

  public class NotInitalization3 {public static void main(String[] args) {System.out.println(ConstClass.HELLOWORD);}/** * output: hello world */}

• 对上图的分析（Analysis）
  • A1）没有输出“ConstClass init”的原因：虽然在java源码中引用了 ConstClass类中的常量HELLOWORLD， 但其实在编译阶段通过常量传播优化，已经将此常量的值“hello world”存储到了NotInitialization3 的常量池中，以后 NotInitialization3 对常量 ConstClass.HELLOWORLD 的引用实际都被转化为 NotInitialization 类对自身常量池的引用了。也就是说，实际上 NotInitialization3 的Class 文件中并没有 ConstClass类的符号引用入口，这两个类在编译成Class 之后就不存在任何联系了；

4）接口的加载与类加载的不同：

4.1）接口也有初始化过程：类中用静态语句块staitc 来输出初始化信息的，而接口中不能使用“static”语句块，但编译器仍然会为接口生成 “<clinit>()” 类构造器，用于初始化接口中定义的成员变量；

4.2）接口与类的真正区别是：当一个类在初始化时，要求其父类全部都已经初始化过了，但是在一个接口初始化时，并不要求其父接口全部不完成初始化，只有在真正使用到父接口的时候才会初始化；

【3】类加载过程（加载，到验证，到准备，到解析，到初始化）

【3.1】加载

1）加载是类加载过程的一个阶段，不要混淆加载和类加载的概念；

2）在加载阶段，虚拟机需要完成以下3件事情：

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

3）一个非数组类的加载阶段是开发人员可控性最强的，因为加载阶段

• 3.1）既可以使用系统提供的引导类加载器来完成；
• 3.2）也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（即重写一个类加载器的loadClass（）这个方法）；

4）对于数组类而言，情况有所不同，数组类本身不通过类加载器创建，它是由java虚拟机直接创建的 。数组类的创建规则遵循以下规则（rules）：

• rule1）如果数组的组件类型（Component Type， 指的是数组去掉一个维度的类型）是引用类型：那就递归采用本节中定义的加载过程去加载这个组件类型，数组C 将在加载该组件类型的类加载器的类名称空间上被标识；
• rule2）如果数组的组件类型不是引用类型（如int[] 数组）：java虚拟机将会把数组C 标记为与引导类加载器关联；
• rule3）数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为 public；

5）加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构； 然后在内存中实例化一个 java.lang.Class 类的对象，这个对象将作为程序访问方法区中的这些类型数据的外部接口；

6）加载阶段和连接阶段（如一部分字节码文件格式验证动作）的部分内容是交叉进行的；连接阶段包括（验证+准备+解析）

【3.2】验证（连接第一步）

1）目的：为了确保Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全 ；

2）要知道，Class文件 并不一定要求用java源码编译而来：可以使用任何途径产生，甚至包括用16进制编辑器直接编写来产生Class 文件；

3）验证阶段非常重要：它直接决定了java虚拟机是否能够承受恶意代码的攻击，从执行性能的角度上讲，验证阶段的工作量在虚拟机的类加载子系统中又占了相当大的一部分；

4）验证阶段大致上会完成下面4个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证；

• 4.1）文件格式验证：包括魔数，主次版本等信息，目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个 java类型信息的要求；所以后面的3个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流；
• 4.2）元数据验证：是否有父类，是否继承了不该继承的类，是否抽象类，子类中的字段和方法是否与父类产生矛盾等信息；
• 4.3）字节码验证：目的是通过数据流和控制流分析，确定程序语义是合法的，符合逻辑的；这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件；
  • 4.3.1）若方法体内的字节码没有通过字节码验证，则肯定有问题，但若通过了，也不一定证明其一定是安全的。这里涉及到离散数学中的一个很著名的问题“halting problem”： 通过程序去校验程序逻辑无法做到绝对正确的——不能通过程序准确地检查出程序是否能在有限的时间内结束运行；（干货——离散数学中的一个很著名的问题“halting problem”）
  • 4.3.2）在jdk1.6 之后的javac编译器和java虚拟机中进行了优化：给方法体的Code属性的属性表中增加了一项名为 “StackMapTable”的属性，这项属性描述了方法体中所有的基本块开始时本地变量表和操作栈应用的状态，在字节码验证期间，就不需要根据程序推导这些状态的合法性，只需要检查 StackMapTable 属性中的记录是否合法即可；从而节省时间；
  • 4.3.3）problem+solution：
  • problem）理论上 StackMapTable 属性也存在错误或被篡改的可能，所以是否有可能在恶意篡改了Code属性的同时，也生成相应的StackMapTable 属性来骗过虚拟机的类型校验则是虚拟机设计者值得思考的问题；
  • solution）jdk1.6 的HotSpot虚拟机提供了 -XX: -UseSplitVerifier　选项来关闭这项优化，或者使用参数 -XX: +FailOverToOldVerifier 要求在类型校验失败时再退回到旧的类型推导方式进行校验；
• 4.4）符号引用验证： 该验证发生在虚拟机将符号引用转化为 直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证看做是对类自身以外的信息进行匹配性校验；校验内容，如引用的全限定名是否能找到对应的类，符号引用中的类，字段，方法的访问性是否合法等信息；
  • 4.4.1）目的：是确保解析动作能正常进行，如果无法通过验证，将抛出 java.lang.IncompatibleClassChangeError 异常的子类；
  • 4.4.2）如果所运行的全部代码都已经被反复使用和验证过，那么在实施阶段就可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间；

【3.3】准备

1）准备阶段所做的工作：是正式为类变量分配内存并设置其初始值， 这些变量所使用的内存都将在方法区中进行分配；

Attention）

• A1）准备阶段进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化的时候随着对象一起分配在 java堆中；
• A2）通常情况下：这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：public static int value=123；那变量value 在准备阶段过后的初始化为0而不是123，因为这时候尚未开始执行任何 java方法，而把value赋值为 123 的putstatic 指令是程序被编译后，存放于类构造器<clinit>方法之中，所以把 value赋值为 123的动作将在初始化阶段才会执行；
• A3）特殊情况下：如果类字段的字段属性表中存在 ConstantValue 属性，那在准备阶段变量 value 就会被初始化为 ConstantValue属性所指定的值，假设上面类变量的value的定义变为： public static final int value = 123；编译时javac 将会为value生成 ConstantValue属性，在准备阶段虚拟机就根据 ConstantValue 的设置将 value赋值为 123；（干货——被final修饰的字段就是特殊情况）

2）java中所有基本数据类型的零值，如下所示：

【3.4】解析

1）解析阶段的工作内容：将虚拟机将常量池内的符号引用替换为 直接引用的过程；符号引用在Class文件中以 CONTANT_Class_info, CONSTNAT_Fieldref_info， CONSTNAT_Methodref_info 等类型的常量出现；

2）符号引用与直接引用的关联

• 2.1）符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可；
• 2.2）直接引用：直接引用可以是 直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。
• 2.3）符号引用和直接引用的区别：同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同，如果有了直接引用，那引用的目标必定已经在内存中存在了；

3）虚拟机规范中要求了在执行 anewarray, checkcast, getfield, getstatic, instanceof, invokebynamic, invokeinterface, invokespecial, invokestatic, invokevirtual, ldc, ldc_w, multinaewarray, new, putfield, putstatic 这16个用于操作 符号引用的字节码指令前，先对他们所使用的符号引用进行解析；

4）除开 invokeddynamic指令：对同一个符号引用进行多次解析请求是很常见的事情，虚拟机实现可以对第一次解析的结果进行缓存，从而避免解析动作重复进行。虚拟机需要保证在同一个实体中， 如果一个符号引用前已经被成功解析过，那么后续的引用解析请求就应当一直成功；

5）对于 invokeddynamic指令：该指令的目的就是用于动态语言支持，它所对应的引用称为“动态调用点限定符”，这里动态的含义就是必须等到程序实际运行到这条指令的时候，解析动作才能进行；相对的，其余可触发解析的指令都是静态的，可以在刚刚完成完成加载阶段，还没有开始执行代码时就进行解析；

6）解析动作主要针对：类，接口，类方法，接口方法，方法类型，方法句柄，调用点限定符7类符号引用进行，分别对应于常量池的CONSTANT_Class_info,  CONSTANT_Fieldref_info,  CONSTANT_Methodref_info,  CONSTANT_InterfaceMethodref_info,  CONSTANT_MethodType_info,  CONSTANT_MethodHandle_info,  CONSTANT_InvokeDynamic_info 7 种常量类型。下面讲解前4种引用的解析过程：

6.1）类或接口的解析：假设当前代码所处的类为D，若要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那虚拟机完成解析的过程需要以下3个steps：

• step1）如果C 不是一个数组类型：那虚拟机将会把代表N 的全限定名传递给D的类加载器去加载这个类C；
• step2）如果C是一个数组类型：并且数组的元素类型为对象，也就是N 的描述符会是类似 “[Ljava/lang/Integer” 的形式，那将会按照第1点的规则加载数组元素类型；
• step3）若上面的步骤没有出现任何异常，那么C 在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成前还要进行符号引用验证，确认D是否具备对C 的访问权限；

6.2）字段解析

1）要解析一个未被解析过的字段符号引用，首先将会对字段表内 class_index 项中索引的 CONSANT_Class_info 符号引用进行解析，也就是字段所属的类或接口的符号引用；
2）若解析成功，那将这个字段所属的类或接口用C表示，虚拟机规范要求按照如下steps 对C 进行后续字段的搜索：

• step1）如果C 本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束；
• step2）否则如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口；如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束；
• step3）否则，如果C不是 java.lang.Object 的话，将会按照继承关系从下往上递归搜索其父类；如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束；
• step4）否则，查找失败，抛出 java.lang.NoSuchFieldError 异常；

3）如果查找过程中返回了引用，将会对这个字段进行权限验证，如果发现不具备对这个字段的访问权限，将抛出 java.lang.IllegalAccessError 异常；

4）对于同名字段，编译器拒绝编译：

public class FieldResolution {interface Interface0 {int A = 0;}interface Interface1 extends Interface0 {int A = 1;}interface Interface2 {int A = 2;}static class Parent implements Interface1 {public static int A = 3;}static class Sub extends Parent implements Interface2 {public static int A = 4;/** * 如果注释了Sub类中的 public static int A = 4; 接口与父类同时存在字段A，那编译器 * 将提示 “the field Sub.A is ambiguous”，并且拒绝编译  */}public static void main(String[] args) {System.out.println(Sub.A); // output: 4}}

6.3）类方法解析

6.3.1）类方法解析的第一个步骤与字段解析一样，也需要先解析出类方法表的class_index 项中索引的方法所属的类或接口的符号引用，如果解析成功，我们依然用C表示这个 类，接下来虚拟机将会按照如下steps 进行后续的类方法搜索：

• step1）类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现 class_index 索引的C 是个接口，那就直接抛出 java.lang.IncompatibleClassChangeError 异常；
• step2）如果通过了第1步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束；
• step3）否则，在其父类中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束；
• step4）否则，在类C实现的接口列表以及它们的父接口中查找是否有简单名称和描述符都与目标相匹配的方法，如果存在匹配的方法，说明类C 是一个抽象类，这是查找结束，抛出 AbstractMethodError异常；
• step5）否则，宣告方法查找失败，抛出 java.lang.NoSuchMethodError；
• 最后）查找成功后，还要进行权限验证，如果权限不匹配，将抛出 java.lang.IllegalAccessError 异常；

6.4）接口方法解析

6.4.1）接口方法也需要先解析class_index 项中索引的方法所属的类或接口的符号引用，如果解析成功，我们依然用C表示这个 类，接下来虚拟机将会按照如下steps 进行后续的类方法搜索：

• step1）如果在接口方法表中发现class_index 中的索引C是个类而不是接口，抛出 java.lang.IncompatibleClassChangeError 异常；
• step2）否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束；
• step3）否则，在接口C的父接口中递归查找，直到 java.lang.Object类为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束；
• step4）否则，查找失败，抛出  java.lang.NoSuchMethodError 异常；

2）由于接口方法默认都是 public，所以不存在访问权限问题；

【3.5】初始化（类加载过程的最后一步）

0）前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的java程序代码（或字节码）；

1）类构造器<clinit>方法执行过程： 

1.1）类构造器方法<clinit>方法：是由 编译器自动收集类中的所有类变量的赋值动作和静态语句块（static块）中的语句合并产生的，编译器收集顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问；

public class Test {static {i = 0;// System.out.println(i);// 编译器报错}static int i = 1;// 静态语句块中只能访问到定义在静态语句块之前的变量，// 定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问}

1.2）类构造器<clinit>方法与类的构造函数不同：它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>方法执行之前，父类的 <clinit>方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>方法的类肯定是 java.lang.Object；

1.3）由于父类的<clinit>（） 方法先执行：也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作；（如下荔枝中，字段B的值会是2而不是1）

public class ExecuteOrderTest {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);// output:2}}

1.4）<clinit>方法对于类或接口来说并不是必须的：如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成 <clinit> 方法；

1.5）接口中不能使用静态语句块，但仍然有变量初始化的赋值操作：因此接口与类一样都会生成 <clinit>() 方法。但接口与类不同的是，执行接口的<clinit>（） 方法不需要先执行父接口的<clinit>（） 方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也不会执行接口的 <clinit>接口；

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

看个荔枝）如果在一个类的<clinit> 方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中这种阻塞往往是很隐蔽的：

public class DeadLoopClass {static {if(true) {System.out.println(Thread.currentThread() + "init DeadLoopClass");while(true) {}}}public static void main(String[] args) {Runnable runnable = new Runnable() {@Overridepublic void run() {System.out.println(Thread.currentThread() + " start");DeadLoopClass dlc = new DeadLoopClass();System.out.println(Thread.currentThread() + "run over");}};Thread thread1 = new Thread(runnable);Thread thread2 = new Thread(runnable);thread1.start();thread2.start();}}

【4】 类加载器

1）类加载器定义：虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己决定如何取获取所需要的类。实现这个动作的代码模块称为 类加载器；

【4.1】 类与类加载器

1）每一个类加载器，都拥有一个独立的类名称空间。即比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等；（干货——这里所说的相等，包括代表类的Class对象的equals（）方法， isAssignableFrom()方法， isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。）

看个荔枝）演示了不同类加载器对instanceof 关键字运算的结果的影响

public class ClassLoaderTest {public static void main(String[] args) throws Exception {ClassLoader loader = new ClassLoader() { // 自定义类加载器@Overridepublic 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 (Exception e) {throw new ClassNotFoundException(name);}} };Object obj = loader.loadClass("com.jvm.chapter7.ClassLoaderTest").newInstance();System.out.println(obj.getClass());System.out.println(obj instanceof com.jvm.chapter7.ClassLoaderTest);/** * outpub: * class com.jvm.chapter7.ClassLoaderTest * false */}}

对输出结果false的分析（Analysis）：

• A1）因为虚拟机中存在两个ClassLoaderTest类，一个是由系统应用程序类加载器加载的；另外一个是由我们自定义的类加载器加载的，虽然都来自同一个Class文件，但依然是 两个独立的类，做对象所属类型检查时结果自然为 false；

【4.2】双亲委派模型

1）java虚拟机的角度讲，只存在两种不同的类加载器：

1.1）一种是启动类加载器（Bootstrap ClassLoader）：这个类加载器使用C++ 语言实现；

1.2）一种是所有其他的类加载器：这些类加载器都由 java语言实现，独立于虚拟机外部，并且都继承自抽象类 java.lang.ClassLoader；

2）从java开放人员角度看，绝大部分java程序都会使用到以下3种系统提供的类加载器：

2.1）启动类加载器：这个类加载器将存放在 <java_home>/lib 目录中的，或者被 -Xbootclasspath 参数所指定的路径中的，并且使虚拟机识别的类库加载到虚拟机内存中；启动类加载器无法被java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用 null代替即可；

看个荔枝） 展示了 java.lang.ClassLoader.getClassLoder() 方法的代码片段

2.2）扩展类加载器：这个加载器由 sun.misc.Launcher$ExtClassLoader 实现，它负责加载 <java_home>/lib/ext 目录中的，或者被 java.ext.dirs 系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器；

2.3）应用程序类加载器（系统类加载器）：这个类加载器由sun.misc.Launcher$AppClassLoader 实现。由于这个类加载器是ClassLoader 中的getSystemClassLoader() 方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般case下 这个就是程序中默认的类加载器；

3）我们的应用程序都是由这3种类加载器相互配合进行加载的，如果有必要，还可以加入自定义的类加载器。类加载器间的关系如下所示：

对上图的分析（Analysis）：

• A1）上图中的类加载器间的层次关系，称为类加载器的双亲委派模型；（干货——双亲委派模式定义）
• A2）双亲委派模式：要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器间的父子关系一般不会以继承的关系来实现，而是使用 组合关系来复用父加载器的代码；

4）双亲委派模型的工作过程是： 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每个层次的类加载器都是如此，因此所有的加载请求最终都应该传送带到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载；

5）双亲委派模式来组织类加载器的关系，有一个好处： java 随着它的类加载器一起具备了一种带有优先级的层次关系。（干货——双亲委派模式来组织类加载器的关系，有一个好处）

5.1）看个荔枝：如java.lang.Object， 它存放在 rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个java.lang.Object 的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为也就无法保证了，应用程序也将会变得一片混乱；

5.2） 双亲委派模型的代码实现： 实现双亲委派模型的代码都集中在 java.lang.ClassLoader 的 loadClass() 方法中，如下面代码所示： 先检查是否已经被加载过了， 若没有加载则调用父加载器的 loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出 ClassNotFoundException 异常后，再调用自己的 findClass() 方法进行加载；

【4.3】破坏双亲委派模型

1）双亲委派模型主要出现过3次较大规模的被破坏情况：

case1）第一次被破坏：发生在双亲委派模型出现之前——即jdk1.2 发布之前。jdk1.2之后，不提倡用户再去覆盖 loadClass() 方法， 而应当把自己的类加载逻辑写到findClass（）方法中，在loadClass（）方法的逻辑如果父类加载失败，则会调用自己的findClass（） 方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派规则的；

case2）第二次被破坏：这次破坏是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的统一问题。

problem+solution）

problem）看个荔枝问题：JNDI现在已经是java 的标准服务，它的代码由启动类加载器去加载（在jdk1.3中放进去的rt.jar），但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的 ClassPath 下的JNDI 接口提供者（SPI=service provider interface）的代码，但启动类加载器不可能“认识”这些代码啊！那该怎么办？

solution）为了解决这个问题： java设计团队引入了线程上下文类加载器。线程上下文类加载器可以通过 java.lang.Thread 类的setContextClassLoader() 方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是 应用程序类加载器；JNDI范围使用这个线程上下文类加载器 去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作。（干货——引入了线程上下文类加载器）

case3）第三次被破坏：是由于对程序动态性的追求而导致的，这里所说的动态性指的是当前一些非常热门的名词：代码热替换，模块热部署等，说白了就是希望应用程序能像我们的计算机外设那样，接上鼠标，不用重启机器就可以立即使用；（干货——引入程序动态性）

补充）（干货——引入OSGi）

1）Sun 公司提出的JSR-294， JSR-277规范在于 JCP 组织的模块化规范之争中落败给 JSR-291（即OSGI R4.2），虽然Sun 不甘失去 java模块化的主导权，独立在发展Jigsaw项目，但目前 OSGi 已经成为 业界事实上的java 模块化标准，而OSGi 实现模块化热部署的关键则是它自定义的类加载器机制的实现。每个程序模块化（OSGI中称为 Bundle）都有一个自己的类加载器，当需要更换一个 Bundle时，就把 Bundle连同类加载器一起换掉以实现代码的热替换；

2）在OSGi 环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi 将按照下面的顺序进行类搜索（search）：

• s1）将以java.* 开头的类委派给父类加载器加载；
• s2）否则，将委派列表名单内的类 委派给父类加载器加载；
• s3）否则，将import 列表中的类委派给 Export这个类的 Bundle的类加载器加载；
• s4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载；
• s5）否则，查找类是否在自己的 Fragment Bundle中，如果在，则委派给 Fragment Bundle的类加载器加载；
• s6）否则，查找Dynamic Import 列表的Bundle，委派给对应Bundle 的类加载器加载；
• s7）否则，类查找失败；

3）consensus：在java程序员中有一个共识：OSGi 中对类加载器的使用是很值得学习的，弄懂了OSGi 的实现，就可以算是掌握了 类加载器的精髓；（干货——java程序员的共识）

4）intro to OSGi（来自百度百科） :

• OSGi(Open Service Gateway Initiative)技术是Java动态化模块化系统的一系列规范。OSGi一方面指维护OSGi规范的OSGI官方联盟，另一方面指的是该组织维护的基于Java语言的服务（业务）规范。简单来说，OSGi可以认为是Java平台的模块层。
• OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。Java提供在多个平台支持产品的可移植性。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。