JVM-类加载子系统

一、类的加载过程

在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载,，按照Java虚拟机规范，class文件从开始加载，到加载到内存中的类，到类卸载出内存为止，它的整个生命周期包括如下7个阶段：

其中，验证、准备、解析3个部分统称为链接(Linking)，从程序中类的使用过程来分，如下图所示：

1. 类的加载阶段

1.1 基础知识

• 加载的理解：所谓加载，简而言之就是将Java类的字节码文件加载到机器内存中，并在内存中构建出Java类的原型一一类模板对象。 类模板对象就是Java类在JVM内存中的一个快照，JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样JVM在运行期便能通过类模板而获取Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用。反射的机制即基于这一基础。 如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射。
• 加载完成的操作：加载阶段，简言之，查找并加载类的二进制数据，生成Class的实例。在加载类时，Java虚拟机必须完成以下3件事情:① 通过类的全名，获取类的二进制数据流。② 解析类的二进制数据流为方法区内的数据结构（Java类模型）。③ 创建java.lang.Class类的实例， 表示该类型。作为方法区这个类的各种数据的访问入口。

1.2 二进制流获取方式

只要所读取的字节码符合JVM规范即可，具体方式如下：

• 虚拟机可能通过文件系统读入一个class后缀的文件 （最常见）。
• 读入jar、zip等归档数据包，提取类文件。
• 事先存放在数据库中的类的二进制数据。
• 使用类似于HTTP之类的协议通过网络进行加载。
• 在运行时生成一段Class的二进制信息等。

在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为个java.lang.Class的实例。如果输入数据不是ClassFile的结构，则会抛出ClassFormatError。

1.3 类模型与Class实例的位置

• 类模型的位置：加载的类在JVM中创建相应的类结构，类结构会存储在方法区（JDK1.8之前为永久代; JDK1.8及之后为元空间）。
• Class实例的位置：类将.class文件加载至元空间后，会在堆中创建一个Java.lang.Class对象，用来封装类位于方法区内的数据结构，该Class对象是在加载类的过程中创建的，每个类都对应有一个Class类型的对象，该对象在堆里，引用指向方法区。
• 外部可以通过访问代表指定类的Class对象来获取该类的类数据结构。
• Class类的构造方法是私有的，只有JVM能够创建。java.lang.Class实例是访问类型元数据的接口，也是实现反射的关键数据、入口。通过Class类提供的接口，可以获得目标类所关联的.class文件中具体的数据结构，比如方法、字段等信息。

1.4 数组的创建

• 创建数组类的情况稍微有些特殊，因为数组类本身并不是由类加载器负责创建，而是由JVM在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类加载器去创建。创建数组类（下述简称A）的过程：① 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型。② JVM使用指定的元素类型和数组维度来创建新的数组类。
• 如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。

2. 类的链接阶段

2.1 验证

当类加载到系统后，就开始链接操作，验证是链接操作的第一步。它的目的是保证加载的字节码是合法、合理并符合规范的。验证的步骤比较复杂，实际要验证的项目也很繁多，个大体上Java虛拟机需要做以下检查，如图所示。

验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证，以及符号引用验证等。其中格式验证会和加载阶段一起执行，验证通过之后，类加载器才会成功将类的二进制数据信息加载到方法区中。格式验证之外的验证操作将会在方法区中进行。链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行各种检查。

• 格式验证：是否以魔数0xCAFEBABE开头，主版本和副版本号是否在当前Java虛拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。
• 语义检查：Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给子验证通过。比如① 是否所有的类都有父类的存在（在Java里，除了Object外， 其他类都应该有父类）。② 是否一些被定义为final的方法或者类被重写或继承了。③ 非抽象类是否实现了所有抽象方法或者接口方法。④ 是否存在不兼容的方法（比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度或者abstract情况下的方法，就不能是final的了)。
• 字节码验证：Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：① 在字节码的执行过程中，是否会跳转到一条不存在的指令。② 函数的调用是否传递了正确类型的参数。③ 变量的赋值是不是给了正确的数据类型等。
  附加：栈映射帧(StackMapTable)就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的。
• 在前面3次检查中，已经排除了文件格式错误、语义错误以及字节码的不正确性。但是依然不能确保类是没有问题的。
• 符号引用验证：校验器还将进行符号引用的验证，class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个 方法无法被找到，则会抛出NoSuchMethodError（注意：此阶段在解析环节才会执行）。

2.2 准备

