Java虚拟机类加载机制

Posted 2020-07-21 Ezioooooo

本文是《深入理解Java虚拟机》第七章的读书总结。

Class文件中存储了类（或接口）中的元数据信息和编译后的字节码。这些信息需要存入Java虚拟机中才能被虚拟机利用和执行。而Class文件是需要Java虚拟机加载到虚拟机内存中的。这就涉及到几个问题，什么时候需要加在一个Class文件？虚拟机如何加载Class文件到虚拟机内存中？Class文件中的信息进入虚拟机内存中后会发生怎么样的变化？

1、概述

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

与那些在编译时需要进行连接工作的语言不同，在Java语言里，类型的加载、连接和初始化过程都是在程序运行期间完成的，这可能会导致类加载时增加了性能开销，不过这也为Java程序提供了高度的灵活性，Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。这个特性导致了很多有用的功能的出现，比如，可以编写一个面向接口的应用程序，等到运行时再指定接口的实现类；用户可以通过Java预定义的和自定义的类加载器，让一个本地的应用程序可以在运行时从网络或者其他地方加载一个二进制流作为程序代码的一部分。

2、什么时候加载？

类的一生就是从被加载到虚拟机内存开始，直到卸载出内存为止。整个生命周期中，一个类经历了加载（Loading）、验证（Verfication）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）等七个阶段。其中，验证、准备、解析三个阶段称为连接（Linking），过程如下所示：

在上面的流程图中，加载、验证、准备、初始化和卸载5个阶段是按顺序开始的，不过不一定按顺序进行，因为这些阶段通常是相互交叉的混合进行的，通常在一个阶段执行的过程中调用、激活另一个阶段。但是解析阶段则不一定，它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也叫动态绑定和晚期绑定）。

接下来就应该考虑一个Class文件会在什么时候进行加载。Java虚拟机规范中并没有进行强制约束，由虚拟机来具体实现。不过对于类的初始化阶段，虚拟机规范严格规定了5种情况下必须对类进行初始化，这样，类的加载、验证、准备就在这之前开始了。

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

这五种情况是Java虚拟机规范规定的主动初始化一个类的情况，除此之外的任何其他引用一个类的情况都不会主动初始化这个类，这叫做被动引用。下面以三个例子说明什么是被动引用。

（1）通过子类引用父类的静态字段，并不会初始化子类

代码如下：

package ch07;

public class SuperClass {
	static{
		System.out.println("Super Class init.");
	}
	public static int value=123;
}

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

public class Test1 {
	@SuppressWarnings("unused")
	public static void main(String[] args) {
		System.out.println(SubClass.value);
	}
}

这里定义了一个父类和一个子类，在Test1中通过子类引用父类的静态字段，结果如下：

Super Class init.
123

可以看到，并没有输出“SubClass init.”，对于静态字段，只有直接定义这个字段的类才会被初始化。不过，对于是否会加载并解析子类，Java虚拟机规范没有明确规定，HotSpot虚拟机可以使用-XX:TraceClassLoading参数来查看类加载的情况，结果如下（只显示了涉及到上面两个类的内容）：

[Loaded ch07.SuperClass from file:/G:/Java/UnderstandingJVM/bin/]
[Loaded ch07.SubClass from file:/G:/Java/UnderstandingJVM/bin/]

说明HotSpot虚拟机会加载子类，不过要先加载父类然后加载子类。

（2）通过数组定义来引用类，不会触发此类的初始化

代码如下：

public class Test1 {
	@SuppressWarnings("unused")
	public static void main(String[] args) {
		SuperClass[] sca=new SuperClass[10];
	}
}

