写在前面：
- 你好，欢迎你的阅读！
- 我热爱技术，热爱分享，热爱生活， 我始终相信：技术是开源的，知识是共享的！
- 博客里面的内容大部分均为原创，是自己日常的学习记录和总结，便于自己在后面的时间里回顾，当然也是希望可以分享自己的知识。目前的内容几乎是基础知识和技术入门，如果你觉得还可以的话不妨关注一下，我们共同进步！
- 除了分享博客之外，也喜欢看书，写一点日常杂文和心情分享，如果你感兴趣，也可以关注关注！
- 微信公众号：傲骄鹿先生
目录
Java程序实际上是将。class文件放入JVM中运行。虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验，转换，解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是JVM的类加载机制
一、类加载机制概述
Java类编译成Class字节码的相关描述和信息，但是java虚拟机如何才能按照class字节码中描述的内容进行运用和使用呢？这个就需要JVM的类加载机制对其进行规范和约束；所以虚拟机把类的数据从Class文件(这里的Class文件可以是javac编译成的class文件，也可以是反射或者动态代理生成的class二进制流，或者网络传输的二进制流等等)加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型的过程就是虚拟机的类加载机制。
JVM类加载机制主要包括两个问题：类加载的时机与步骤和类加载的方式。
与那些在编译时需要进行连接工作的语言不同，在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会令类加载时稍微增加一些性能开销，但是会为Java应用程序提供高度的灵活性，Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的。例如，如果编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类；用户可以通过Java预定义的和自定义类加载器，让一个本地的应用程序可以再运行时从网络或其他地方加载一个二进制流作为程序代码的一部分，这种组装应用程序的方式目前已广泛应用于Java程序之中。那么，对于Java的类加载会产生如下问题:
-
虚拟机什么时候才会加载Class文件并初始化类呢？（类加载和初始化时机）
-
虚拟机如何加载一个Class文件呢？(Java类加载的方式：类加载器、双亲委派机制)
-
虚拟机加载一个Class文件要经历那些具体的步骤呢？(类加载过程与步骤)
二、类加载的时机
Java类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)七个阶段。其中准备、验证、解析三个部分统称为连接(Linking),这7个阶段的发生顺序如下图所示。
加载、验证、准备、初始化和卸载5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以再初始化阶段后再开始，这是为了支持Java语言的运行时绑定(也称动态绑定或晚期绑定)。注意：类的加载过程必须按照这种顺序按部就班地开始，而不是按部就班地进行或完成，因为这些阶段通常都是相互交叉地混合式进行的，通常会在一个阶段执行的过程中调用、激活另外一个阶段。
2.1、类加载的时机
Java虚拟机规范中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始），具体有5种情况：
-
遇到new、getstatic、putstatic或invokestatic这四条字节码指令
-
使用java.lang.reflect包的方法对类进行反射调用的时候
-
初始化类时，父类没有被初始化，先初始化父类
-
虚拟机启动时，用户指定的主类（包含main）
-
当使用jdk1.7动态语言支持时，如果一个java.lang.invoke.MethodHandle实例解析出REF__pubstatic，REF_invokestatic方法句柄，并且这个方法句柄所对应的类没有进行初始化
其中第一点主要解释为以下四个方面：
1、使用 new 关键字实例化对象时；
2、读取类的静态变量时（被 final修饰，已在编译期把结果放入常量池的静态字段除外）；
3、设置类的静态变量时；
4、调用一个类的静态方法时。需要注意：newarray指令触发的只是数组类型本身的初始化，而不会导致其相关类型的初始化，比如，new String[]只会直接触发String[]类的初始化，也就是触发对类java.lang.String的初始化，而直接不会触发String类的初始化。生成这四条指令最常见的Java代码场景是：
-
使用new关键字实例化对象的时候；
-
读取或设置一个类的静态字段(被final修饰，已在编译器把结果放入常量池的静态字段除外)的时候；
-
调用一个类的静态方法的时候；
对于这5种会触发类进行初始化的场景，虚拟机规范中使用了一个很强烈的限定语：“有且只有”，这5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。
需要特别指出的是，类的实例化和类的初始化是两个完全不同的概念：
-
类的实例化是指创建一个类的实例(对象)的过程；
-
类的初始化是指为类各个成员赋初始值的过程，是类生命周期中的一个阶段。
2.2 被动引用常见的三种场景
1、通过子类引用父类的静态字段，不会导致子类初始化
/**
* <Description> 输出:Initialize class Dgrandpa
Initialize class Dfather
* 对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，
* 只会触发父类的初始化而不会触发子类的初始化。至于是否要触发子类的加载和验证，在虚拟机中并未明确规定，
* 这点取决于虚拟机的具体实现。对于Sun HotSpot虚拟机来说，可通过-XX:+TraceClassLoading参数观察到此操作
* 会导致子类的加载。
*/
public class PrTest1 {
public static void main(String[] args) {
int x = Dson.count;
}
}
class Dgrandpa {
static {
System.out.println("Initialize class Dgrandpa");
}}class Dfather extends Dgrandpa{
static int count = 1;
static{
System.out.println("Initialize class Dfather");
}
}
class Dson extends Dfather{
static{
System.out.println("Initialize class Dson");
}
}
2、通过数组定义来引用类，不会触发此类的初始化
/**
* <Description> 没有任何输出
* 通过数组来定义引用类，不会触发此类的初始化
*/
public class PrTest2 {
public static void main(String[] args) {
E[] e = new E[10];
}
}
class E{
static{
System.out.println("Initialize class E");
}
}
3、常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
/**
* <Description> 输出：1
* 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，
* 因此不会触发定义常量的类的初始化
*/
public class PrTest3 {
public static void main(String[] args) {
System.out.println(ConstClass.COUNT );
}
}
class ConstClass{
static final int COUNT = 1;
static{
System.out.println("Initialize class ConstClass");
}
}
上述代码运行之后，只输出“1”，这是因为虽然在Java源码中引用了ConstClass类中的常量COUNT，但是编译阶段将此常量的值“1”存储到了PrTest3常量池中，对常量ConstClass.COUNT的引用实际都被转化为PrTest3类对自身常量池的引用了。也就是说，实际上PrTest3的Class文件之中并没有ConstClass类的符号引用入口，这两个类在编译为Class文件之后就不存在关系了。
三、类加载过程
类从加载虚拟机内存中开始到卸载出内存为止，生命周期包括：加载、验证、准备、解析、初始化、使用、卸载。
3.1、加载（Loading）
在加载阶段，虚拟机需要完成以下三件事情：
a、通过一个类的全限定名来获取定义此类的二进制字节流(并没有指明要从一个Class文件中获取，可以从其他渠道，如：网络、动态生成、数据库等)；
b、将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构；
c、在内存中(对于HotSpot虚拟机而言就是方法区)生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据访问入口；
加载阶段与连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在夹在阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
3.2 、验证(Verification)
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会尾号虚拟机自身的安全。验证阶段大致会完成资格阶段的检验动作：
-
文件格式验证：验证字节流是否符合Class文件格式的规范(如：是否以魔数0xCAFEBABE开头，主次版本号是否在当前虚拟机的处理范围之内、常量池中是否有不被支持的类型)
-
元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求(如：这个类是否有父类，除了java.lang.Object之外)
-
字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的；
-
符号引用验证：确保解析动作能正确执行。
验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响。如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
3.3、 准备(Preparation)
准备阶段是正式为类变量(static成员变量)分配内存并设置类变量初始值(零值)的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。
其次，这里所说的初始值通常情况下是数据类型的零值，假设一个类变量定义为：
public static int value = 123;
那么，变量value在准备阶段过后的值为0而不是123。因为这时候尚未开始执行任何java方法，而把value复制为123的putstatic指令时程序被变异后，存放于类构造器方法<clinit>()之中，所以把value赋值为123的动作将在初始化阶段才会执行。至于“特殊情况”是指：当类字段的字段属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标注为final之后，value的值在准备阶段初始化为123而非0；
public static final int value = 123;
3.4 、解析(Resolution)
解析阶段是把常量池内的符号引用替换成直接引用的过程，符号引用就是Class文件中的CONSTANT_Class_info、 CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量。下面我们看符号引用和直接引用的定义。
-
符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要可以唯一定位到目标即可。符号引用于内存布局无关，所以所引用的对象不一定需要已经加载到内存中。各种虚拟机实现的内存布局可以不同，但是接受的符号引用必须是一致的，因为符号引用的字面量形式已经明确定义在Class文件格式中。
-
直接引用（Direct References）：直接引用时直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用和虚拟机实现的内存布局相关，同一个符号引用在不同虚拟机上翻译出来的直接引用一般不会相同。如果有了直接引用，那么它一定已经存在于内存中了。
以下Java虚拟机指令会将符号引用指向运行时常量池，执行任意一条指令都需要对它的符号引用进行解析：
对同一个符号进行多次解析请求是很常见的，除了invokedynamic指令以外，虚拟机基本都会对第一次解析的结果进行缓存，后面再遇到时，直接引用，从而避免解析动作重复。
对于invokedynamic指令，上面规则不成立。当遇到前面已经由invokedynamic指令触发过解析的符号引用时，并不意味着这个解析结果对于其他invokedynamic指令同样生效。这是由invokedynamic指令的语义决定的，它本来就是用于动态语言支持的，也就是必须等到程序实际运行这条指令的时候，解析动作才会执行。其它的命令都是“静态”的，可以再刚刚完成记载阶段，还没有开始执行代码时就解析。
下面来看几种基本的解析：
类与接口的解析： 假设Java虚拟机在类D的方法体中引用了类N或者接口C，那么会执行下面步骤：
-
如果C不是数组类型，D的定义类加载器被用来创建类N或者接口C。加载过程中出现任何异常，可以被认为是类和接口解析失败。
-
如果C是数组类型，并且它的元素类型是引用类型。那么表示元素类型的类或接口的符号引用会通过递归调用来解析。
-
检查C的访问权限，如果D对C没有访问权限，则会抛出java.lang.IllegalAccessError异常。
字段解析：
要解析一个未被解析过的字段符号引用，首先会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析,也就是字段所属的类或接口的符号引用。如果在解析这个类或接口符号引用的过程中出现了任何异常，都会导致字段解析失败。如果解析完成，那将这个字段所属的类或者接口用C表示，虚拟机规范要求按照如下步骤对Ｃ进行后续字段的搜索。
1 . 如果C本身包含了简单名称和字段描述符都与目标相匹配的字段，则直接返回这个字段的直接引用，查找结束。
2 . 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
3 . 再不然，如果C不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在类中包含
了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
4 . 如果都没有，查找失败退出，抛出java.lang.NoSuchFieldError异常。如果返回了引用，还需要检查访问权限，如果没有访问权限，则会抛出java.lang.IllegalAccessError异常。
在实际的实现中，要求可能更严格，如果同一字段名在C的父类和接口中同时出现，编译器可能拒绝编译。
类方法解析
类方法解析也是先对类方法表中的class_index项中索引的方法所属的类或接口的符号引用进行解析。我们依然用C来代表解析出来的类，接下来虚拟机将按照下面步骤对C进行后续的类方法搜索。
1 . 首先检查方法引用的C是否为类或接口，如果是接口，那么方法引用就会抛出IncompatibleClassChangeError异常
2 . 方法引用过程中会检查C和它的父类中是否包含此方法，如果C中确实有一个方法与方法引用的指定名称相同，并且声明是签名多态方法（Signature Polymorphic Method）,那么方法的查找过程就被认为是成功的，所有方法描述符所提到的类也需要解析。对于C来说，没有必要使用方法引用指定的描述符来声明方法。
3 . 否则，如果C声明的方法与方法引用拥有同样的名称与描述符，那么方法查找也是成功。
4 . 如果C有父类的话，那么按照第2步的方法递归查找C的直接父类。
5 . 否则，在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在相匹配的方法，说明类C时一个抽象类，查找结束，并且抛出java.lang.AbstractMethodError异常。
接口方法解析
接口方法也需要解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，依然用C表示这个接口，接下来虚拟机将会按照如下步骤进行后续的接口方法搜索。
1 . 与类方法解析不同，如果在接口方法表中发现class_index对应的索引C是类而不是接口，直接抛出java.lang.IncompatibleClassChangeError异常。
2 . 否则，在接口C中查找是否有简单名称和描述符都与目标匹配的方法，如果有则直接返回这个方法的直接引用，查找结束。
3 . 否则，在接口C的父接口中递归查找，直到java.lang.Object类为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
4 . 否则，宣告方法失败，抛出java.lang.NoSuchMethodError异常。
由于接口的方法默认都是public的，所以不存在访问权限问题，也就基本不会抛出java.lang.IllegalAccessError异常。
3.5 初始化(Initialization)
类初始化阶段是类加载过程的最后一步。在前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的java程序代码(字节码)。
在准备阶段，变量已经赋过一次系统要求的初始值(零值)；而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者更直接地说：初始化阶段是执行类构造器<clinit>()方法的过程。<clinit>()方法时由编译器自动收集类中的所有类变量的赋值动作和静态语句块static{}中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。如下：
public class Test{
static{
i=0;
System.out.println(i);//Error：Cannot reference a field before it is defined（非法向前应用）
}
static int i=1;
}
那么注释报错的那行代码，改成下面情形，程序就可以编译通过并可以正常运行了。
public class Test{
static{
i=0;
//System.out.println(i);
}
static int i=1;
public static void main(String args[]){
System.out.println(i);
}
}
类构造器<clinit>()与实例构造器<init>()不同，它不需要程序员进行显式调用，虚拟机会保证在子类类构造器<clinit>()执行之前，父类的类构造<clinit>()执行完毕。由于父类的构造器<clinit>()先执行，也就意味着父类中定义的静态语句块/静态变量的初始化要优先于子类的静态语句块/静态变量的初始化执行。特别地，类构造器<clinit>()对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生产类构造器<clinit>()。
虚拟机会保证一个类的类构造器<clinit>()在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的类构造器<clinit>()，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。特别需要注意的是，在这种情形下，其他线程虽然会被阻塞，但如果执行<clinit>()方法的那条线程退出后，其他线程在唤醒之后不会再次进入/执行<clinit>()方法，因为在同一个类加载器下，一个类型只会被初始化一次。如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的，如下所示：
public class DealLoopTest {
static{
System.out.println("DealLoopTest...");
}
static class DeadLoopClass {
static {
if (true) {
System.out.println(Thread.currentThread()
+ "init DeadLoopClass");
while (true) { // 模拟耗时很长的操作
}
}
}
}
public static void main(String[] args) {
Runnable script = new Runnable() { // 匿名内部类
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();
}
}/
* Output:
DealLoopTest...
Thread[Thread-1,5,main] start
Thread[Thread-0,5,main] start
Thread[Thread-1,5,main]init DeadLoopClass
*/
四、类加载器和双亲委派机制
我们对java.lang.ClassNotFoundExcetpion这个异常肯定都不陌生，其实，这个异常背后涉及到的是Java技术体系中的类加载。Java类加载机制是技术体系中比较核心的部分，虽然和大部分开发人员直接打交道不多，但是对其背后的机理有一定理解有助于排查程序中出现的类加载失败等技术问题，对理解Java虚拟机的连接模型和Java语言的动态性都有很大帮助。
4.1、 JVM三种预定义类型类加载器
当JVM启动的时候，Java缺省开始使用如下三种类型的类加载器：
启动（Bootstrap ClassLoader）类加载器：引导类加载器是用 本地代码实现的类加载器，它负责将 <JAVA_HOME>/lib下面的核心类库 或 -Xbootclasspath选项指定的jar包等虚拟机识别的类库加载到内存中。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
扩展（Extension ClassLoader）类加载器：扩展类加载器是由Sun的ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的，它负责将<JAVA_HOME >/lib/ext或者由系统变量-Djava.ext.dir指定位置中的类库 加载到内存中。开发者可以直接使用标准扩展类加载器。
系统（System ClassLoader）类加载器：系统类加载器是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的，它负责将用户类路径(java -classpath或-Djava.class.path变量所指的目录，即当前类所在路径及其引用的第三方类库的路径)下的类库 加载到内存中。开发者可以直接使用系统类加载器。一般情况下这就是系统默认的类加载器
除了以上列举的三种类加载器，还有一种比较特殊的类型就是线程上下文类加载器（后文进行学习）
4.2、 类加载双亲委派机制
双亲委派模型是一种组织类加载器之间关系的一种规范。
工作原理:如果一个类加载器收到了类加载的请求，它不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，这样层层递进，最终所有的加载请求都被传到最顶层的启动类加载器中，只有当父类加载器无法完成这个加载请求(它的搜索范围内没有找到所需的类)时，才会交给子类加载器去尝试加载。
这样的好处是:java类随着它的类加载器一起具备了带有优先级的层次关系。这是十分必要的，比如java.lang.Object，它存放在\jre\lib\rt。jar中，它是所有java类的父类，因此无论哪个类加载都要加载这个类，最终所有的加载请求都汇总到顶层的启动类加载器中。Object类会由启动类加载器来加载，所以加载的都是同一个类，如果不使用双亲委派模型，由各个类加载器自行去加载的话，系统中就会出现不止一个Object类，应用程序就会全乱了。
扩展类加载器和系统类加载器均是继承自 java.lang.ClassLoader抽象类。我们下面我们就看简要介绍一下抽象类 java.lang.ClassLoader中几个最重要的方法：
//加载指定名称（包括包名）的二进制类型，供用户调用的接口
public Class<?> loadClass(String name) throws ClassNotFoundException{ … }
//加载指定名称（包括包名）的二进制类型，同时指定是否解析（但是这里的resolve参数不一定真正能达到解析的效果），供继承用
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{ … }
//findClass方法一般被loadClass方法调用去加载指定名称类，供继承用
protected Class<?> findClass(String name) throws ClassNotFoundException { … }
//定义类型，一般在findClass方法中读取到对应字节码后调用，final的，不能被继承 //这也从侧面说明：JVM已经实现了对应的具体功能，解析对应的字节码，产生对应的内部数据结构放置到方法区，所以无需覆写，直接调用就可以了）
protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError{ … }
通过进一步分析标准扩展类加载器和系统类加载器的代码以及其公共父类（java.net.URLClassLoader和java.security.SecureClassLoader）的代码可以看出，都没有覆写java.lang.ClassLoader中默认的加载委派规则 — loadClass（…）方法。既然这样，我们就可以从java.lang.ClassLoader中的loadClass（String name）方法的代码中分析出虚拟机默认采用的双亲委派机制到底是什么模样：
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
protected synchronized Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException {
// 首先判断该类型是否已经被加载
Class c = findLoadedClass(name);
if (c == null) {
//如果没有被加载，就委托给父类加载或者委派给启动类加载器加载
try {
if (parent != null) {
//如果存在父类加载器，就委派给父类加载器加载
c = parent.loadClass(name, false);
} else { // 递归终止条件
// 由于启动类加载器无法被Java程序直接引用，因此默认用 null 替代
// parent == null就意味着由启动类加载器尝试加载该类，
// 即通过调用 native方法 findBootstrapClass0(String name)加载
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器不能完成加载请求时，再调用自身的findClass方法进行类加载，若加载成功，findClass方法返回的是defineClass方法的返回值
// 注意，若自身也加载不了，会产生ClassNotFoundException异常并向上抛出
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
通过上面的代码分析，我们可以对JVM采用的双亲委派类加载机制有了更感性的认识，下面我们就接着分析一下启动类加载器、标准扩展类加载器和系统类加载器三者之间的关系。
上面图片给人的直观印象是：系统类加载器的父类加载器是标准扩展类加载器，标准扩展类加载器的父类加载器是启动类加载器，下面我们就用代码具体测试一下：
public class LoaderTest {
public static void main(String[] args) {
try {
System.out.println(ClassLoader.getSystemClassLoader());
System.out.println(ClassLoader.getSystemClassLoader().getParent());
System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());
} catch (Exception e) {
e.printStackTrace();
}
}
}
/* Output:
sun.misc.Launcher$AppClassLoader@6d06d69c
sun.misc.Launcher$ExtClassLoader@70dea4e
null
*/
通过以上的代码输出，我们知道：通过java.lang.ClassLoader.getSystemClassLoader()可以直接获取到系统类加载器，并且可以判定系统类加载器的父加载器是标准扩展类加载器，但是我们试图获取标准扩展类加载器的父类加载器时却得到了null。事实上，由于启动类加载器无法被Java程序直接引用，因此JVM默认直接使用 null 代表启动类加载器。我们还是借助于代码分析一下，首先看一下java.lang.ClassLoader抽象类中默认实现的两个构造函数：
protected ClassLoader() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkCreateClassLoader();
}
//默认将父类加载器设置为系统类加载器，getSystemClassLoader()获取系统类加载器
this.parent = getSystemClassLoader();
initialized = true;
}
protected ClassLoader(ClassLoader parent) {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkCreateClassLoader();
}
//强制设置父类加载器
this.parent = parent;
initialized = true;
}
紧接着，我们再看一下ClassLoader抽象类中parent成员的声明：
// The parent class loader for delegation
private ClassLoader parent;
声明为私有变量的同时并没有对外提供可供派生类访问的public或者protected设置器接口（对应的setter方法），结合前面的测试代码的输出，我们可以推断出：
1．系统类加载器（AppClassLoader）调用ClassLoader(ClassLoader parent)构造函数将父类加载器设置为标准扩展类加载器(ExtClassLoader)。（因为如果不强制设置，默认会通过调用getSystemClassLoader()方法获取并设置成系统类加载器，这显然和测试输出结果不符。）
2．扩展类加载器（ExtClassLoader）调用ClassLoader(ClassLoader parent)构造函数将父类加载器设置为null（null 本身就代表着引导类加载器）。（因为如果不强制设置，默认会通过调用getSystemClassLoader()方法获取并设置成系统类加载器，这显然和测试输出结果不符。）
事实上，这就是启动类加载器、标准扩展类加载器和系统类加载器之间的委派关系。
4.3、类加载双亲委派实例
以上已经简要介绍了虚拟机默认使用的启动类加载器、标准扩展类加载器和系统类加载器，并以三者为例结合JDK代码对JVM默认使用的双亲委派类加载机制做了分析。下面我们就来看一个综合的例子，首先在IDE中建立一个简单的java应用工程，然后写一个简单的JavaBean如下：
package classloader.test.bean;
public class TestBean {
public TestBean() { }
}
在现有当前工程中另外建立一个测试类（ClassLoaderTest.java）内容如下：
测试一：
package classloader.test.bean;
public class ClassLoaderTest {
public static void main(String[] args) {
try {
//查看当前系统类路径中包含的路径条目
System.out.println(System.getProperty("java.class.path"));
//调用加载当前类的类加载器（这里即为系统类加载器）加载TestBean
Class typeLoaded = Class.forName("classloader.test.bean.TestBean");
//查看被加载的TestBean类型是被那个类加载器加载的
System.out.println(typeLoaded.getClassLoader());
} catch (Exception e) {
e.printStackTrace();
}
}
}/* Output:
I:\AlgorithmPractice\TestClassLoader\bin
sun.misc.Launcher$AppClassLoader@6150818a
*/
测试二：
将当前工程输出目录下的TestBean.class打包进test.jar剪贴到/lib/ext目录下（现在工程输出目录下和JRE扩展目录下都有待加载类型的class文件）。再运行测试一测试代码，结果如下：
I:\AlgorithmPractice\TestClassLoader\bin
sun.misc.Launcher$ExtClassLoader@15db9742
测试三：
将test.jar拷贝一份到/lib下，运行测试代码，输出如下：
I:\AlgorithmPractice\TestClassLoader\bin
sun.misc.Launcher$ExtClassLoader@15db9742
测试三和测试二输出结果一致。那就是说，放置到/lib目录下的TestBean对应的class字节码并没有被加载，这其实和前面讲的双亲委派机制并不矛盾。虚拟机出于安全等因素考虑，不会加载<JAVA_HOME>/lib目录下存在的陌生类，换句话说，虚拟机只加载<JAVA_HOME>/lib目录下它可以识别的类。因此，开发者通过将要加载的非JDK自身的类放置到此目录下期待启动类加载器加载是不可能的。
五、Java程序动态扩展方式
public static Class<?> forName(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException
这里的initialize参数是很重要的，它表示在加载同时是否完成初始化的工作（说明：单参数版本的forName方法默认是完成初始化的）。有些场景下需要将initialize设置为true来强制加载同时完成初始化，例如典型的就是利用DriverManager进行JDBC驱动程序类注册的问题。因为每一个JDBC驱动程序类的静态初始化方法都用DriverManager注册驱动程序，这样才能被应用程序使用。这就要求驱动程序类必须被初始化，而不单单被加载。Class.forName的一个很常见的用法就是在加载数据库驱动的时候。如 Class.forName(“org.apache.derby.jdbc.EmbeddedDriver”).newInstance()用来加载 Apache Derby 数据库的驱动。
六、常见的问题分析
1、由不同的类加载器加载的指定类还是相同的类型吗？
在Java中，一个类用其完全匹配类名(fully qualified class name)作为标识，这里指的完全匹配类名包括包名和类名。但在JVM中，一个类用其全名和一个ClassLoader的实例 作为唯一标识，不同类加载器加载的类将被置于不同的命名空间。我们可以用两个自定义类加载器去加载某自定义类型（注意不要将自定义类型的字节码放置到系统路径或者扩展路径中，否则会被系统类加载器或扩展类加载器抢先加载），然后用获取到的两个Class实例进行java.lang.Object.equals（…）判断，将会得到不相等的结果，如下所示：
public class TestBean {
public static void main(String[] args) throws Exception {
// 一个简单的类加载器，逆向双亲委派机制
// 可以加载与自己在同一路径下的Class文件
ClassLoader myClassLoader = 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 (Exception e) {
throw new ClassNotFoundException(name);
}
}
};
Object obj = myClassLoader.loadClass("classloader.test.bean.TestBean")
.newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof classloader.test.bean.TestBean);
}
}
/* Output:
class classloader.test.bean.TestBean
false
*/
我们发现，obj 确实是类classloader.test.bean.TestBean实例化出来的对象，但当这个对象与类classloader.test.bean.TestBean做所属类型检查时却返回了false。这是因为虚拟机中存在了两个TestBean类，一个是由系统类加载器加载的，另一个则是由我们自定义的类加载器加载的，虽然它们来自同一个Class文件，但依然是两个独立的类，因此做所属类型检查时返回false。
2、在代码中直接调用Class.forName(String name)方法，到底会触发那个类加载器进行类加载行为？
Class.forName(String name)默认会使用调用类的类加载器来进行类加载。我们直接来分析一下对应的jdk的代码：
//java.lang.Class.java
publicstatic Class<?> forName(String className) throws ClassNotFoundException {
return forName0(className, true, ClassLoader.getCallerClassLoader());
}
//java.lang.ClassLoader.java
// Returns the invoker's class loader, or null if none.
static ClassLoader getCallerClassLoader() {
// 获取调用类（caller）的类型
Class caller = Reflection.getCallerClass(3);
// This can be null if the VM is requesting it
if (caller == null) {
return null;
}
// 调用java.lang.Class中本地方法获取加载该调用类（caller）的ClassLoader
return caller.getClassLoader0();
}
//java.lang.Class.java
//虚拟机本地实现，获取当前类的类加载器，前面介绍的Class的getClassLoader()也使用此方法
native ClassLoader getClassLoader0();
3、在编写自定义类加载器时，如果没有设定父加载器，那么父加载器是谁？
当自定义类加载器没有指定父类加载器的情况下，默认的父类加载器即为系统类加载器。同时，我们可以得出如下结论：即使用户自定义类加载器不指定父类加载器，那么，同样可以加载如下三个地方的类：
-
<Java_Runtime_Home>/lib下的类；
-
<Java_Runtime_Home>/lib/ext下或者由系统变量java.ext.dir指定位置中的类；
-
当前工程类路径下或者由系统变量java.class.path指定位置中的类。
4、在编写自定义类加载器时，如果将父类加载器强制设置为null，那么会有什么影响？如果自定义的类加载器不能加载指定类，就肯定会加载失败吗？
JVM规范中规定如果用户自定义的类加载器将父类加载器强制设置为null，那么会自动将启动类加载器设置为当前用户自定义类加载器的父类加载器（这个问题前面已经分析过了）。同时，我们可以得出如下结论：即使用户自定义类加载器不指定父类加载器，那么，同样可以加载到<JAVA_HOME>/lib下的类，但此时就不能够加载<JAVA_HOME>/lib/ext目录下的类了。
5、编写自定义类加载器时，一般有哪些注意点？
（1）一般尽量不要覆写已有的loadClass(…)方法中的委派逻辑（Old Generation）
（2）正确设置父类加载器
（3）保证findClass(String name)方法的逻辑正确性
6、如何在运行时判断系统类加载器能加载哪些路径下的类？
一是可以直接调用ClassLoader.getSystemClassLoader()或者其他方式获取到系统类加载器（系统类加载器和扩展类加载器本身都派生自URLClassLoader），调用URLClassLoader中的getURLs()方法可以获取到。
二是可以直接通过获取系统属性java.class.path来查看当前类路径上的条目信息 ：System.getProperty(“java.class.path”)。如下所示：
public class Test {
public static void main(String[] args) {
System.out.println("Rico");
Gson gson = new Gson();
System.out.println(gson.getClass().getClassLoader());
System.out.println(System.getProperty("java.class.path"));
}
}
/* Output:
Rico
sun.misc.Launcher$AppClassLoader@6c68bcef
I:\AlgorithmPractice\TestClassLoader\bin;I:\Java\jars\Gson\gson-2.3.1.jar
*/
7、如何在运行时判断标准扩展类加载器能加载哪些路径下的类？
import java.net.URL;
import java.net.URLClassLoader;
public class ClassLoaderTest {
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
try {
URL[] extURLs = ((URLClassLoader) ClassLoader.getSystemClassLoader().getParent()).getURLs();
for (int i = 0; i < extURLs.length; i++) {
System.out.println(extURLs[i]);
}
} catch (Exception e) {
//…
}
}
}
/* Output:
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/access-bridge-64.jar
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/dnsns.jar
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/jaccess.jar
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/localedata.jar
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/sunec.jar
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/sunjce_provider.jar
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/sunmscapi.jar
file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/zipfs.jar
*/
七、开发自己的类加载器
真正完成类的加载工作是通过调用defineClass来实现的；而启动类的加载过程是通过调用loadClass来实现的。前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。在Java虚拟机判断两个类是否相同的时候，使用的是类的定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。两种类加载器的关联之处在于：一个类的定义加载器是它引用的其它类的初始加载器。
方法 loadClass()抛出的是 java.lang.ClassNotFoundException异常；方法 defineClass()抛出的是 java.lang.NoClassDefFoundError异常。
类加载器在成功加载某个类之后，会把得到的 java.lang.Class类的实例缓存起来。下次再请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。也就是说，对于一个类加载器实例来说，相同全名的类只加载一次，即 loadClass方法不会被重复调用。
在绝大多数情况下，系统默认提供的类加载器实现已经可以满足需求。但是在某些情况下，您还是需要为应用开发出自己的类加载器。比如您的应用通过网络来传输Java类的字节代码，为了保证安全性，这些字节代码经过了加密处理。这个时候您就需要自己的类加载器来从某个网络地址上读取加密后的字节代码，接着进行解密和验证，最后定义出要在Java虚拟机中运行的类来。
下面将通过两个具体的实例来说明类加载器的开发。
1、文件系统类加载器
package classloader;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
// 文件系统类加载器
public class FileSystemClassLoader extends ClassLoader {
private String rootDir;
public FileSystemClassLoader(String rootDir) {
this.rootDir = rootDir;
}
// 获取类的字节码
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] classData = getClassData(name); // 获取类的字节数组
if (classData == null) {
throw new ClassNotFoundException();
} else {
return defineClass(name, classData, 0, classData.length);
}
}
private byte[] getClassData(String className) {
// 读取类文件的字节
String path = classNameToPath(className);
try {
InputStream ins = new FileInputStream(path);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 4096;
byte[] buffer = new byte[bufferSize];
int bytesNumRead = 0;
// 读取类文件的字节码
while ((bytesNumRead = ins.read(buffer)) != -1) {
baos.write(buffer, 0, bytesNumRead);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
private String classNameToPath(String className) {
// 得到类文件的完全路径
return rootDir + File.separatorChar + className.replace('.', File.separatorChar) + ".class";
}
}
如上所示，类 FileSystemClassLoader继承自类java.lang.ClassLoader。在java.lang.ClassLoader类的常用方法中，一般来说，自己开发的类加载器只需要覆写 findClass(String name)方法即可。java.lang.ClassLoader类的方法loadClass()封装了前面提到的代理模式的实现。该方法会首先调用findLoadedClass()方法来检查该类是否已经被加载过；如果没有加载过的话，会调用父类加载器的loadClass()方法来尝试加载该类；如果父类加载器无法加载该类的话，就调用findClass()方法来查找该类。因此，为了保证类加载器都正确实现代理模式，在开发自己的类加载器时，最好不要覆写 loadClass()方法，而是覆写 findClass()方法。
类 FileSystemClassLoader的 findClass()方法首先根据类的全名在硬盘上查找类的字节代码文件（.class 文件），然后读取该文件内容，最后通过defineClass()方法来把这些字节代码转换成 java.lang.Class类的实例。加载本地文件系统上的类，示例如下：
package com.example;
public class Sample {
private Sample instance;
public void setSample(Object instance) {
System.out.println(instance.toString());
this.instance = (Sample) instance;
}
}
package classloader;
import java.lang.reflect.Method;
public class ClassIdentity {
public static void main(String[] args) {
new ClassIdentity().testClassIdentity();
}
public void testClassIdentity() {
String classDataRootPath = "C:\\Users\\JackZhou\\Documents\\NetBeansProjects\\classloader\\build\\classes";
FileSystemClassLoader fscl1 = new FileSystemClassLoader(classDataRootPath);
FileSystemClassLoader fscl2 = new FileSystemClassLoader(classDataRootPath);
String className = "com.example.Sample";
try {
Class<?> class1 = fscl1.loadClass(className); // 加载Sample类
Object obj1 = class1.newInstance(); // 创建对象
Class<?> class2 = fscl2.loadClass(className);
Object obj2 = class2.newInstance();
Method setSampleMethod = class1.getMethod("setSample", java.lang.Object.class);
setSampleMethod.invoke(obj1, obj2);
} catch (Exception e) {
e.printStackTrace();
}
}
}
/* Output:
com.example.Sample@7852e922
*/
2、网络类加载器
下面将通过一个网络类加载器来说明如何通过类加载器来实现组件的动态更新。即基本的场景是：Java 字节代码（.class）文件存放在服务器上，客户端通过网络的方式获取字节代码并执行。当有版本更新的时候，只需要替换掉服务器上保存的文件即可。通过类加载器可以比较简单的实现这种需求。
类 NetworkClassLoader负责通过网络下载Java类字节代码并定义出Java类。它的实现与FileSystemClassLoader类似。
package classloader;
import java.io.ByteArrayOutputStream;
import java.io.InputStream;
import java.net.URL;
public class NetworkClassLoader extends ClassLoader {
private String rootUrl;
public NetworkClassLoader(String rootUrl) {
// 指定URL
this.rootUrl = rootUrl;
}
// 获取类的字节码
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] classData = getClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
} else {
return defineClass(name, classData, 0, classData.length);
}
}
private byte[] getClassData(String className) {
// 从网络上读取的类的字节
String path = classNameToPath(className);
try {
URL url = new URL(path);
InputStream ins = url.openStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 4096;
byte[] buffer = new byte[bufferSize];
int bytesNumRead = 0;
// 读取类文件的字节
while ((bytesNumRead = ins.read(buffer)) != -1) {
baos.write(buffer, 0, bytesNumRead);
}
return baos.toByteArray();
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
private String classNameToPath(String className) {
// 得到类文件的URL
return rootUrl + "/" + className.replace('.', '/') + ".class";
}
}
在通过NetworkClassLoader加载了某个版本的类之后，一般有两种做法来使用它。第一种做法是使用Java反射API。另外一种做法是使用接口。需要注意的是，并不能直接在客户端代码中引用从服务器上下载的类，因为客户端代码的类加载器找不到这些类。使用Java反射API可以直接调用Java类的方法。而使用接口的做法则是把接口的类放在客户端中，从服务器上加载实现此接口的不同版本的类。在客户端通过相同的接口来使用这些实现类。我们使用接口的方式。示例如下：
客户端接口：
package classloader;
public interface Versioned {
String getVersion();
}
package classloader;
public interface ICalculator extends Versioned {
String calculate(String expression);
}
网络上的不同版本的类：
package com.example;
import classloader.ICalculator;
public class CalculatorBasic implements ICalculator {
@Override
public String calculate(String expression) {
return expression;
}
@Override
public String getVersion() {
return "1.0";
}
}
package com.example;
import classloader.ICalculator;
public class CalculatorAdvanced implements ICalculator {
@Override
public String calculate(String expression) {
return "Result is " + expression;
}
@Override
public String getVersion() {
return "2.0";
}
}
在客户端加载网络上的类的过程：
package classloader;
public class CalculatorTest {
public static void main(String[] args) {
String url = "http://localhost:8080/ClassloaderTest/classes";
NetworkClassLoader ncl = new NetworkClassLoader(url);
String basicClassName = "com.example.CalculatorBasic";
String advancedClassName = "com.example.CalculatorAdvanced";
try {
Class<?> clazz = ncl.loadClass(basicClassName); // 加载一个版本的类
ICalculator calculator = (ICalculator) clazz.newInstance(); // 创建对象
System.out.println(calculator.getVersion());
clazz = ncl.loadClass(advancedClassName); // 加载另一个版本的类
calculator = (ICalculator) clazz.newInstance();
System.out.println(calculator.getVersion());
} catch (Exception e) {
e.printStackTrace();
}
}
}