• 准备阶段(Preparation)，简言之，为类的静态变量分配内存，并将其初始化为默认值。当一个类验证通过时，虚拟机就会进入准备阶段。在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值。
• 注意: Java并不支持boolean类型，对于boolean类型，内部实现是int，由于int的默认值是0，故对应的，boolean的默认值就是false。
• 注意：① 这里不包含基本数据类型的字段用static final修饰和String类型数据使用字面量的方式赋值并用static final修饰的情况，因为此时，final在编译的时候就会分配内存了，准备阶段会显式赋值。② 这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。③ 在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。

2.3 解析

• 在准备阶段完成后，就进入了解析阶段。解析阶段(Resolution)，简言之，将类、接口、字段和方法的符号引用转为直接引用。符号引用就是一些字面量的引用，和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的，比如当如下println()方法被调用时，系统需要明确知道该方法的位置。
• 举例：输出操作System.out .println()对应的字节码:invokevirtual #24 <java/io/PrintStream. printIn>，Java 虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中，当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作，符号引用就可以转变为目标方法在类中方法表中的位置，从而使得方法被成功调用。
  
• 所谓解析就是将符号引用转为直接引用，也就是得到类、字段、方法在内存中的指针或者偏移量。因此，可以说，如果直接引用存在，那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用，不能确定系统中定存在该结构。
• 不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpotVM中，加载、验证、准备和初始化会按照顺序有条不紊地执行，但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。
• 字符串的复习：最后，再来看一下CONSTANT String的解析。由于字符串在程序开发中有着重要的作用，因此，读者有必要了解一下。String在Java虚拟机中的处理。当在Java代码中直接使用字符串常量时，就会在类中出现CONSTANT_String, 它表示字符串常量，并且会引用一个CONSTANT_UTF8的常量项。在Java虚拟机内部运行中的常量池中，会维护一张字符串拘留表(intern)，它会保存所有出现过的字符串常量，并且没有重复项。只要以CONSTANT_String形式出现的字符串也都会在这张表中。使用String.intern()方法可以得到一个字符串在拘留表中的引用，因为该表中没有重复项，所以任何字面相同的字符串的String.intern()方法返回总是相等的。

3. 类的初始化阶段

3.1 基础知识

• 初始化阶段，简言之，为类的静态变量赋予正确的初始值。类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码（即：到了初始化阶段，才真正开始执行类中定义的Java 程序代码)。
• 初始化阶段的重要工作是执行类的初始化方法：<clinit>()方法。该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成。它是由类静态成员的赋值语句以及static语句块合并产生的。
• 在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<clinit>总是在子类<clinit>之前被调用。也就是说，父类的static块优先级高于子类。口诀即由父及子，静态先行。
• Java编译器并不会为所有的类都产生<clinit>()初始化方法。哪些类在编译为字节码后，字节码文件中将不会包含<clinit>()方法？① 一个类中并没有声明任何的类静态变量，也没有静态代码块时。② 一个类中声明类变量，但是没有明确使用类静态变量的初始化语句以及静态代码块来执行初始化操作时 ③一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式。
• 使用static + final修饰的字段的显式赋值的操作，到底是在哪个阶段进行的赋值（① 在链接阶段的准备环节赋值② 在初始化阶段<clinit>()中赋值）？答：使用static + final修饰，且显示赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值，是在链接阶段的准备环节进行。其他情况，都是在初始化阶段<clinit>()中赋值。

public class InitializationTest2 {
	public static int a = 1;// 在初始化阶段<clinit>()中赋值
	public static final int INT_CONSTANT = 10;// 在链接阶段的准备环节赋值
	public static final Integer INTEGER_CONSTANT1 = Integer.value0f(100);//在初始化阶段<clinit>()中赋值
	public static Integer INTEGER_CONSTANT2 = Integer.value0f(1000);//在初始化阶段<clinit>()中赋值
	public static final String s0 = "helloworld0";// 在链接阶段的准备环节赋值
	public static final String s1 = new String(original: "helloworld1");// 在初始化阶段<clinit>()中赋值
	public static String s2 = "helloworld2";// 在初始化阶段<clinit>()中赋值
	public static final int NUM1 = new Random().nextInt( bound: 10);// 在初始化阶段<clinit>()中赋值
}

3.2 clinit方法的线程安全性

