类的生命周期和加载过程
在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。引用类型，Java 将其细分为四种：类、接口、数组类和泛型参数。由于泛型参数会在编译过程中被擦除，因此 Java 虚拟机实际上只有前三种。在类、接口和数组类中，数组类是由 Java 虚拟机直接生成的，其他两种则有对应的字节流。
按照Java虚拟机规范，从class文件到加载到内存中的类，到类卸载出内存为止，它的整个生命周期包括如下7个阶段：分别是加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）、卸载（Unloading）。其中，验证、准备、解析3个部分统称为链接（Linking）
其中前五个部分（加载，验证，准备，解析，初始化）统称为类加载，也称为类加载器子系统。
1）加载：
根据 class 完全限定名, 来获取二进制 classfile 格式的字节流，即找到文件系统中/jar 包中/或存在于任何地方的“class 文件”。 如果找不到二进制表示形式，则会抛出 NoClassDefFound 错误。对于数组类来说，它并没有对应的字节流，而是由 Java 虚拟机直接生成的。将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。在堆内存中生成一个代表这个类的 java.lang.Class 对象，用来封装类位于方法区内的数据结构，作为方法区这个类的各种数据的访问入口。该Class对象是在加载类的过程中创建的，每个类都对应有一个Class类型的对象。Class类的构造方法是私有的，只有JVM能够创建。 java.lang.Class 实例是访问类型元数据的接口，也是实现反射的关键数据、入口。通过Class类提供的接口，可以获得目标类所关联的.class文件中具体的数据结构：方法、字段等信息。
Class文件的来源：
- 从本地系统中直接加载
- 通过网络获取，典型场景：Web Applet
- 从zip压缩包中读取，这很常见，成为日后jar、ear、war格式的基础
- 运行时计算生成，使用最多的是：动态代理技术
- 由其他文件生成，典型场景：JSP应用
- 从专有数据库中提取.class文件，比较少见，例如有些中间件服务器（如SAP Netweaver）可以选择吧程序安装到数据库中来完成程序代码在集群间的分发
- 从加密文件中获取，典型的防Class文件被反编译的保护措施，通过加载时解密Class文件来保障程序运行逻辑不被窥探
加载阶段并不会检查 classfile 的语法和格式。 类加载的整个过程主要由 JVM 和 Java 的类加载系统共同完成， 具体点就是由 JVM 与具体的某一个类加载器（java.lang.classLoader）共同完成的。classLoader 只负责class 文件的加载，至于它是否可以运行，则由执行引擎（Execution Engine）决定。加载的类信息存放于一块称为方法区的内存空间（JDK1.8之前：永久代；JDK1.8及之后：元空间）。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）。
创建数组类的情况稍微有些特殊，因为数组类本身并不是由类加载器负责创建，而是由JVM在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类加载器去创建。创建数组类的过程：
- 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组的元素类型；
- JVM使用指定的元素类型和数组维度来创建新的数组类。
如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。
2）校验（验证）：
链接过程的第一个阶段是 校验，确保 class 文件里的字节流信息符合当前虚拟机的要求，保证被加载类的正确性，不会危害虚拟机的安全。主要包括四种验证：文件格式验证，语义验证，字节码验证，符号引用验证。
- 格式验证：魔数检查、版本检查、长度检查
- 语义验证：是否继承final、是否有父类、抽象方法是否有实现
- 字节码验证：跳转指令是否指向正确位置，操作数类型是否合理
- 符号引用验证：符号引用的直接引用是否存在
格式验证：
验证是否以魔数 0×CAFEBABE开头，主版本和副版本号是否在当前Java虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。
语义验证：
Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给予验证通过。比如：
- 是否所有的类都有父类的存在（在Java里，除了Object外，其他类都应该有父类）
- 是否一些被定义为final的方法或者类被重写或继承了
- 非抽象类是否实现了所有抽象方法或者接口方法
- 是否存在不兼容的方法（比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度：abstract情况下的方法，就不能是final的了）
字节码验证
Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：
- 在字节码的执行过程中，是否会跳转到一条不存在的指令
- 函数的调用是否传递了正确类型的参数
- 变量的赋值是不是给了正确的数据类型等
栈映射帧（StackMapTable）就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的。
符号引用验证
校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类由权限访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个方法无法被找到，则会抛出NoSuchMethodError。此阶段在解析环节才会执行。
总结
其中格式验证会和加载阶段一起执行。验证通过之后，类加载器才会成功将类的二进制数据信息加载到方法区中。格式验证之外的验证操作将会在方法区中进行。链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行的各种检查。
校验过程检查 classfile 的语义，判断常量池中的符号，并执行类型检查， 主要目的是判断字节码的合法性，比如 magic number, 对版本号进行验证。 这些检查过程中可能会抛出 VerifyError， ClassFormatError或 UnsupportedClassVersionError。
因为 classfile 的验证属是链接阶段的一部分，所以这个过程中可能需要加载其他类，在某个类的加载过程中，JVM 必须加载其所有的超类和接口。
如果类层次结构有问题（例如，该类是自己的超类或接口,死循环了），则 JVM 将抛出 ClassCircularityError。 而如果实现的接口并不是一个 interface，或者声明的超类是一个 interface，也会抛出 IncompatibleClassChangeError。
3）准备
然后进入准备阶段，这个阶段会为类中定义的变量（即静态变量，被static修饰的变量）分配内存并且设置该类变量的默认初始值，即零值。此时，实例对象还没有分配内存，这些变量所使用的内存是在方法区中进行分配的。
Java虚拟机为各类型变量默认的初始值如表所示。
| 类型 | 默认初始值 |
| byte | （byte）0 |
| short | （short）0 |
| int | 0 |
| long | 0L |
| float | 0.0f |
| double | 0.0 |
| char |
\u0000 |
| boolean | false |
| reference | null |
Java并不支持boolean类型，对于boolean类型，内部实现是int，由于int的默认值是0，故对应的，boolean的默认值就是false。
注意：方法区本身时一个逻辑上的区域，在JDK 7之前，HotSpot使用永久代来实现方法区时，实现是符合逻辑概念的；而在JDK 7及之后，类变量会随着Class对象一起存放在Java 堆中，这时候“类变量在方法区”就完全是一种对逻辑概念的表述了。这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化；这里不会为实例变量分配内存，也不会初始化，类变量会分配在方法区中，而实例变量是会在对象实例化时随着对象一起分配到Java堆中。类变量有两次赋初始值的过程，一次在准备阶段，赋予初始值（也可以是指定值）；另外一次在初始化阶段，赋予程序员定义的值。
请注意，准备阶段并不会像初始化阶段中那样会有初始化或者代码被执行。
例如：
public static int i = 1；
在准备阶段i的值会被初始化为 0，因为这时尚未开始执行任何 Java 方法，而吧 i 赋值为 1 的 putstatic 指令是程序被编译后，存放于类构造器<clinit>() 方法之中，所以在类初始化阶段才会执行赋值为 1；但是下面如果使用 final 作为静态常量，某些 JVM 的行为就不一样了：
public static final int i =1；
对应常量 i，编译时 Javac 将会为 i 生成 ConstantValue 属性，在准备阶段虚拟机就会根据ConstantValue 的设置将 i 赋值为 1，其实这样还是比较 puzzle，例如其他语言（C#）有直接的常量关键字 const，让告诉编译器在编译阶段就替换成常量，类似于宏指令，更简单。
基本数据类型的零值
除了分配内存外，部分 Java 虚拟机还会在此阶段构造其他跟类层次相关的数据结构，比如说用来实现虚方法的动态绑定的方法表。
在 class 文件被加载至 Java 虚拟机之前，这个类无法知道其他类及其方法、字段所对应的具体地址，甚至不知道自己方法、字段的地址。因此，每当需要引用这些成员时，Java 编译器会生成一个符号引用。在运行阶段，这个符号引用一般都能够无歧义地定位到具体目标上。
举例来说，对于一个方法调用，编译器会生成一个包含目标方法所在类的名字、目标方法的名字、接收参数类型以及返回值类型的符号引用，来指代所要调用的方法。
4）解析
然后进入可选的解析符号引用阶段。 也就是解析常量池，将常量池内的符号引用转换为直接引用的过程。即将上文提到的符号引用解析成为实际引用。主要有以下四种：类或接口的解析、字段解析、类方法解析、接口方法解析，对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info。符号引用就是一组符号来描述所引用的目标，即一些字面量的引用，和虚拟机的内部数据结构和内存布局无关。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。直接引用的对象都存在于内存中，你可以把通讯录里的手机号码，类比为符号引用，把面对面和你吃饭的人，类比为直接引用。比较容易理解的就是在Class类文件中，通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用时不够的，比如当如下println()方法被调用时，系统需要明确知道该方法的位置。如果符号引用指向一个未被加载的类，或者未被加载类的字段或方法，那么解析将触发这个类的加载（但未必触发这个类的链接以及初始化。）
举例：输出操作System.out.println()对应的字节码：
invokevirtual #24 <java/io/PrintStream.println>
以方法为例，Java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中，当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作，符号引用就可以转变为目标方法在类中方法表的位置，从而使得方法被成功调用。
简单的来说就是我们编写的代码中，当一个变量引用某个对象的时候，这个引用在 .class 文件中是以符号引用来存储的（相当于做了一个索引记录）。
在解析阶段就需要将其解析并链接为直接引用（相当于指向实际对象），也就是得到类、字段、方法在内存中的指针或者偏移量。因此，可以说，如果直接引用存在，那么可以肯定系统中存在该类、方法或者字段，但只存在符号引用，不能确定系统中一定存在该结构。即如果有了直接引用，那引用的目标必定在堆中存在。
加载一个 class 时, 需要加载所有的 super 类和 super 接口。事实上，Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中，加载、验证、准备和初始化会按照顺序有条不紊地执行，但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。
最后，看下CONSTANT_String的解析。由于字符串在程序开发中有着重要的作用，因此，我们有必要了解下String在Java虚拟机中的处理。当在Java代码中直接使用字符串常量时，就会在类中出现CONSTANT_String，它表示字符串常量，并且会引用一个CONSTANT_UTF8的常量项。在Java虚拟机内部运行中的常量池中，会维护一张字符串拘留表（intern），它会保存所有出现过的字符串常量，并且没有重复项。只要以CONSTANT_String形式出现的字符串也都会在这张表中。使用String.intern()方法可以得到一个字符串在拘留表中的引用，因为该表中没有重复项，所以任何字面相同的字符串的String.intern()方法返回总是相等的。
Java 虚拟机规范并没有要求在链接过程中完成解析。它仅规定了：如果某些字节码使用了符号引用，那么在执行这些字节码之前，需要完成对这些符号引用的解析。
5）初始化（Initialization）
JVM 规范明确规定, 必须在类的首次“主动使用”时才能执行类初始化。类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。即：到了初始化阶段，才真正开始执行类中定义的Java程序代码。
在 Java 代码中，如果要初始化一个静态字段，我们可以在声明时直接赋值，也可以在静态代码块中对其赋值。
如果直接赋值的静态字段被 final 所修饰，并且它的类型是基本类型或字符串时，那么该字段便会被 Java 编译器标记成常量值（ConstantValue），其初始化直接由 Java 虚拟机完成。除此之外的直接赋值操作，以及所有静态代码块中的代码，则会被 Java 编译器置于同一方法中，并把它命名为 < clinit >。
初始化阶段就是执行类构造器 <clinit>() 方法的过程。
<clinit>() 方法
源码：
public class ClassInitTest {
private static int num = 1;
public static void main(String[] args) {
System.out.println(ClassInitTest.num);
}
}
<clinit>() 方法不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。如果类没有静态变量或者静态代码块，就不会生成<clinit>() 方法。编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态代码块中只能访问到定义在静态代码块之前的变量，定义在它之后的变量，在前面的静态代码块可以赋值，但是不能访问，如以下代码：
public class ClassInitTest {
static {
i = 0;//正常编译
System.out.println(i);//提示“非法前向引用”
}
static int i = 1;
}
<clinit>() 方法不同于类的构造函数（即在虚拟机视角中的实例构造器<init>() 方法），它不需要显示调用父类构造器，Java 虚拟机会保证在子类的 <clinit>() 方法执行前，父类的 <clinit>() 方法已经执行完毕。因此在Java虚拟机中第一个被执行的<clinit>() 方法的类型肯定是 java.lang.Object 。
由于父类的<clinit>() 方法先执行，意味着父类中定义的静态代码块要优先于子类的变量赋值操作，如以下代码：
public class ClassInitTest {
static class Father {
public static int a = 1;
static {
a = 2;
}
}
static class Son extends Father {
public static int b = a;
}
public static void main(String[] args) {
System.out.println(Son.b);
}
}
运算结果：
2
<clinit>() 方法对于类或接口来说并不是必需的。哪些类在编译为字节码后，字节码文件中将不会包含<clinit>() 方法。
- 一个类中并没有声明任何的类变量，也没有静态代码块时
- 一个类中声明类变量，但是没有明确使用类变量的初始化语句已经静态代码块来执行初始化操作时
- 一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式
源码：
public class ClassInitTest {
private int num = 1;
public static void main(String[] args) {
int b = 2;
}
}
接口中不能使用静态代码块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>() 方法。但是接口与类不同的是，执行接口的<clinit>() 方法不需要先执行父接口的<clinit>() 方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。此外，接口的实现类在初始化时也一样不会执行接口的<clinit>() 方法。
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的<clinit>() 方法，其他线程都需要阻塞等待，直到活动线程执行完<clinit>() 方法。如果一个类的<clinit>() 方法中有耗时很长的操作，那就可能造成多个进程阻塞，在实际应用中这种阻塞往往很隐蔽。
代码如下：
public class ClassInitTest {
static class DeadLoopClass {
static {
if (true) {
System.out.println(Thread.currentThread() + "init DeadLoopClass");
while (true) {
}
}
}
}
public static void main(String[] args) {
Runnable runnable = new Runnable() {
@Override
public void run() {
System.out.println(Thread.currentThread() + "start");
DeadLoopClass deadLoopClass = new DeadLoopClass();
System.out.println(Thread.currentThread() + "start");
}
};
Thread thread1 = new Thread(runnable);
Thread thread2 = new Thread(runnable);
thread1.start();
thread2.start();
}
}
运行结果如下，一条线程在死循环以模拟长时间操作，另一条线程在阻塞等待：
Thread[Thread-0,5,main]start Thread[Thread-1,5,main]start Thread[Thread-0,5,main]init DeadLoopClass
Java程序对类的使用方式分为：主动使用和被动使用
Class只有在必须要首次使用的时候才会被装载，Java虚拟机不会无条件地装载Class类型。Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里的使用是指主动使用。
主动使用，分为八种情况：（即：如果出现如下情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成。）
- 当虚拟机启动时，初始化用户指定的主类即标明为启动类的类，就是启动执行的 main 方法所在的类；
- 当遇到用以新建目标类实例的 new 指令时，初始化 new 指令的目标类，就是 new 一个类的时候要初始化；
- 当遇到调用静态方法的指令时，即当使用了字节码invokestatic指令，初始化该静态方法所在的类；
- 当访问某个类或接口的静态变量或对该静态变量赋值时，比如使用getstatic或者putstatic，初始化该静态字段所在的类；
- 子类的初始化会触发父类的初始化；
- 如果一个接口定义了 default 方法，那么直接实现或者间接实现该接口的类的初始化，会触发该接口的初始化；
- 使用反射 API 对某个类进行反射调用时，初始化这个类，其实跟前面一样，反射调用要么是已经有实例了，要么是静态方法，都需要初始化；
- JDK 7 开始提供的动态语言支持：java.lang.invoke.MethodHandle 实例的解析结果。REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化。
同时以下几种情况可以看作类的被动使用，不会执行类初始化：
- 当访问一个静态字段时，只有真正声明这个字段的类才会被初始化。通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
- 定义对象数组，不会触发该类的初始化。
- 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
- 通过类名获取 Class 对象，不会触发类的初始化，Hello.class 不会让 Hello 类初始化。
- 通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。Class.forName(“jvm.Hello”)默认会加载 Hello 类。
- 通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作（加载了，但是不初始化）。
示例: 诸如 Class.forName(), classLoader.loadClass() 等 Java API, 反射API, 以及 JNI_FindClass 都可以启动类加载。 JVM 本身也会进行类加载。 比如在 JVM 启动时加载核心类，java.lang.Object, java.lang.Thread 等等。
public class Singleton {
private Singleton() {}
private static class LazyHolder {
static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return LazyHolder.INSTANCE;
}
}
只有当调用 Singleton.getInstance 时，程序才会访问 LazyHolder.INSTANCE，才会触发对 LazyHolder 的初始化（对应第 4 种情况），继而新建一个 Singleton 的实例。由于类初始化是线程安全的，并且仅被执行一次，因此程序可以确保多线程环境下有且仅有一个 Singleton 实例。
注意：
当Java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则并不适用于接口。在初始化一个类时，并不会先初始化它所实现的接口。在初始化一个接口时，并不会先初始化它的父接口。因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。
6）使用（Using）
7）卸载（Unloading）
在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。
一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。
类的生命周期
当Sample类被加载、链接和初始化后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载。从而结束Sample类的生命周期。
一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。
loader1变量和obj变量间接引用代表Sample类的Class对象，而objClass变量则直接引用它。
如果程序运行过程中，将上图左侧三个引用变量都置为null，此时Sample对象结束生命周期，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据被卸载。
当再次有需要时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不在重新加载；如果不存在，会被重新加载，在Java虚拟机的堆区重新生成一个新的代表Sample类的Class实例（可以通过哈希吗查看是否是同一个实例）
方法区的垃圾回收
方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。
HotSpot虚拟机对常量池的回收策略时很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。
判断一个常量是否废弃还是相对简单的，而判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足以下三个条件：
- 该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例。
- 加载该类的类加载器已经被回收。这个条件除非时经过精心设计的可替换类加载器的场景，如OSGI、JSP的重加载等，否则通常是很难达成的。
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而不是和对象一样，没有引用了就必然会回收。
类的卸载
- 启动类加载器加载的类型在整个运行期间是不可能被卸载的（JVM和JLS规范）
- 被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类加载器的实例基本上在整个运行期间总能直接或者间接的访问到，其达到unreachable的可能性极小。
- 被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中（比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略提高系统性能），被加载的类型在运行期间也是几乎不太可能被卸载的（至少卸载的实际是不确定的）
综合以上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。同时我们可以看的出来，开发者在开发代码时，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能。
类加载器机制
类加载过程可以描述为“通过一个类的全限定名 a.b.c.XXClass 来获取描述此类的 Class 对象”，这个过程由“类加载器（ClassLoader）”来完成。ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader区改变类的链接和初始化行为。至于它是否可以运行，则由Execution Engine决定。
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即时这两个类源自同一个Class文件，被同一个虚拟机加载，只有加载它们的类加载器不同，那这两个类就必定不相等。
类的加载分类：显式加载和隐式加载
class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。
- 显式加载指的是在代码中通过调用ClassLoader加载classs对象，如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载class对象。
- 隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载到内存中。
系统自带的类加载器分为三种：
- 启动类加载器（BootstrapClassLoader）
- 扩展类加载器（ExtClassLoader）
- 应用类加载器（AppClassLoader）
一般启动类加载器是由 JVM 内部实现的，在 Java 的 API 里无法拿到，但是我们可以侧面看到和影响它。后 2 种类加载器在 Oracle Hotspot JVM 里，都是在中sun.misc.Launcher定义的，扩展类加载器和应用类加载器一般都继承自URLClassLoader类，这个类也默认实现了从各种不同来源加载 class 字节码转换成 Class 的方法。
上图是类加载器的继承关系。
- 启动类加载器（bootstrap class loader）: 它用来加载 Java 的核心类，也就是 rt.jar、resources.jar、charsets.jar 等，是用原生 C++ 代码来实现的，并不继承自 java.lang.ClassLoader。它可以看做是 JVM 自带的，随着 JVM 启动，我们在代码层面无法直接获取到启动类加载器的引用，所以不允许直接操作它， 如果打印出来就是个 null。举例来说，java.lang.String 是由启动类加载器加载的，所以 String.class.getClassLoader() 就会返回 null。但是可以通过-Xbootclasspath 参数影响它加载什么。
- 扩展类加载器（extensions class loader）：它负责加载 JRE 的扩展目录，lib/ext 或者由 java.ext.dirs 系统属性指定的目录中的 JAR 包的类，代码里直接获取它的父类加载器为 null（因为无法拿到启动类加载器）。
- 应用类加载器（app class loader）：它负责在 JVM 启动时加载来自 Java 命令的 -classpath 或者 -cp 选项、java.class.path 系统属性指定的 jar 包和类路径。在应用程序代码里可以通过 ClassLoader 的静态方法 getSystemClassLoader() 来获取应用类加载器。如果没有特别指定，则在没有使用自定义类加载器情况下，用户自定义的类都由此加载器加载。
此外还可以自定义类加载器。如果用户自定义了类加载器，则自定义类加载器都以应用类加载器作为父加载器。应用类加载器的父类加载器为扩展类加载器。这些类加载器是有层次关系的，启动加载器又叫根加载器，是扩展加载器的父加载器，但是直接从 ExClassLoader 里拿不到它的引用，同样会返回 null。
请注意：这不是类的继承关系，只是层级关系。
每个类加载器都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成。在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类。在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类。
数组类的Class对象，不是由类加载器去创建的，而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说，是通过Class.getClassLoader()返回的，与数组当中元素类型的类加载器是一样的；如果数组当中的元素类型是基本数据类型，数组类是没有类加载器的。
类加载机制有三个特点：
- 双亲委托：当一个自定义类加载器需要加载一个类，比如 java.lang.String，它很懒，不会一上来就直接试图加载它，而是先委托自己的父加载器去加载，父加载器如果发现自己还有父加载器，会一直往前找，这样只要上级加载器，比如启动类加载器已经加载了某个类比如 java.lang.String，所有的子加载器都不需要自己加载了。如果几个类加载器都没有加载到指定名称的类，那么会抛出 ClassNotFountException 异常。但不是所有类加载都遵守这个规则，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供一些摩尔呢的参考实现。例如，Java中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用的这种机制，这种情况就不会用双亲委派去加载，而是利用所谓的上下文加载器。
- 负责依赖：如果一个加载器在加载某个类的时候，发现这个类依赖于另外几个类或接口，也会去尝试加载这些依赖项。
- 缓存加载：为了提升加载效率，消除重复加载，一旦某个类被一个类加载器加载，那么它会缓存这个加载结果，不会重复加载。
抽象类ClassLoader的主要方法
ClassLoader内部没有抽象方法。
public final ClassLoader getParent()
返回该类加载器的超类加载器
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
加载名称为name的类，返回结果为java.lang.Class类的实例。如果找不到类，则返回ClassNotFoundException异常。该方法中的逻辑就是双亲委派模式的实现。
protected Class<?> loadClass(String name, boolean resolve) //resolve：true -加载class的同时进行解析操作
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) { //判断是否存在父类加载器
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.
long t1 = System.nanoTime();
c = findClass(name); //调用当前类加载器的findClass()方法
// 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;
}
}
Class.forName()与ClassLoader.loadClass()的区别：
Class.forName()：是一个静态方法，最常用的是Class.forName(String className)；根据传入的类的全限定名返回一个Class对象。该方法在将Class文件加载到内存的同时，会执行类的初始化。
ClassLoader.loadClass()：是一个实例方法，需要一个ClassLoader对象来调用该方法。该方法将Class文件加载到内存时，并不会执行类的初始化，直到这个类第一次使用时才进行初始化。该方法因为需要得到一个ClassLoader对象，所以可以根据需要指定使用哪个类加载器。
protected Class<?> findClass(String name) throws ClassNotFoundException
查找二进制名称为name的类，返回结果为java.lang.class类的实例。这是一个受保护的方法，JVM鼓励我们重写此方法，需要自定义加载器遵循双亲委派机制，该方法会在检查完父类加载器之后被loadClass()方法调用。
在JDK1.2之前，在自定义类加载时，总会去继承ClassLoader类并重写loadClass方法，从而实现自定义的类加载类。但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议吧自定义的类加载逻辑写在findClass()方法中，从前面的分析可知，findClass()方法是在loadClass()方法中被调用的，当loadClass()方法中父加载器加载失败后，则会调用自己的findClass()方法来完成类加载，这样就可以保证自定义的类加载器也符合双亲委派模式。
需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑，取而代之的是抛出ClassNotFoundException异常，同时应该知道的是findClass()方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass()方法生成类的Class对象。
URLClassLoader的findClass()方法：
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;
}
protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError
根据给定的字节数组b转换为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，其中byte数组b是ClassLoader从外部获取的。这是受保护的方法，只有在自定义ClassLoader子类中可以使用。
defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象（ClassLoader中已实现该方法逻辑），通过这个方法不仅能够通过class文件实例化class对象，也可以通过其他方式实例化class对象，如通过网络接收一个类的字节码，然后转换为byte字节流创建对应的Class对象。
defineClass()方法通常与findClass()方法一起使用，一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法并编写加载规则，取得要加载类的字节码后转换为流，然后调用defineClass()方法生成类的Class对象。
protected final void resolveClass(Class<?> c)
链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析。前面我们说链接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。
protected final Class<?> findLoadedClass(String name)
查找名称为name的已经被加载过的类，返回结果是java.lang.Class类的实例。这个方法是final方法，无法被修改。
自定义类加载器示例
为什么需要自定义类加载器
- 隔离加载类
- 修改类加载的方式
- 扩展加载源
- 防止源码泄漏
我们可以自行实现类加载器来加载其他格式的类，对加载方式、加载数据的格式进行自定义处理，只要能通过 classloader 返回一个 Class 实例即可。这就大大增强了加载器灵活性。
举个例子：
public class Hello {
static {
System.out.println("类加载器:" + Hello.class.getClassLoader());
System.out.println("Hello Class Initialized!");
}
}
Hello 类在自己被初始化的时候，打印自己的类加载器并打印一句“Hello Class Initialized!”。
实现一个 MyClassLoader ，它继承自 ClassLoader 类，在加载器类构造方法中指定 class文件路径，findClass 方法中参数指定类的全限定名。
public class MyClassLoader extends ClassLoader {
//指定class文件路径
private String path ;
public MyClassLoader(String classPath){
path=classPath;
}
public static void main(String[] args) {
try {
new MyClassLoader("D:\\Hello.class").findClass("com.fhj.jvm.Hello").newInstance(); // 加载并初始化Hello类
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
}
}
/**
* 重写findClass方法
* @param name 是我们这个类的全路径
* @return
* @throws ClassNotFoundException
*/
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
Class log = null;
// 获取该class文件字节码数组
byte[] classData = getData();
if (classData != null) {
// 将class的字节码数组转换成Class类的实例
log = defineClass(name, classData, 0, classData.length);
}
return log;
}
/**
* 将class文件转化为字节码数组
* @return
*/
private byte[] getData() {
File file = new File(path);
if (file.exists()){
FileInputStream in = null;
ByteArrayOutputStream out = null;
try {
in = new FileInputStream(file);
out = new ByteArrayOutputStream();
byte[] buffer = new byte[1024];
int size = 0;
while ((size = in.read(buffer)) != -1) {
out.write(buffer, 0, size);
}
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
in.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return out.toByteArray();
}else{
return null;
}
}
}
执行结果：
类加载器:com.fhj.jvm.MyClassLoader@2f92e0f4
Hello Class Initialized!
自定义类加载器还有其他一些功能，比如我们试着实现一个可以用来处理简单加密的字节码的类加载器，用来保护我们的 class 字节码文件不被使用者直接拿来破解。
如果上面的 Hello 类的内容非常重要，不想把编译到得到的 Hello.class 给别人，但是别人可以调用或执行这个类，应该怎么办呢？一个简单的思路是，我们把这个类的 class 文件二进制作为字节流先加密一下，然后尝试通过自定义的类加载器来加载加密后的数据。为了演示简单，我们使用 jdk 自带的 Base64 算法，把字节码加密成一个文本。在下面这个例子里，我们实现一个 HelloClassLoader，它继承自 ClassLoader 类，但是我们希望它通过我们提供的一段 Base64 字符串，来还原出来，并执行我们的 Hello 类里的打印一串字符串的逻辑。Base64 字符串由方法 encode 执行而来，可以先在其他地方执行，然后将执行结果放入 findClass 方法中。
public class HelloClassLoader extends ClassLoader {
public static void main(String[] args) {
try {
new HelloClassLoader().findClass("com.fhj.jvm.Hello").newInstance(); // 加载并初始化Hello类
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
}
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
String helloBase64 = "yv66vgAAADQANQoADQAYCQAZABoHABsKAAMAGAgAHAoAAwAdBwAeCgAfACAKAAMAIQoAAwAiCgAjACQIACUHACYBAAY8aW5pdD4BAAMoKVYBAARDb2RlAQAPTGluZU51bWJlclRhYmxlAQASTG9jYWxWYXJpYWJsZVRhYmxlAQAEdGhpcwEAE0xjb20vZmhqL2p2bS9IZWxsbzsBAAg8Y2xpbml0PgEAClNvdXJjZUZpbGUBAApIZWxsby5qYXZhDAAOAA8HACcMACgAKQEAF2phdmEvbGFuZy9TdHJpbmdCdWlsZGVyAQAN57G75Yqg6L295ZmoOgwAKgArAQARY29tL2Zoai9qdm0vSGVsbG8HACwMAC0ALgwAKgAvDAAwADEHADIMADMANAEAGEhlbGxvIENsYXNzIEluaXRpYWxpemVkIQEAEGphdmEvbGFuZy9PYmplY3QBABBqYXZhL2xhbmcvU3lzdGVtAQADb3V0AQAVTGphdmEvaW8vUHJpbnRTdHJlYW07AQAGYXBwZW5kAQAtKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1N0cmluZ0J1aWxkZXI7AQAPamF2YS9sYW5nL0NsYXNzAQAOZ2V0Q2xhc3NMb2FkZXIBABkoKUxqYXZhL2xhbmcvQ2xhc3NMb2FkZXI7AQAtKExqYXZhL2xhbmcvT2JqZWN0OylMamF2YS9sYW5nL1N0cmluZ0J1aWxkZXI7AQAIdG9TdHJpbmcBABQoKUxqYXZhL2xhbmcvU3RyaW5nOwEAE2phdmEvaW8vUHJpbnRTdHJlYW0BAAdwcmludGxuAQAVKExqYXZhL2xhbmcvU3RyaW5nOylWACEABwANAAAAAAACAAEADgAPAAEAEAAAAC8AAQABAAAABSq3AAGxAAAAAgARAAAABgABAAAAAwASAAAADAABAAAABQATABQAAAAIABUADwABABAAAABGAAMAAAAAACayAAK7AANZtwAEEgW2AAYSB7YACLYACbYACrYAC7IAAhIMtgALsQAAAAEAEQAAAA4AAwAAAAUAHQAGACUABwABABYAAAACABc=";//String helloBase64 = encode("D:\\Hello.class");
byte[] bytes = decode(helloBase64);
return defineClass(name, bytes, 0, bytes.length);
}
public byte[] decode(String base64) {
return Base64.getDecoder().decode(base64);
}
public String encode(String path) {
return Base64.getEncoder().encodeToString(getData(path));
}
private byte[] getData(String path) {
File file = new File(path);
if (file.exists()) {
FileInputStream in = null;
ByteArrayOutputStream out = null;
try {
in = new FileInputStream(file);
out = new ByteArrayOutputStream();
byte[] buffer = new byte[1024];
int size = 0;
while ((size = in.read(buffer)) != -1) {
out.write(buffer, 0, size);
}
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
in.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return out.toByteArray();
} else {
return null;
}
}
}
执行结果：
类加载器:com.fhj.jvm.HelloClassLoader@567d299b
Hello Class Initialized!
可以看到达到了我们的目的，成功执行了Hello类的代码，但是完全不需要有Hello这个类的class文件。此外，需要说明的是两个没有关系的自定义类加载器之间加载的类是不共享的（只共享父类加载器，兄弟之间不共享），这样就可以实现不同的类型沙箱的隔离性，我们可以用多个类加载器，各自加载同一个类的不同版本，大家可以相互之间不影响彼此，从而在这个基础上可以实现类的动态加载卸载，热插拔的插件机制等。
实用技巧
找不到Jar包的问题
有时候我们会碰到这种情况，明明已经把某个jar加入到了环境里，可是运行的时候还是找不到。如果想看看各个类加载器加载了哪些jar，以及把哪些路径加到了classpath里。该怎么办呢，可以使用以下方法，代码如下：
public class JvmClassLoaderPrintPath {
public static void main(String[] args) {
// 启动类加载器
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
System.out.println("启动类加载器");
for(URL url : urls) {
System.out.println(" ==> " +url.toExternalForm());
}
// 扩展类加载器
printClassLoader("扩展类加载器", JvmClassLoaderPrintPath.class.getClassLoader().getParent());
// 应用类加载器
printClassLoader("应用类加载器", JvmClassLoaderPrintPath.class.getClassLoader());
}
public static void printClassLoader(String name, ClassLoader CL){
if(CL != null) {
System.out.println(name + " ClassLoader -> " + CL.toString());
printURLForClassLoader(CL);
}else{
System.out.println(name + " ClassLoader -> null");
}
}
public static void printURLForClassLoader(ClassLoader CL){
Object ucp = insightField(CL,"ucp");
Object path = insightField(ucp,"path");
ArrayList ps = (ArrayList) path;
for (Object p : ps){
System.out.println(" ==> " + p.toString());
}
}
private static Object insightField(Object obj, String fName) {
try {
Field f = null;
if(obj instanceof URLClassLoader){
f = URLClassLoader.class.getDeclaredField(fName);
}else{
f = obj.getClass().getDeclaredField(fName);
}
f.setAccessible(true);
return f.get(obj);
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
执行结果：
启动类加载器 ==> file:/D:/java/jdk1.8.0_66/jre/lib/resources.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/rt.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/sunrsasign.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/jsse.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/jce.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/charsets.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/jfr.jar ==> file:/D:/java/jdk1.8.0_66/jre/classes 扩展类加载器 ClassLoader -> sun.misc.Launcher$ExtClassLoader@2f92e0f4 ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/access-bridge-64.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/cldrdata.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/dnsns.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/jaccess.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/jfxrt.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/localedata.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/nashorn.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/sunec.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/sunjce_provider.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/sunmscapi.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/sunpkcs11.jar ==> file:/D:/java/jdk1.8.0_66/jre/lib/ext/zipfs.jar 应用类加载器 ClassLoader -> sun.misc.Launcher$AppClassLoader@14dad5dc ==> file:/D:/study/target/classes/
从打印结果，我们可以看到三种类加载器各自默认加载了哪些 jar 包和包含了哪些 classpath 的路径。
如何排查类的方法不一致的问题？
假如我们确定一个 jar 或者 class 已经在 classpath 里了，但是却总是提示java.lang.NoSuchMethodError，这是怎么回事呢？很可能是加载了错误的或者重复加载了不同版本的 jar 包。这时候，用前面的方法就可以先排查一下，加载了具体什么 jar，然后是不是不同路径下有重复的 class 文件，但是版本不一样。
怎么看到加载了哪些类，以及加载顺序？
还是针对上一个问题，假如有两个地方有 Hello.class，一个是新版本，一个是旧的，怎么才能直观地看到他们的加载顺序呢？也没有问题，我们可以直接打印加载的类清单和加载顺序。
只需要在类的启动命令行参数加上-XX:+TraceClassLoading 或者 -verbose 即可，注意需要加载 Java 命令之后，要执行的类名之前，不然不起作用。例如：
执行结果：
[Opened D:\Java\jdk1.8.0_66\jre\lib\rt.jar] [Loaded java.lang.Object from D:\Java\jdk1.8.0_66\jre\lib\rt.jar] [Loaded java.io.Serializable from D:\Java\jdk1.8.0_66\jre\lib\rt.jar] [Loaded java.lang.Comparable from D:\Java\jdk1.8.0_66\jre\lib\rt.jar] [Loaded java.lang.CharSequence from D:\Java\jdk1.8.0_66\jre\lib\rt.jar] // 。。。。。。此次省略了部分类加载信息 [Loaded sun.nio.cs.Surrogate$Parser from D:\Java\jdk1.8.0_66\jre\lib\rt.jar] [Loaded sun.nio.cs.Surrogate from D:\Java\jdk1.8.0_66\jre\lib\rt.jar] [Loaded com.fhj.jvm.Hello from __JVM_DefineClass__]
类加载器:com.fhj.jvm.HelloClassLoader@2f92e0f4 Hello Class Initialized! [Loaded java.lang.Shutdown from D:\Java\jdk1.8.0_66\jre\lib\rt.jar] [Loaded java.lang.Shutdown$Lock from D:\Java\jdk1.8.0_66\jre\lib\rt.jar]
上面的信息，可以很清楚的看到类的加载先后顺序，以及是从哪个 jar 里加载的，这样排查类加载的问题非常方便。
怎么调整或修改 ext 和本地加载路径？
从前面的例子我们可以看到，假如什么都不设置，直接执行 java 命令，默认也会加载非常多的 jar 包，怎么可以自定义加载哪些 jar 包呢？比如我的代码很简单，只加载 rt.jar 行不行？答案是肯定的。
执行结果：
启动类加载器 ==> file:/D:/java/jdk1.8.0_66/jre/lib/rt.jar 扩展类加载器 ClassLoader -> sun.misc.Launcher$ExtClassLoader@f6f4d33 应用类加载器 ClassLoader -> sun.misc.Launcher$AppClassLoader@14dad5dc
==> file:/D:/study/target/classes/
我们看到启动类加载器只加载了 rt.jar，而扩展类加载器什么都没加载，这就达到了我们的目的。
其中命令行参数 -Dsun.boot.class.path 表示我们要指定启动类加载器加载什么，也可以使用参数 -Xbootclasspath，最基础的东西都在 rt.jar 这个包了里，所以一般配置它就够了 。需要注意的是因为在 windows 系统默认 JDK 安装路径有个空格，所以需要把整个路径用双引号括起来，如果路径没有空格，或是 Linux/Mac 系统，就不需要双引号了。
参数-Djava.ext.dirs 表示扩展类加载器要加载什么，一般情况下不需要的话可以直接配置为空即可。
怎么运行期加载额外的 jar 包或者 class 呢？
有时候我们在程序已经运行了以后，还是想要再额外的去加载一些 jar 或类，需要怎么做呢？
简单说就是不使用命令行参数的情况下，怎么用代码来运行时改变加载类的路径和方式。假如说，在 d: 路径下，有我们刚才使用过的 Hello.class 文件，怎么在代码里能加载这个 Hello 类呢？
两个办法，一个是前面提到的自定义 ClassLoader 的方式，还有一个就是直接在当前的应用类加载器里，使用 URLClassLoader 类的方法 addURL，不过这个方法是 protected 的，需要反射处理一下，然后又因为程序在启动时并没有显示加载 Hello 类，所以在添加完了 classpath 以后，没法直接显式初始化，需要使用 Class.forName 的方式来拿到已经加载的Hello类（Class.forName("com.fhj.jvm.Hello") 默认会初始化并执行静态代码块）。代码如下：
public class JvmAppClassLoaderAddURL {
public static void main(String[] args) {
String appPath = "file:/d:/";
URLClassLoader urlClassLoader = (URLClassLoader) JvmAppClassLoaderAddURL.class.getClassLoader();
try {
Method addURL = URLClassLoader.class.getDeclaredMethod("addURL", URL.class);
addURL.setAccessible(true);
URL url = new URL(appPath);
addURL.invoke(urlClassLoader, url);
Class.forName("com.fhj.jvm.Hello"); // 效果跟Class.forName("com.fhj.jvm.Hello").newInstance()一样
} catch (Exception e) {
e.printStackTrace();
}
}
}
执行结果：
类加载器:sun.misc.Launcher$AppClassLoader@14dad5dc Hello Class Initialized!
替换 JDK 的类
当 Java 的原生 API 不能满足需求时，比如我们要修改 HashMap 类，就必须要使用到 Java 的 endorsed 技术。我们需要将自己的 HashMap 类，打包成一个 jar 包，然后放到 -Djava.endorsed.dirs 指定的目录中。注意类名和包名，应该和 JDK 自带的是一样的。但是，java.lang 包下面的类除外，因为这些都是特殊保护的。
因为我们上面提到的双亲委派机制，是无法直接在应用中替换 JDK 的原生类的。但是，有时候又不得不进行一下增强、替换，比如你想要调试一段代码，或者比 Java 团队早发现了一个 Bug。所以，Java 提供了 endorsed 技术，用于替换这些类。这个目录下的 jar 包，会比 rt.jar 中的文件，优先级更高，可以被最先加载到。
双亲委派机制
工作过程：
如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类加载器去执行，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（类没有在它的搜索范围中）时，子加载器才会尝试自己去完成加载。
优势
避免类的重复加载，保护程序安全，防止核心API被随意篡改
沙箱安全机制：自定义String类，但是在加载自定义String 类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载JDK自带的文件（rt.jar包中java.lang.String）。这样就可以保证对java 核心源代码的保护。
缺点
检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。
通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类时没有问题的，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这是，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。
双亲委派机制的实现
protected Class<?> loadClass(String name, boolean resolve)
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) {
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.
long t1 = System.nanoTime();
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;
}
}
先检查请求加载的类型是否已经被加载过，若没有则调用父加载器的loadClass() 方法，若父加载器为空则默认使用启动类加载器作为父加载器。假如父加载器加载失败，抛出ClassNotFoundException 异常的话，才调用自己的findClass()方法尝试进行加载。
破坏双亲委派
双亲委派并不具有强制性约束，而是Java设计者推荐给开发者的类加载器实现方式。大部分的类加载器都遵循这个模型，但也有例外，双亲委派出现过3次较大规模被破坏的情况。
第一次发生在双亲委派出现之前即JDK 1.2面世以前。双亲委派在JDK 1.2 之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader 在Java的第一个版本就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派时做出了妥协，为了兼容已有的自定义类加载器代码，无法再以技术手段避免loadClass() 被子类覆盖的可能性，只能在JDK 1.2之后的java.lang.ClassLoader 中添加一个新的protect 方法 findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass中编写代码。之前分析过 loadClass() 方法，按照 loadClass() 方法的逻辑，如果父类加载失败，就会自动调用自己的 findClass() 方法来完成加载，这样既不会影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器符合双亲委派规则。
第二次是双亲委派自身的缺陷导致的，典型例子：JNDI服务，JNDI的代码由启动类加载器加载（在JDK 1.3 时加入到rt.jar），但JNDI 的目的就是查找和集中管理资源，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码，但是启动类加载器是不会加载这些代码的。为了解决这个问题，引入了线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread 类的setContext-ClassLoader() 方法进行设置，如果创建线程时未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，这个类加载器默认就是应用程序类加载器。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为打通了双亲委派的层次结构来逆向使用类加载器，违背了双亲委派的一般性原则。Java 中涉及SPI的加载基本都采用这种方式来完成，例如 JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个时，代码就只能根据具体提供者的类型来硬编码判断，在JDK 6时，JDK 提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一个相对合理的解决方案。
第三次是由于用户对程序动态性的追求导致的。用户希望Java应用程序能像电脑外设一样，不用重启电脑就可以换鼠标，读U盘。对于生产系统，重启一次是会被列为生产事故的，这种不重启就能更新的功能对开发者来说，具有很大吸引力。IBM公司主导的JSR-291(即OSGI R4.2)实现模块化热部署的关键是它自定义的类加载器机制的实现。OSGI通过类加载器实现了热部署，每一个程序模块（OSGI中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGI环境下，类加载器不在使用双亲委派的树状结构，而是网状结构，当收到类加载请求时，OSGI按照以下的顺序进行类搜索：
- 将以java.*开头的类，委派给父类加载器加载。
- 否则，将委派列表名单内的类，委派给父类加载器加载。
- 否则，将Import列表的类，委派给Export这个类的Bundle的类加载器加载。
- 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
- 否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
- 否则，查找Dynamic Import 列表的Bundle，委派给对应Bundle的类加载器加载。
- 否则，类查找失败.
上面的查找顺序只有开头两点符合双亲委派，其余的类查找都是在平级的类加载器中进行。
打破双亲委派机制的案例
案例一：tomcat
tomcat 通过 war 包进行应用的发布，它其实是违反了双亲委派机制原则的。简单看一下 tomcat 类加载器的层次结构。
对于一些需要加载的非基础类，会由一个叫作 WebAppClassLoader 的类加载器优先加载。等它加载不到的时候，再交给上层的 ClassLoader 进行加载。这个加载器用来隔绝不同应用的 .class 文件，比如你的两个应用，可能会依赖同一个第三方的不同版本，它们是相互没有影响的。
如何在同一个 JVM 里，运行着不兼容的两个版本，当然是需要自定义加载器才能完成的事。
那么 tomcat 是怎么打破双亲委派机制的呢？可以看图中的 WebAppClassLoader，它加载自己目录下的 .class 文件，并不会传递给父类的加载器。但是，它却可以使用 SharedClassLoader 所加载的类，实现了共享和分离的功能。
但是你自己写一个 ArrayList，放在应用目录里，tomcat 依然不会加载。它只是自定义的加载器顺序不同，但对于顶层来说，还是一样的。
案例二：SPI
Java 中有一个 SPI 机制，全称是 Service Provider Interface，是 Java 提供的一套用来被第三方实现或者扩展的 API，它可以用来启用框架扩展和替换组件。
这个说法可能比较晦涩，但是拿我们常用的数据库驱动加载来说，就比较好理解了。在使用 JDBC 写程序之前，通常会调用下面这行代码，用于加载所需要的驱动类。
Class.forName("com.mysql.jdbc.Driver")
这只是一种初始化模式，通过 static 代码块显式地声明了驱动对象，然后把这些信息，保存到底层的一个 List 中。但是你会发现，即使删除了 Class.forName 这一行代码，也能加载到正确的驱动类，什么都不需要做，非常的神奇，它是怎么做到的呢？
我们翻开 MySQL 的驱动代码，发现了一个奇怪的文件。之所以能够发生这样神奇的事情，就是在这里实现的。
路径：
mysql-connector-java-8.0.15.jar!/META-INF/services/java.sql.Driver
里面的内容是：
com.mysql.cj.jdbc.Driver
通过在 META-INF/services 目录下，创建一个以接口全限定名为命名的文件（内容为实现类的全限定名），即可自动加载这一种实现，这就是 SPI。
SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制，主要使用 java.util.ServiceLoader 类进行动态装载。
这种方式，同样打破了双亲委派的机制。
DriverManager 类和 ServiceLoader 类都是属于 rt.jar 的。它们的类加载器是 Bootstrap ClassLoader，也就是最上层的那个。而具体的数据库驱动，却属于业务代码，这个启动类加载器是无法加载的。
我们可以一步步跟踪代码，来看一下这个过程。
com.mysql.cj.jdbc.Driver类
public class Driver extends NonRegisteringDriver implements java.sql.Driver {
//
// Register ourselves with the DriverManager
//
static {
try {
java.sql.DriverManager.registerDriver(new Driver());
} catch (SQLException E) {
throw new RuntimeException("Can't register driver!");
}
}
/**
* Construct a new driver and register it with DriverManager
*
* @throws SQLException
* if a database error occurs.
*/
public Driver() throws SQLException {
// Required for Class.forName().newInstance()
}
}
java.sql.DriverManager
private static void loadInitialDrivers() {
String drivers;
try {
drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
return System.getProperty("jdbc.drivers");
}
});
} catch (Exception ex) {
drivers = null;
}
// If the driver is packaged as a Service Provider, load it.
// Get all the drivers through the classloader
// exposed as a java.sql.Driver.class service.
// ServiceLoader.load() replaces the sun.misc.Providers()
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();
/* Load these drivers, so that they can be instantiated.
* It may be the case that the driver class may not be there
* i.e. there may be a packaged driver with the service class
* as implementation of java.sql.Driver but the actual class
* may be missing. In that case a java.util.ServiceConfigurationError
* will be thrown at runtime by the VM trying to locate
* and load the service.
*
* Adding a try catch block to catch those runtime errors
* if driver not available in classpath but it's
* packaged as service and that service is there in classpath.
*/
try{
while(driversIterator.hasNext()) {
driversIterator.next();
}
} catch(Throwable t) {
// Do nothing
}
return null;
}
});
println("DriverManager.initialize: jdbc.drivers = " + drivers);
if (drivers == null || drivers.equals("")) {
return;
}
String[] driversList = drivers.split(":");
println("number of Drivers:" + driversList.length);
for (String aDriver : driversList) {
try {
println("DriverManager.Initialize: loading " + aDriver);
Class.forName(aDriver, true,
ClassLoader.getSystemClassLoader());
} catch (Exception ex) {
println("DriverManager.Initialize: load failed: " + ex);
}
}
}
java.util.ServiceLoader
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
通过代码你可以发现 Java 玩了个魔术，它把当前的类加载器，设置成了线程的上下文类加载器。那么，对于一个刚刚启动的应用程序来说，它当前的加载器是谁呢？也就是说，启动 main 方法的那个加载器，到底是哪一个？
所以我们继续跟踪代码。找到 Launcher 类，就是 jre 中用于启动入口函数 main 的类。我们在 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);
}
}
到此为止，事情就比较明朗了，当前线程上下文的类加载器，是应用程序类加载器。使用它来加载第三方驱动，是没有什么问题的。
案例三：OSGi
OSGi 曾经非常流行，Eclipse 就使用 OSGi 作为插件系统的基础。OSGi 是服务平台的规范，旨在用于需要长运行时间、动态更新和对运行环境破坏最小的系统。
OSGi 规范定义了很多关于包生命周期，以及基础架构和绑定包的交互方式。这些规则，通过使用特殊 Java 类加载器来强制执行，比较霸道。
比如，在一般 Java 应用程序中，classpath 中的所有类都对所有其他类可见，这是毋庸置疑的。但是，OSGi 类加载器基于 OSGi 规范和每个绑定包的 manifest.mf 文件中指定的选项，来限制这些类的交互，这就让编程风格变得非常的怪异。但我们不难想象，这种与直觉相违背的加载方式，肯定是由专用的类加载器来实现的。
随着 jigsaw 的发展（旨在为 Java SE 平台设计、实现一个标准的模块系统），现在的 OSGi，意义已经不是很大了。OSGi 是一个庞大的话题，只需要知道，有这么一个复杂的东西，实现了模块化，每个模块可以独立安装、启动、停止、卸载，就可以了。
注意
在JVM中，即使两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的。即在JVM中表示两个class对象是否为同一个类存在两个必要条件：类的完全限定名一致，加载类的ClassLoader实例对象是同一个。
JVM必须知道一个类是由启动加载器加载的还是由用户类加载器加载的。如果一个类是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类信息的一部分保存在方法区中。当解析一个类到另一个类的引用时，JVM需要保证这两个类的类加载器是相同的。
JDK9新特性
为了保证兼容性，JDK 9 没有从根本上改变三层类加载器架构和双亲委派模型，但为了模块化系统的顺利运行，仍然发生了一些值得被注意的变动。
- 扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重名为平台类加载器（platform classloader）。可以通过ClassLoader的新方法getPlatformClassLoader()来获取。Java SE 中除了少数几个关键模块，比如说 java.base 是由启动类加载器加载之外，其他的模块均由平台类加载器所加载。JDK 9是基于模块化进行构建（原来的rt.jar和tools.jar被拆封成数十个JMOD文件），其中的Java类库就已天然地满足了可扩展的需求，那自然无须再保留<JAVA_HOME>\lib\ext 目录，此前使用这个目录或者java.ext.dir 系统变量来扩展JDK功能的机制已经没有继续存在的价值了。
- 平台类加载器和应用程序类加载器都不再继承自 java.net.URLClassLoader。现在启动类加载器、平台类加载器、应用程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader。
- 在Java9 中，类加载器有了名称。该名称在构造方法中指定，可以通过getName()方法来获取。平台类加载器的名称是platform，应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。
- 启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器（以前是C++实现），但为了与之前代码坚韧，在获取启动类加载器的场景中仍然会返回null，而不是得到BootClassLoader实例。
- 类加载的委派关系也发生了变动。当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。