这里复用了上面的父类和子类的代码，使用new关键字创建了一个父类的数组，结果并没有"SuperClass init."输出，说明没有触发SuperClass类的初始化阶段。不过这会导致另一个叫做“[Lch07.SuperClass”的类的初始化过程，这是一个由虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray触发。

这意味着，数组也是对象，而且是和成员类型不同的一个对象。

这个类代表了SuperClass的一维数组，数组中应有的属性和方法（用户可以访问到的只有length属性和clone方法）都实现在这个类里。Java语言中对数组的访问要比C/C++相对安全是因为这个类封装了数组元素的访问方法，而C/C++直接翻译为对数组指针的移动。在Java语言里，当检查到发生数组越界时会抛出java.lang.ArrayIndexOutOfBoundsException异常。

（3）常量在编译阶段会存入调用类的常量池

代码如下：

public class ConstClass{
	static{
		System.out.println("ConstClass init.");
	}
	public static final String GREETING="Hello World.";
}

public class Test1{
	public static void main(String[] args){
		System.out.println(ConstClass.GREETING);
	}
}

这里的ConstClass里定义了一个常量，运行后也没有“ConstClass init.”输出，这时因为在编译阶段将这个常量的值存储到了Test1类的常量池中，以后Test1类对这个常量的引用实际上都会被转化为Test类对自身常量池的引用，即使在Java源码中引用了ConstClass的GREETING常量。也就是说，实际上Test1的Class文件中并没有对ConstClass类的符号引用入口，两者在编译成Class文件后就没有关系了。

接口的加载过程和类的加载过程有一些不同，不过接口也有初始化过程，上面的代码都是用静态代码块“static{}”来输出初始化信息的，而接口中不能使用“static{}”语句块，但编译器仍然会为接口生成“<clinit()>”类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是在前面五种情况中的第三种：当一个类在初始化时，它的所有父类都完成了初始化，但对一个接口初始化时，并不要求所有的父接口都完成初始化，只有在真正用药父接口的时候才会初始化。

3、怎么加载？

接下来就是怎么加载的问题了。这里涉及到前面图中的五个阶段：加载、验证、准备、解析和初始化。

3.1、加载阶段

这个加载的步骤只是类加载过程的一个阶段。这在个阶段，虚拟机要做的事情有如下三个：

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

流程图如下：

虚拟机规范的这三点要求并不具体，虚拟机的实现很自由。

首先要有Class文件。虽然说是文件，但获取Class二进制流的方式非常对，只要能得到这个虚拟机所需要的内容即可。比如可以使用如下的方式获取二进制流：

• 从ZIP包中读取，这就是JAR、EAR和WAR格式的基础；
• 从网络中获取，典型应用就是Applet；
• 运行时计算生成，使用最多的就是动态代理技术；
• 由其他文件生成，典型场景是JSP应用，即由JSP文件生成对应的Class类；
• 从数据库汇中读取；

总之，获取Class文件的方式非常多。

将Class文件加载到内存中是由类加载器完成的。相比于类加载的其他阶段，加载这个阶段的灵活性很大，因为开发者可以自己定义一个类加载器，来达到灵活加载的目的（即重写一个类加载器的loadClass()方法）。

前面提到过，数组也是一个类，但数组类的加载和非数组类不同，它不是通过类加载器创建的，而是由Java虚拟机直接创建的。但数组类和非数组类也有很大的联系，毕竟组成数组的元素就是非数组类（对于一维数组来说，而对于多维数组来说，可以递归加载），非数组类的创建需要类加载器完成。加载创建一个数组类的过程如下：

• 如果数组的元素类型是引用类型，就递归加载这个元素类型，这个数组将在加载该元素类型的类加载器的类名称空间上被标识；
• 如果数组的元素类型不是引用类型（比如int[]数组），Java虚拟机将会把数组标记为与引导类加载器关联；
• 数组类的可见性与元素类型的可见性一致，如果元素类型是不引用类型，那么数组的可见性默认是public；

加载阶段完成后，原来虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，不过方法区中的数据格式Java虚拟机规范没有规定。在这之后，虚拟机会在内存中实例化一个java.lang.Class类的对象。对于HotSpot虚拟机，虽然这是一个对象，按理说应该在Java堆中创建，不过HotSpot虚拟机是在方法区中创建的。这个对象将作为程序访问方法区中的这些数据类型的外部入口。

需要注意的是，加载阶段与连接阶段的部分内容是交叉进行的。

3.2、验证阶段

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

不过，如果Java源代码本身有安全问题的话（比如数组越界访问），编译器就不会编译成功，也就没有Class文件。是不是就是说，如果有Class文件，那么这个Class文件就是安全的呢？如果这样，也就不需要验证了，是不是可以提高虚拟机的执行性能呢？

当然不是，前面的加载阶段提到过，Class文件不一定是编译器生成的，获取Class文件的方式有很多，甚至可以使用十六进制编辑器自己手工写一个Class文件。这样，Java语言方面的安全检查就没有用了，如果虚拟机不检查输入的字节流，很可能会因为载入了有害的字节流导致虚拟机崩溃。即，验证阶段是虚拟机的自我保护的一个手段。

从整体上看，验证阶段大致可以分为四个方面：文件格式验证、元数据验证、字节码验证和符号引用验证。

（1）文件格式验证

首先要验证文件的格式是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这个阶段可能验证的内容有：

• 文件的开始是否是0xCAFEBABE这个魔数；
• 主次版本号是否在当前虚拟机的处理范围内；
• 常量池的常量中是否有不被支持的常量类型（即检查tag标志）；
• 指向常量的各种索引值是否有指向不存在的常量或不符合类型的常量；
• CONSTANT_Utf8_info类型的常量中是否有不符合UTF8编码的数据；
• Class文件中各个部分及文件本身是否有被删除的或附加的其他信息等；

其实这只是一小部分，这个阶段要验证的内容还挺多，主要目的就是保证输入的字节流能正常地解析并存储于方法区内，格式上符合描述一个Java类型信息的要求。这个阶段验证的是基于二进制字节流的，只有通过这个阶段的验证，字节流才会进入方法区中，所以后面的三个验证阶段是基于方法区的存储结构进行的。

从这里可以看出，在虚拟机找到Class文件之后就开始了验证阶段，两个阶段是交叉进行的。如果这两个阶段细分的话，可以是：寻找Class文件——>找到后进行文件格式验证——>验证通过后存入方法区——>进行其他方面的验证与加载工作。

（2）元数据验证

接下来就是对字节码描述的信息进行语义分析，验证这些信息是否符合Java语言规范的要求，这个阶段验证的内容有：

• 这个类是否有父类（除了java.lang.Object外都有父类）；
• 这个类的父类是否继承了不被允许继承的类（被final修饰的类，如String）；
• 如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法；
• 类中的字段、方法是否与父类产生矛盾（比如覆盖了父类的final字段、或出现不符合规则的方法重载等）；

对元数据的验证内容还有很多，主要是保证不存在不符合Java语言规范的元数据信息。

（3）字节码验证

接下来就是字节码验证，这部分是整个验证过程中最复杂的一部分，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段完成对元数据信息中的数据类型的验证后，这个阶段将对类的方法体进行校验分析，保证被校验的类的方法在运行时不会做出危害虚拟机安全的事件，比如：

• 保证任意时刻操作数栈的数据类型与指令序列都能配合工作，即不会出现指令是iload但操作数是long的情况；
• 保证跳转指令不会跳转到方法体以外的字节码指令上；
• 保证方法体中的类型转换是有效的；

这部分的验证内容还有很多。如果一个类方法体的字节码没有通过字节码验证，那么这肯定是有问题的；不过，如果字节码通过了字节码验证也不一定是没有问题的。

由于数据流验证的高复杂性，虚拟机设计团队在JDK 1.6之后的Javac编译器和Java虚拟机中进行了一项优化，给方法体的Code属性的属性表中增加了一个叫StackMapTable的属性，这个属性用来描述方法体中所有的基本快（按照控制流拆分的代码块）开始时本地变量表和操作数栈应有的状态，在字节码验证期间，就不需要根据程序员推导这些状态的合法性，只需要检查StackMapTable属性中的记录是否合法即可。不过这个属性也有被篡改的可能。

在JDK 1.6的HotSpot虚拟机中提供了-XX:UseSplitVerifier选项来关闭这项优化，或者使用参数-XX:FailOverToOldVerifier要求在类型校验失败的时候回退到旧的类型推导方式进行校验。而在JDK 1.7之后，对于版本号大于50的Class文件，使用类型检查来完成数据流分析校验是唯一的选择，不允许回退到类型推导的校验方式。

（4）符号引用验证

最后一个验证阶段就是符号引用验证。这一阶段发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池的各种符号引用）的信息进行匹配性校验，通常要校验如下内容：

• 符号引用中通过字符串描述的全限定名是否能找到对应的类；
• 在指定类中是否存在符号方法的字段描述符以及简单名称所描述的方法和字段；
• 符号引用中的类、字段和方法的访问性是否可以被当前类访问；

符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么就会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。

对于虚拟机的类加载机制来说，验证阶段是一个非常重要但不是必须的阶段。如果所运行的代码都已经被反复使用和验证过，那么在实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3.3、准备阶段

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中需要注意两点，首先，这个时候进行内存分配的仅包括类变量（被static修饰的变量）而不包括实例变量，实例变量就在对象实例化时随着对象一起分配在Java堆中。其次，这里所说的初始值通常是数据类型的零值，比如下面的类变量定义：

public static int value=10;

那么value在准备阶段的初始值是0而不是10，因为这个时候还没开始执行任何Java方法，而将value赋值为10的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法中，所以把value赋值为10的动作将在初始化阶段才会执行。下标列出了所有基本类型的零值：

数据类型	零值	数据类型	零值
int	0	boolean	False
long	0L	float	0.0f
short	(short)0	double	0.0d
char	‘\\u0000’	reference	Null
byte	(byte)0

不过也有特殊情况，将类变量赋值为非零值。如果类字段的字段属性表中存在ConstantValue属性，那么在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，比如：

public static final int value=10;

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

3.4、解析阶段

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，在Class文件结构中层多次提到过符号引用，它以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现。在解析阶段的符号引用和直接引用的区别如下：

• 符号引用（Symbolic References）：符号引用以一组符号来描述索引用的目标，符号引用可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用都是一样的；
• 直接引用（Direct References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局有关的，同一个符号引用在不同的虚拟机上翻译出来的直接引用一般不相同。如果有了直接引用，那么引用的目标一定在内存中。

虚拟机规范没有规定解析阶段发生的具体时间，只要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokeespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield和putstatic这16个用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。所以虚拟机实现可以根据需要来判断到底是在类被加载器加载之前就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前再去解析。

对同一个符号引用进行多次解析请求是很常见的事情，除了invokedynamic指令外，虚拟机实现可以对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免重复解析。无论是否真正执行了多次解析动作，虚拟机需要保证的是在同一个实体中，如果一个符号引用之前就已经被成功解析过，那么后续的引用解析请求就应当是一直成功；同样的，如果第一次解析失败了，那么其它指令对这个符号的解析请求也应该收到同样的异常。

解析动作主要是对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行解析，分别对应CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info和CONSTANT_InvokeDynamic_info7种常量类型。这里仅仅介绍前四种，因为后三种和动态类型语言支持有关。

（1）   类或接口的解析

假设当前代码处于类D中，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，虚拟机将经历如下的过程：

• 如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器区加载这个类。在加载过程中，由于元数据验证、字节码验证的需要，又可能触发其他相关类的加载，比如这个类的父类或实现的接口。如果加载过程出现异常，解析过程就失败。
• 如果C是一个数组类型，并且数组的元素类型是对象，就会按照第一点加载数组元素类型。接着由虚拟机生成一个代表着数组维度和元素的数组对象。
• 如果上面的步骤没有异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。

（2）   字段解析

要解析一个未被解析过的字段符号引用，首先将会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或借口的符号引用。如果解析这个类或接口时发生异常，都会导致解析字段的失败。如果解析成功，才会继续解析这个字段。具体的规则如下：

• 如果类或接口C本身就包含了简单名称和字段描述符都与目标匹配的字段，则返回这个字段的直接引用，查找结束；
• 否则，如果在C中实现了接口，将会按照继承关系从下到上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标匹配的字段，则返回这个字段的直接引用，查找结束；
• 否则，如果C不是Object的话，将会按照继承关系从下到上递归搜索父类，如果父类中包含了简单名称和字段描述符都与目标匹配的字段，返回这个字段的直接引用，查找结束；
• 否则，查找失败。
• 之后，还会对返回的字段进行权限验证，如果不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

（3）   类方法解析

类方法解析的第一个步骤和字段解析一样，也需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，按照如下步骤继续（同样以C来表示这个类）：

• 类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的C是一个接口，直接失败；
• 然后，会在类C中查找这个方法；
• 否则，在类C的父类中递归查找这个方法；
• 否则，在类C实现的接口列表中递归查找这个方法。如果找到一个匹配的方法，说明类C是一个抽象类，查找结束，抛出java.lang.AbstractMethodError异常；
• 否则，查找失败，抛出java.lang.NoSuchMethodError异常。
• 同样，成功返回后还要进行权限验证。

（4）   接口方法解析

接口方法也要解析接口方法表的class_index所属的类或接口引用，如果解析成功，用C表示这个类或接口，虚拟机按照如下的规则搜索：

• 与类方法解析不同，如果在接口方法表中发现class_index是一个类而不是接口，直接抛出java.lang.IncompatibleClassChangeError异常；
• 否则，在接口C中查找这个方法；
• 否则，在接口C的父接口中递归查找；
• 否则，查找失败，抛出java.lang.NoSuchMethodError异常。

返回成功后不会验证权限，因为接口的方法都是public的。

3.5、初始化阶段

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序。

前面已经知道，在准备阶段变量已经赋值过一次系统初始值了，而在初始化阶段，则会根据程序员通过程序制定的主观计划去初始化类变量和其它内容。即，初始化阶段是执行类构造器<clinit>()方法的过程。下面是<clinit>()方法的特点：

• <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序由语句块在源文件中的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在之后的变量不能访问，但能赋值。
• <clinit>()方法与类构造器<init>()不同，它不需要显式调用父类的<clinit>()方法，虚拟机保证在子类<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。
• 由于父类的<clinit>()方法先执行，意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
• <clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变脸的赋值操作，那么编译器就不会生成<clinit>()方法。
• 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。即，只有使用一个接口中的变量时，才会执行这个接口的<clinit>()方法。
• 虚拟机会保证一个类的<clinit>()方法在多线程环境下中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只有一个线程会去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。

4、类加载器

类加载的过程是通过类加载器来完成的。类加载器是Java语言的一个重要创新，许多有用的技术都是基于类加载器实现的，比如类层次划分、OSGi、热部署、代码加密等。

4.1、类与类加载器

虽然类加载器只用于类的加载动作，但在Java程序中还有着很大的作用。对于任意一个类，都需要加载它的类加载器和这个类本身来确定这个类在Java虚拟机中的唯一性，每一个类加载器都有一个独立的类名称空间。也就是说，如果比较两个类是否是同一个类，除了这比较这两个类本身的全限定名是否相同之外，还要比较这两个类是否是同一个类加载器加载的。即使同一个类文件两次加载到同一个虚拟机中，但如果是由两个不同的类加载器加载的，那这两个类仍然不是同一个类。

这个相等性比较会影响一些方法，比如Class对象的equals方法、isAssignableFrom方法、isInstance方法等，还有instanceof关键字做对象所属关系判定等。下面的代码演示了不同的类加载器对instanceof关键字的影响：

package jvm;

import java.io.IOException;
import java.io.InputStream;

public class ClassLoaderTest {
	public static void main(String[] args) throws Exception{
		ClassLoader loader=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=loader.loadClass("jvm.ClassLoaderTest").newInstance();
		System.out.println(obj.getClass());
		System.out.println(obj instanceof jvm.ClassLoaderTest);
	}
}

运行结果：
class jvm.ClassLoaderTest
false

这里构造了一个简单的类加载器，它可以加载与自己在同一个路径下的Class文件。然后使用这个类加载器去加载全限定名是“jvm.ClassLoaderTest”的类，并实例化了这个类的对象。从第一行输出可以看出，这个对象确实是jvm.ClassLoaderTest类的一个实例，但第二句输出表明在做instanceof检查时出现了false，这是因为这时虚拟机中有两个jvm.ClassLoaderTest类，一个是系统应用程序类加载器加载的，另一个是自定义的类加载器加载的，这两个类虽然来自同一个Class文件，但是加载它们的类加载器不同，导致类型检查时结果是false。

4.2、双亲委派模型

从Java虚拟机的角度看，只有两种不同的类加载器，一种是启动类加载器，这个类加载是由C++实现的，是虚拟机的一部分；另一个是所有其它的类加载器，都是由Java实现的，独立在虚拟机外部，并且全部继承自java.lang.ClassLoader抽象类。

不过在Java开发者看来，类加载器的细致划分可以划分为三种：

• 启动类加载器：负责将存放在<JAVA_HOME>\\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。
• 扩展类加载器：这个加载器由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>\\lib\\ext目录下的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
• 应用程序类加载器：这个类加载器是由sun.misc.Launcher$AppClassLoader实现的。由于这个类加载器是ClassLoader中的getSystemClassLoader方法的返回值，所以也叫系统类加载器。它负责加载用户类路径上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

用户的应用程序就是在这三个类加载器的配合下加载的。不过，用户还可以加入自己的类加载器，这些类加载器的关系如下图：

这种类加载的层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当有自己的父类加载器。不过这个父子关系不是通过继承实现的，而是使用组合关系来复用父加载器的代码。

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

这种模型的一个好处就是由于类加载器有一种层次关系，导致类也有一种层次关系，从而有了优先级。比如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都要委派给启动类加载器去加载，因此Object类在各个类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器去自行加载，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会有多个不同的Object类，java类型体系中最基础的行为也就没有办法保证了。

4.3、双亲委派模型的破坏

不过，双亲委派模型并不是一个强制性的约束模型，而是一个推荐实现类加载的方式。但也会有例外，导致破坏双亲委派模型。

首先，双亲委派模型是JDK 1.2之后引入的，而ClassLoader类在JDK 1.0就有了，为了向前兼容，不得做出一些妥协。

还有，类加载器的层次结构解决了基础类的统一问题，但是如果基础类要回调用户的代码呢？这也破坏了双亲委托模型。

最后就是语言动态性造成的。

这部分对于双亲委派模型的破坏的介绍不是很多，只要知道这只是一个推荐模型即可。

添加公众号Machairodus，我会不时分享平时学到的东西~