• 对于<clinit>()方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性。
• 虚拟机会保证每个类的<clinit>()方法在多线程环境中被正确地加锁、同步（注意此时加的锁是隐式锁，不是使用synchronized进行显式的控制的，字节码中没有synchronized的标识），如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。
• 正是因为函数<clinit>()带锁线程安全的，因此，如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，引发死锁。并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息。
• 如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了。那么，当需要使用这个类时，虚拟机会直接返回给它已经准备好的信息。

3.3 类的使用

Java程序对类的使用分为两种：主动使用和被动使用。主动使用时，会进行类的初始化阶段（调用类的<clinit>()方法），被动使用时，不会进行类的初始化阶段（不会调用类的<clinit>()方法），注意，如果使用了类，一定要进行加载，但并不一定会进行初始化。

3.3.1 主动使用

1. 当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化。
2. 当调用类的静态方法时，即当使用了字节码invokestatic指令。
3. 当使用类、接口的静态字段时，比如，使用getstatic或者putstatic指令（对应访问变量、赋值变量操作）。对于final修饰特殊考虑，如果final修饰的静态量需要在初始化阶段完成赋值，则会调用类的<clinit>()方法，否则不会调用。
4. 当使用java.lang.reflect包中的方法反射类的方法时。比如: Class.forName(“com.atguigu.java.Test”)
5. 当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。注意：当Java虛拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则并不适用于接口。在初始化一个类时，并不会先初始化它所实现的接口。在初始化一个接口时，并不会先初始化它的父接口。因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。
6. 如果一个接口定义了default方法， 那么直接实现或者间接实现该接口的类的初始化之前要初始化该接口。
7. 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。注意：JVM启动的时候通过引导类加载器加载一个初始类。这个类在调用public static void main(String[])方法之前被链接和初始化。这个方法的执行将依次导致所需的类的加载，链接和初始化。
8. 当初次调用MethodHandle实例时，初始化该MethodHandle指向的方法所在的类 (涉及解析REF_getStatic、REF_ putStatic、 REF_invokeStatic方法句柄对应的类)。

3.3.2 被动使用

除了以上的情况属于主动使用，其他的情况均属于被动使用。被动使用不会引起类的初始化。也就是说并不是在代码中出现的类，就一定会被加载或者初始化。如果不符合主动使用的条件，类就不会初始化。

1. 当访问一个静态字段时，只有真正声明这个字段的类才会被初始化。比如当通过子类引用父类的静态变量，不会导致子类初始化。
2. 通过数组定义类引用，不会触发此类的初始化。
3. 引用常量不一定会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。这个具体的细节在上面已经说清楚了。
4. 调用ClassLoader类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化。

4. 类的使用阶段

任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后，便“万事俱备，只欠东风”，就等着开发者使用了。开发人员可以在程序中访问和调用它的静态类成员信息（比如静态字段、静态方法），或者使用new关键字为其创建对象实例。

5. 类的卸载阶段

5.1 类、类的加载器、类的实例之间的引用关系

• 在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法， 就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。
• 一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。

5.2 类的生命周期

当Sample类被加载、链接和初始化后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期。一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。

5.3 举例

loader1变量和obj变量间接引用代表Sample类的Class对象，而objClass变量则直接引用它。如果程序运行过程中，将上图左侧三个引用变量都置为null， 此时Sample对象结束生命周期，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据被卸载。当再次有需要时，会检查Sample类的Class对象是否存在， 如果存在会直接使用，不再重新加载，如果不存在Sample类会被重新加载，在Java虛拟机的堆区会生成一个新的代表Sample类的Class实例（可以通过哈希码查看是否是同一个实例）。

5.4 类的卸载概率

• 启动类加载器加载的类型在整个运行期间是不可能被卸载的（jvm和j1s规范）。
• 被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小。
• 被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中（比如很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能），被加载的类型在运行期间也是几乎不太可能被卸载的（至少卸载的时间是不确定的)。

5.5 回顾：方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型。HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。判定一个常量是否“废弃”还是相对简单，而要判定一个类型 是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：
① 该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例。
② 加载该类的类加载器已经被回收。这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
③ 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。

二、类的加载器

1. 概述

1.1 加载器概述

• 类加载器是JVM执行类加载机制的前提。
• ClassLoader的作用：① ClassLoader是Java的核心组件， 所有的Class都是由ClassLoader进行加载的，ClassLoader负责将通过各种方式获得的含有Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。
• ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的链接和初始化行为。至于类是否可以运行，则由Execution Engine决定。
• 类加载器最早出现在Java1.0版本中，那个时候只是单纯地为了满足Java Applet应用而被研发出来。但如今类加载器却在OSGi、字节码加解密领域大放异彩。这主要归功于Java虚拟机的设计者们当初在设计类加载器的时候，并没有考虑将它绑定在JVM内部，这样做的好处就是能够更加灵活和动态地执行类加载操作。

1.2 加载概述

类的加载分为显式加载和隐式加载，class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。① 显式加载指的是在代码中通过调用ClassLoader加载class对象，如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载class对象。② 隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载到内存中。在日常开发中，以上两种方式一般会混合使用。

1.3 了解加载器的必要性

• 避免在开发中遇到java.lang.ClassNotFoundException异常或java.lang.NoClassDefFoundError异常时手足无措。只有了解类加载器的加载机制才能够在出现异常的时候快速地根据错误异常日志定位问题和解决问题。
• 需要支持类的动态加载或需要对编译后的字节码文件进行加解密操作时，就需要与类加载器打交道了。
• 开发人员可以在程序中编写自定义类加载器来重新定义类的加载规则，以便实现一些自定义的处理逻辑。

1.4 命名空间

• 何为类的唯一性？对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一一性。每一个类加载器，都拥有一个独立的类名称空间。比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载不同，那这两个类就必定不相等。
• 命名空间：每个类加载器都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成，在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类，在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类。在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本。

1.5 类加载机制的基本特征

1. 双亲委派模型：不是所有类加载都遵守这个模型。
2. 可见性：子类加载器可以访问父加载器加载的类型，但是反过来是不允许的。不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑。
3. 单一性：由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载但是注意，类加载器“邻居”间，同一类型仍然可以被加载多次，因为互相并不可见。

2. 分类

JVM支持两种类型的类加载器，分别为引导类加载器(Bootstrap ClassLoader) 和自定义类加载器(User-Defined ClassLoader) 。从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分，在程序中我们最常见的类加载器结构主要是如下情况：

除了顶层的启动类加载器外，其余的类加载器都应当有自己的“父类”加载器。不同类加载器看似是继承(Inheritance)关系，实际上是包含关系。在下层加载器中，包含着上层加载器的引用。

2.1 引导类加载器（启动类加载器）(BootstrapClassLoader)

• 这个类加载使用C/C++语言实现的，嵌套在JVM内部。
• 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar或sun.boot.class.path路径下的内容）用于提供JVM自身需要的类。
• 并不继承自java.lang.ClassLoader，没有父加载器。
• 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类。
• 引导类加载器还用于加载扩展类和应用程序类加载器，并指定为他们的父类加载器。

2.2 扩展类加载器(ExtensionClassLoader)

• Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。
• 继承于ClassLoader类。
• 父类加载器为启动类加载器。
• 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

2.3 系统类加载器(AppClassLoader)

• Java语言编写，由sun.misc.Launcher$AppClassLoader实现。
• 继承于ClassLoader类。
• 父类加载器为扩展类加载器。
• 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库。
• 应用程序中的类加载器默认是系统类加载器（自定义的类结构，都是使用该加载器进行加载的）。
• 它是用户自定义类加载器的默认父加载器。
• 通过ClassLoader的getSystemClassLoader()方法可以获取到该类加载器。

2.4 用户自定义类加载器

• 在Java的日常应用程序开发中， 类的加载几乎是由上述3种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式。
• Java语言拥有强大生命力和巨大魅力的关键因素之一便是，Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包， 也可以是网络上的远程资源。
• 通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。
• 同时，自定义加载器能够实现应用隔离，例如Tomcat、Spring等 中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好太多，想不修改C/C++程序 就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想。
• 自定义类加载器通常需要继承于ClassLoader.。

2.5 注意

• 数组类型的加载使用的类的加载器与数组元素的类的加载器相同，如果是基本数据类型的数组，则无需进行加载，因为基本数据类型就是由虚拟机预先定义的，本身就无需加载。
• 获得当前类的ClassLoader：clazz.getClassLoader()。
• 获得当前线程上下文的ClassLoader：Thread.currentThread().getContextClassLoader()，默认情况下就是系统类加载器。
• 获得系统的ClassLoader：ClassLoader. getSystemClassLoader()。

3. 源码分析

3.1 ClassLoader与现有的类加载器的继承关系

除了以上虚拟机自带的加载器外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。此外，由于BootstrapClassLoader是用C/C++编写的，所以不在以上的继承关系中。

3.2 Launcher

public Launcher() {
    Launcher.ExtClassLoader var1;
    try {
        var1 = Launcher.ExtClassLoader.getExtClassLoader();
    } catch (IOException var10) {
        throw new InternalError("Could not create extension class loader", var10);
    }

    try {
        this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
    } catch (IOException var9) {
        throw new InternalError("Could not create application class loader", var9);
    }

    Thread.currentThread().setContextClassLoader(this.loader);
    String var2 = System.getProperty("java.security.manager");
    if (var2 != null) {
        SecurityManager var3 = null;
        if (!"".equals(var2) && !"default".equals(var2)) {
            try {
                var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();
            } catch (IllegalAccessException var5) {
            } catch (InstantiationException var6) {
            } catch (ClassNotFoundException var7) {
            } catch (ClassCastException var8) {
            }
        } else {
            var3 = new SecurityManager();
        }

        if (var3 == null) {
            throw new InternalError("Could not create SecurityManager: " + var2);
        }

        System.setSecurityManager(var3);
    }

}

ExtClassLoader和AppClassLoader都是Launcher的内部类可以看到，在Launcher的构造器中，创建了ExtClassLoader和AppClassLoader的实例（在创建时就设置了其parent属性的值），并且将上下文加载器设置为AppClassLoader。

3.3 ClassLoader中的方法

3.3.1 getParent方法

//ClassLoader中的方法
private final ClassLoader parent;
public final ClassLoader getParent() {
      if (parent == null)
          return null;
      SecurityManager sm = System.getSecurityManager();
      if (sm != null) {
          // Check access to the parent class loader
          // If the caller's class loader is same as this class loader,
          // permission check is performed.
          checkClassLoaderPermission(parent, Reflection.getCallerClass());
      }
      return parent;
  }

返回该类的parent属性。

3.3.2 loadClass(String name)方法

//ClassLoder中的方法
public Class<?> loadClass(String name) throws ClassNotFoundException {
    return loadClass(name, false);
}

protected Class<?> loadClass(String name, boolean resolve)//resolve为true表示加载的同时进行解析，false就是不需要进行解析
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {//同步操作，保证只能加载一次
        // First, check if the class has already been loaded
        //在缓存中判断是否已经加载了同名的类（命名空间内不允许出现重复的类）
        Class<?> c = findLoadedClass(name);
        if (c == null) {//未加载过则走如下逻辑
            long t0 = System.nanoTime();
            try {
                if (parent != null) {//判断父类加载器是否存在（当前类的父类加载器是否为启动类加载器），存在（不是）则递归调用父类的loadClass(name, false)方法
                    c = parent.loadClass(name, false);
                } else {//不存在（是）则启动启动类加载器的加载方法
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }

            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                //能进入该逻辑只可能是两种情况：① (parent != null)当前加载器的父类加载器未加载 ② (parent == null)当前类的加载器未加载。
                long t1 = System.nanoTime();
                //调用当前ClassLoader的findClass(name)方法，真正开始进行类的加载
                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;
    }
}
/**
 * Returns a class loaded by the bootstrap class loader;
 * or return null if not found.
 */
private Class<?> findBootstrapClassOrNull(String name)
{
    if (!checkName(name)) return null;//加载过或不可以加载

    return findBootstrapClass(name);//未加载过且可以加载则加载
}

加载名称为name的类，返回结果为java.lang.Class类的实例。如果找不到类，则返回ClassNotFoundException异常。该方法中的逻辑就是双亲委派模式的实现。

3.3.3 findClass(String name)方法

//抽象类ClassLoader内的findClass(String name)方法
protected Class<?> findClass(String name) throws ClassNotFoundException {
    throw new ClassNotFoundException(name);
}
//URLClassLoader子类中重写了findClass(String name)方法
protected Class<?> findClass(final String name)
    throws ClassNotFoundException
{
    final Class<?> result;
    try {
        result = AccessController.doPrivileged(
            new PrivilegedExceptionAction<Class<?>>() {
                public Class<?> run() throws ClassNotFoundException {
                    String path = name.replace('.', '/').concat(".class");
                    Resource res = ucp.getResource(path, false);
                    if (res != null) {
                        try {
                            return defineClass(name, res);
                        } catch (IOException e) {
                            throw new ClassNotFoundException(name, e);
                        }
                    } else {
                        return null;
                    }
                }
            }, acc);
    } catch (java.security.PrivilegedActionException pae) {
        throw (ClassNotFoundException) pae.getException();
    }
    if (result == null) {
        throw new ClassNotFoundException(name);
    }
    return result;
}

findClass(String name)方法用于查找二进制名称为name的类，返回结果为java.lang.Class类的实例。这是一个受保护的方法，JVM鼓励我们重写此方法，需要自定义加载器遵循双亲委托机制，该方法会在检查完父类加载器之后被loadclass()方法调用。
在JDK1.2之前，在自定义类加载时，总会去继承ClassLoader类并重写loadClass方法，从而实现自定义的类加教类。但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中，从前面的分析可知，findClass()方法是在loadClass()方法中被调用的，当loadClass()方法中父加载器加载失败后，则会调用自己的findClass()方法来完成类加载，这样就可以保证自定义的类加载器也符合双亲委托模式。
需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑，取而代之的是抛出ClassNotFoundException异常，同时应该知道的是findClass方法通常是和defineClass方法一起使用的。一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法生成类的Class对象。

3.3.4 defineClss(String name, btye[] b,int off, int len)方法

//URLClassLoader中的方法，会调用父类的同命不同参的方法，最后会调到ClassLoader中的同名不同参的方法
private Class<?> defineClass(String name, Resource res) throws IOException {
    long t0 = System.nanoTime();
    int i = name.lastIndexOf('.');
    URL url = res.getCodeSourceURL();
    if (i != -1) {
        String pkgname = name.substring(0, i);
        // Check if package already loaded.
        Manifest man = res.getManifest();
        definePackageInternal(pkgname, man, url);
    }
    // Now read the class bytes and define the class
    java.nio.ByteBuffer bb = res.getByteBuffer();
    if (bb != null) {
        // Use (direct) ByteBuffer:
        CodeSigner[] signers = res.getCodeSigners();
        CodeSource cs = new CodeSource(url, signers);
        sun.misc.PerfCounter.getReadClassBytesTime().addElapsedTimeFrom(t0);
        return defineClass(name, bb, cs);
    } else {
        byte[] b = res.getBytes();
        // must read certificates AFTER reading bytes.
        CodeSigner[] signers = res.getCodeSigners();
        CodeSource cs = new CodeSource(url, signers);
        sun.misc.PerfCounter.getReadClassBytesTime().addElapsedTimeFrom(t0);
        return defineClass(name, b, 0, b.length, cs);
    }
}

根据给定的字节数组b转换为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，其中byte数组b是ClassLoader从外部获取的。这是受保护的方法，只有在自定义ClassLoader子类中可以使用。
defineClass()方法是用来将byte字节流解析成VM能够认别的Class对象（ClassLoader中已实现该方法逻辑），通过这个方法不仅能够通过class文件实例化class对象，也可以通过其他方式实例化class对象，如通过网络接收一个类的字节码，然后转换为byte字节流创建对应的Class对象。
defineClass()方法通常与findClass()方法一起使用，一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法法生成类的Class对象。

3.3.5 其他方法

• protected final void resolveclass(class<?> c)
  链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析。前面我们说链接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。
• protected final class<?> findLoadedClass(string name)
  查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例。这个方法是final方法，无法被修改。
• private final classLoader parent;
  它也是一个ClassLoader的实例，这个字段所表示的ClassLoader也称为这个ClassLoader的双亲。在类加载的过程中,classLoader可能会将某些请求交予自己的双亲处理。

3.4 ClassLoader子类的说明

3.4.1 SecureClassLoader

SecureClassLoader扩展了ClassLoader，新增了几个与使用相关的代码源（对代码源的位置及其证书的验证）和权限定义类验证（主要指对class源码的访问权限）的方法，一般我们不会直接跟这个类打交道，更多是与它的子类URLClassLoader有所关联。

3.4.2 URLClassLoader

ClassLoader是一个抽象类，很多方法是空的没有实现，比如 findClass()、findResource()等。而URLClassLoader这个实现类为这些方法提供了具体的实现。并新增URLClassPath类协助取得Class字节码流等功能。在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

3.4.3 拓展类加载器ExtClassLoader和系统类加载器AppClassLoader

这两个类都继承自URLClassLoader，是sun.misc.Launcher的静态内部类。sun.misc.Launcher主要被系统用于启动主应用程序，ExtClassLoader和AppClassLoader都是由sun.misc.Launcher创建的。ExtClassLoader并没有重写loadClass()方法，这足矣说明其遵循双亲委派模式，而AppClassLoader重载了loadClass()方法，但最终调用的还是父类loadclass()方法，因此依然遵守双亲委派模式。

3.4.4 补充：Class.forName() 与ClassLoader.loadClass()区别

• Class.forName()是一个静态方法,最常用的是Class.forName(String className)，根据传入的类的全限定名返回一个Class对象。该方法在将.class文件加载到内存的同时，会执行类的初始化。
• ClassLoader.loadClass()是一个实例方法，需要一个ClassLoader对象来调用该方法。该方法将Class文件加载到内存时，并不会执行类的初始化，直到这个类第一次使用时才进行初始化。

4. 双亲委派机制

4.1 基本介绍

• 引入：类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。
• 定义：如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。
• 本质：规定了类加载的顺序是引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

4.2 优缺点

• 优点：① 保证字节码文件不会被不同的类加载器重复加载，确保一个类的全局唯一性。② 保护程序安全，防止核心API被随意篡改。
• 缺点：双亲委派的委托是单向的，只能从下向上，这就导致了顶层的ClassLoader无法访问底层的ClassLoader所加载的类，也就是说，如果我们自定义的User类中调用了String类，User类是由系统类加载器加载，此时如果想加载String类可以层层委托到启动类加载器对String类进行加载，但是如果启动类加载器加载的类，需要底层的实现即需要底层的加载器加载的类，是无法从启动类加载器委托到底层的加载器的，比如启动类加载器加载的JDBC的类想调用系统类加载器加载的mysql的实现是不可以的。
• 注意：Java虚拟机规范并没有明确要求类的加载机制一定要使用双亲委派模型。

4.3 三次双亲委派的打破

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到ava模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。

4.3.1 第一次：JDK1.2前不存在双亲委派

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

4.3.2 第二次：上下文加载器

• 双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？
• 首先，明确这并非是不可能出现的事情，一个典型的例子便是JNDI服务,JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理,它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口(Service Provider Interface, SPI)的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的(SPI：在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI)，为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计，即线程上下文类加载器(Thread ContextClassLoaden)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派榄型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。
• 默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。

4.3.3 第三次：代码热替换和模块热部署

• 双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如:代码热替换(Hot Swap)、模块热部署(Hot Deployment)等。
• IBM公司主导的JSR-291（即OSGi R4.2）实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。

5. 自定义类加载器

5.1 自定义类加载器的必要性

5.1.1 为什么要自定义类加载器

1. 隔离加载类：在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如Tomcat这类web应用服务器，内部自定义了好几种类加载器，用于隔离同一个web应用服务器上的不同应用程序。
2. 修改类加载的方式：类的加载模型并非强制，余Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载。
3. 扩展加载源：比如从数据库、网络、甚至是电视机机顶盒进行加载。
4. 防止源码泄漏：Java代码容易被编译和篡改，可以进行编译加密，那么类加载也需要自定义，还原加密的字节码。

5.1.2 常见的场景

1. 实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是Java EE和OSGi、JPMS等框架。
2. 应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统，或者是需要自己操纵字节码，动态修改或者生成类型。

5.1.3 注意

在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情，因为在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能为型转换，否则转换时会发生异常。

5.2 自定义类加载器的代码实现

5.2.1 实现方式

Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该直接或间接的继承于ClassLoader类。在自定义ClassLoader的子类时候，我们常见的会有两种做法：① 方式一：重写loadClass()方法。② 方式二（推荐）：重写findClass()方法。

5.2.1 方式对比

• 这两种方式本质上差不多，因为loadClass()也会调用findClass()，但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法，根据参数指定类的名字，返回对应的Class对象的引用。
• loadClass()这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法会导致模型被破坏，容易造成问题。因此我们最好是在双亲委派模型框架内进行小范围的改动，不破坏原有的稳定结构。同时，也避免了自己重写loadClass()方法的过程中必须写双亲委托的重复代码，从代码的复用性来看，不直接修改这个方法始终是比较好的选择。
• 当编写好自定义类加载器后，便可以在程序中调用loadClass()方法来实现类加载操作。

5.2.3 说明

• 自定义类加载器的父类加载器是系统类加载器。
• JVM中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)接口（自定义类加载器并重写java.lang.ClassLoader.loadClass(String)接口的除外），连JDK的核心类库也不能例外。