【JVM】JVM 类加载机制

发表于2021-09-22更新于2022-03-01字数统计18.9k阅读时长112分阅读次数

类加载器子系统概述

img

img

img

如果自己想手写一个Java虚拟机的话，主要考虑哪些结构呢？

  • 类加载器
  • 执行引擎

类加载器子系统作用

类加载器子系统负责从文件系统或者网络中加载Class文件，.class文件在文件开头有特定的文件标识：魔数 CA FE BA BE。类加载器ClassLoader只负责.class文件的加载，至于它是否可以运行，则由执行引擎Execution Engine决定。

加载的类信息存放于一块称为方法区（Java 8.0称为元空间）的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

image-20200705081813409

  • .class 文件存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM的方法区（JDK 8 的元空间）当中来根据这个文件实例化出n个一模一样的实例。
  • .class 文件加载到JVM的方法区（JDK 8 的元空间）中，被称为DNA元数据模板。
  • 在.class文件 -> JVM -> 最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。

image-20200705081913538

image-20211014204209807

类的加载过程

在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。即基本数据类型不需要类加载器来加载，在JVM启动时就已经预定义，下面讨论的加载过程都是针对引用类型对象而言。

例如下面的一段简单的代码：

1
2
3
4
5
public class HelloLoader {
    public static void main(String[] args) {
        System.out.println("我已经被加载啦");
    }
}

它的加载过程是怎么样的呢?

img

完整的流程图如下所示：加载 --> 链接（验证 --> 准备 --> 解析） --> 初始化

image-20200705082601441

下面按顺序分析该类的加载过程：

  • 加载阶段 - Loading：将 .class 文件从硬盘/网络中读取加载到内存中
  • 链接阶段 - Linking
    • 验证 - Verify：校验文件是否合法
    • 准备 - Prepare：为类的静态成员变量初始化，赋零值
    • 解析 - Resolve：将常量池内的符号引用转换为直接引用
  • 初始化阶段 - Initialization：为类的静态成员变量赋值。合并类的静态成员变量赋值语句和静态代码块中的语句组成 <clinit>() 方法，并按顺序执行为这些静态成员变量赋值。

image-20200705081813409

按照Java虚拟机规范，从class文件到加载到内存中的类，到类卸载出内存为止，它的整个生命周期包括如下7个阶段：

image-20211014204138998

加载阶段 - Loading

所谓加载，就是将Java类的字节码文件加载到机器内存中，并在方法区中构建出Java类的原型——类模板信息

所谓类模板对象，其实就是Java类在JVM内存中的一个快照，JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样JVM在运行期便能通过类模板而获取Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用，见下图中方法区里的二进制数据表结构。反射的机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射。

作用：加载阶段负责将.class文件从硬盘/网络中读取二进制字节流到内存中，交给链接阶段进行验证/准备/解析。

流程：

  1. 通过一个类的全限定名获取定义此类的二进制字节流
  2. 将这个二进制字节流所代表的静态存储结构转化为方法区内的运行时数据结构——类模板信息
  3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口（下图中代表Sample类的Class对象）

image-20211014204209807

加载 .class 文件的方式

  • 从本地系统中直接加载 .class 文件（最常见）
  • 通过网络获取，典型场景：Web Applet
  • 从zip压缩包中读取，成为日后jar、war格式的基础
  • 运行时计算生成，使用最多的是：动态代理技术
  • 由其他文件生成，典型场景：JSP应用从专有数据库中提取.class文件，比较少见
  • 从加密文件中获取，典型的防Class文件被反编译的保护措施

类模型与 Class 实例的位置

代表该类的类模板信息存储在方法区（JDK 8 以后的元空间）中，其对应的 Class 对象存储在堆区，并能访问到方法区中的类信息。

image-20211014204942607

数组类的加载

创建数组类的情况稍微有些特殊，因为数组类本身并不是由类加载器负责创建，而是由JVM在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类加载器去创建。创建数组类（下述简称A）的过程：

  • 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型
  • JVM使用指定的元素类型和数组维度来创建新的数组类。

如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。

链接阶段 - Linking

img

验证 - Verify

目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。如果出现不合法的字节码文件，那么将会验证不通过。

主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。

image-20211014205546184

说明：

  • 格式验证其实适合加载阶段一起进行的，只是为了分类才将其归纳到链接阶段。验证通过后，类加载器才会将类的二进制数据信息加载到方法区中。
  • 格式验证之外的其他验证操作将会在方法区中进行。
  • 链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行各种检查。

工具：Binary Viewer查看

image-20200705084038680

同时我们可以通过安装IDEA的插件，来查看我们的Class文件

image-20200705090237078

安装完成后，我们编译完一个class文件后，点击view即可显示我们安装的插件来查看字节码方法了

image-20200705090328171

准备 - Prepare

作用：为类的静态成员变量分配内存并且设置该类变量的默认零初始值，基本数据类型为零值，引用数据类型为null。

准备阶段不会为 static 方法块中定义的静态成员进行初始化，其由初始化阶段完成

1
2
3
4
5
6
public class HelloApp {
    private static int a = 1;  // 准备阶段为0，在下个阶段，也就是初始化的时候才是1
    public static void main(String[] args) {
        System.out.println(a);
    }
}

上面的变量a在准备阶段会赋默认零初始值，但不是1，而是0。在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。

注意：

  • 这里不包含用final修饰的static，因为 final在编译的时候就会分配了，可以在字节码文件中该Field的属性中查看到其值为1，说明在程序运行前就已经确定了该值，因此准备阶段时其值就已经是1了
  • 这里不会为实例变量分配初始化，类的静态成员变量会分配在方法区中（JDK 8 中存储在堆中），而实例变量是会随着对象一起分配到堆中。

下面代码中，num在static方法块中先赋值再声明，看似顺序不合理，但是在准备阶段已经先声明了静态成员变量num并为赋值为0。在后续的初始化阶段，才会执行static代码块中赋值操作，此时已经声明了num变量。

1
2
3
4
5
static {
    num = 1;
}

private static int num;

注意：

1
2
3
4
// 一般情况：static final修饰的基本数据类型、字符串类型字面量会在准备阶段赋值
private static final String str = "Hello world";
// 特殊情况：static final修饰的引用类型不会在准备阶段赋值，而是在初始化阶段赋值
private static final String str = new String("Hello world");

结论：使用 static + final 修饰，且显式赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值，是在链接阶段的准备环节进行，否则就是在初始化阶段进行。

1
2
3
4
5
6
7
8
9
10
public static final int INT_CONSTANT = 10;                                // 在链接阶段的准备环节赋值
public static final int NUM1 = new Random().nextInt(10);                  // 在初始化阶段clinit>()中赋值
public static int a = 1;                                                  // 在初始化阶段<clinit>()中赋值

public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100);     // 在初始化阶段<clinit>()中赋值
public static Integer INTEGER_CONSTANT2 = Integer.valueOf(100);           // 在初始化阶段<clinit>()中概值

public static final String s0 = "helloworld0";                            // 在链接阶段的准备环节赋值
public static final String s1 = new String("helloworld1");                // 在初始化阶段<clinit>()中赋值
public static String s2 = "hellowrold2";                                  // 在初始化阶段<clinit>()中赋值

解析 - Resolve

作用：将常量池内的类、接口、字段和方法等符号引用转换为直接引用。通过解析后，就会得知每个符号引用在方法区中实际存储的物理地址。

解析后的效果：

image-20220301155234333

.class文件中只会保存常量池中信息（例如类信息、方法信息等）的符号引用，不需要直接引用这些信息，这样文件体积就会比较小，也能节省栈的空间，即栈帧里的动态链接部分只需要保存符号引用，而不需要保存直接引用，该转换由解析阶段完成。

符号引用就是一些字面量的引用，和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中，通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的，比如当 println() 方法被调用时，系统需要明确知道该方法在方法区中的实际物理地址，因此需要在调用该方法前找到其真实地址。

使用 javap 命令解析 .class 文件后可以查看符号引用：

img

以方法为例，Java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中，当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析阶段，符号引用就可以转变为目标方法在类中方法表里的位置，从而使得方法被成功调用。

事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行，只是将其分类到链接阶段而已。

符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等。

初始化阶段 - Initialization

作用：初始化阶段就是执行类的静态属性初始化方法<clinit>()的过程（class init）。

<clinit>()方法不需显式定义，是javac编译器自动收集类中的所有类静态成员变量的赋值动作和静态代码块中的语句合并而来。也就是说，当我们代码中包含static变量的时候，就会自动生成clinit()方法。静态属性构造器方法中指令按语句在源文件中出现的顺序执行。

<clinit>()不同于类的构造器。（关联：构造器是虚拟机视角下的<init>()）若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕。

只有当我们代码中包含static成员变量或static代码块的时候，才会有<clinit>()方法。

1
2
3
4
5
6
7
8
9
10
11
public class ClassInitTest {
    private static int num = 1;

    static {
        num = 3;
    }

    public static void main(String[] args) {
        System.out.println(ClassInitTest.num);
    }
}

img

<clinit>()方法初始化顺序

<clinit>()方法中的指令按语句在源文件中出现的顺序执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class ClassInitTest {
    private static int num = 1;
    static {
        num = 2;
        number = 20;
        System.out.println(num);
        System.out.println(number);  // 报错，非法的前向引用，但是不调用的话是不会有错的
    }

    private static int number = 10;

    public static void main(String[] args) {
        System.out.println(ClassInitTest.num); // 2
        System.out.println(ClassInitTest.number); // 10
    }
}

静态变量 number 的值变化过程如下

  • 准备阶段时：默认初始化 0
  • 执行静态代码块：20
  • 执行静态变量初始化：10

img

若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕

<init>() 方法初始化顺序

类的构造器方法是虚拟机视角下的<init>()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class ClinitTest {
    // 任何一个类声明以后，内部至少存在一个类的构造器
    private int a = 1;
    private static int c = 3;

    public static void main(String[] args) {
        int b = 2;
    }

    public ClinitTest(){
        a = 10;
        int d = 20;
    }
}

img

在构造器中：

  • 先将类变量 a 赋值为 10
  • 再将局部变量赋值为 20

关于涉及到父类时候的变量赋值过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class ClinitTest1 {
    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);
    }
}

上述代码，加载流程如下：

  • 首先，执行 main() 方法需要加载 ClinitTest1类
  • 获取 Son.b 静态变量，需要加载 Son 类
  • Son类的父类是 Father类，所以需要先执行 Father类的加载，再执行 Son类的加载

输出结果为 2，也就是说首先加载ClinitTest1的时候，会找到main()方法，然后执行Son的初始化，但是Son继承了Father，因此还需要执行Father的初始化，同时将A赋值为2。我们通过反编译得到Father的加载过程，首先我们看到原来的值被赋值成1，然后又被复制成2，最后返回

1
2
3
4
5
iconst_1
putstatic #2 <com/zhao/java/chapter02/ClinitTest1$Father.A>
iconst_2
putstatic #2 <com/zhao/java/chapter02/ClinitTest1$Father.A>
return

<clinit>() 的线程安全性

对于<clinit>()方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性。

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

因此，如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，引发死锁。并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息。

如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了。那么，当需要使用这个类时，虚拟机会直接返回给它已经准备好的信息。

代码演示死锁情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class DeadThreadTest {
    public static void main(String[] args) {
        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + "\t 线程t1开始");
            new DeadThread();
        }, "t1").start();

        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + "\t 线程t2开始");
            new DeadThread();
        }, "t2").start();
    }
}

class DeadThread {
    static {
        if (true) {
            System.out.println(Thread.currentThread().getName() + "\t 初始化当前类");
            while(true) {

            }
        }
    }
}

上面的代码，输出结果为

1
2
3
线程t1开始
线程t2开始
线程t2 初始化当前类

程序卡死，分析原因：

  • 两个线程同时去加载 DeadThread类，而 DeadThread类中静态代码块中有一处死循环
  • 先加载 DeadThread类的线程抢到了同步锁，然后在类的静态代码块中执行死循环，而另一个线程在等待同步锁的释放
  • 所以无论哪个线程先执行 DeadThread 类的加载，另外一个类也不会继续执行

从上面可以看出初始化后，只能够执行一次初始化，这也就是同步加锁的过程

类的主动使用和被动使用

Java程序对类的使用方式分为：主动使用和被动使用。

主动使用

Class 只有在必须要首次使用的时候才会被加载，Java虚拟机不会无条件地加载Class类型。即程序启动时并不会立即加载所有Class，而是会等待程序运行到需要使用该类时才会加载该类，但也不是都会执行初始化阶段，而是按需执行：需要用到时再初始化（即主动使用情况），不需要时不初始化。

并且每个类只会被加载一次，第二次使用该类时，不再需要加载初始化，可以直接从方法区中获取该类信息。

Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里指的“使用”，是指主动使用，即：如果出现如下的情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成。

主动使用有下列七种情况：

  • 创建类的实例
  • 访问某个类或接口的静态变量，或者对该静态变量赋值
  • 调用类的静态方法
  • 反射（比如：Class.forName("com.zhao.Test")）
  • 初始化一个类的子类
  • Java虚拟机启动时被标明为启动类的类（main() 方法所在类）
  • JDK 7开始提供的动态语言支持：
  • java.lang.invoke.MethodHandle实例的解析结果REF getStatic、REF putStatic、REF invokeStatic句柄对应的类没有初始化，则初始化

下面逐个举例：

  1. 创建类的实例：当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
/**
 * 反序列化
 */
Class Order implements Serializable {
    static {
        System.out.println("Order类的初始化");
    }
}

public void test() {
    ObjectOutputStream oos = null;
    ObjectInputStream ois = null;
    try {
        // 序列化
        oos = new ObjectOutputStream(new FileOutputStream("order.dat"));
        oos.writeObject(new Order());
        // 反序列化
        ois = new ObjectInputStream(new FileOutputStream("order.dat"));
        Order order = ois.readObject();
    }
    catch (IOException e){
        e.printStackTrace();
    }
    catch (ClassNotFoundException e){
        e.printStackTrace();
    }
    finally {
        try {
            if (oos != null) {
                oos.close();
            }
            if (ois != null) {
                ois.close();
            }
        }
        catch (IOException e){
            e.printStackTrace();
        }
    }
}
  1. 静态方法：当调用类的静态方法时，即当使用了字节码 invokestatic 指令。
  2. 静态字段：当使用类、接口的静态字段时（final修饰特殊考虑），比如，使用getstatic或者putstatic指令。（对应访问变量、赋值变量操作）
1
2
3
4
5
6
7
8
9
10
11
12
13
public class ActiveUse {
    @Test
    public void test() {
        System.out.println(User.num);
    }
}

class User {
    static {
        System.out.println("User类的初始化");
    }
    public static final int num = 1;
}
  1. 反射：当使用java.lang.reflect包中的方法反射类的方法时。比如：Class.forName("com.zhao.java.Test")
  2. 继承：当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

当Java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是该规则并不适用于接口

  • 在初始化一个类时，并不会先初始化它所实现的接口
  • 在初始化一个接口时，并不会先初始化它的父接口
  • 因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。
  1. default方法：如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化。
1
2
3
4
5
6
7
interface Compare {
	public static final Thread t = new Thread() {
        {
            System.out.println("Compare接口的初始化");
        }
    }   
}
  1. main() 方法：当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

JVM启动的时候通过引导类加载器加载一个初始类。这个类在调用public static void main(String[]) 方法之前被链接和初始化。这个方法的执行将依次导致所需的类的加载，链接和初始化。

  1. MethodHandle：当初次调用MethodHandle实例时，初始化该MethodHandle指向的方法所在的类。（涉及解析REF getStatic、REF_putStatic、REF invokeStatic方法句柄对应的类）

被动使用

除了以上几种情况，其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的 <clinit>() 初始化。被动使用时，类会被加载，但是不会进行初始化。

被动使用的举例：

  1. 静态字段：当通过子类引用父类的静态变量，不会导致子类初始化，只有真正声明这个字段的类才会被初始化。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class PassiveUse {
 	@Test
    public void test() {
        System.out.println(Child.num);
    }
}

class Child extends Parent {
    static {
        System.out.println("Child类的初始化");
    }
}

class Parent {
    static {
        System.out.println("Parent类的初始化");
    }
    
    public static int num = 1;
}
  1. 数组定义：通过数组定义类引用，不会触发此类的初始化
1
2
3
4
Parent[] parents= new Parent[10];
System.out.println(parents.getClass()); 
// new的话才会初始化
parents[0] = new Parent();
  1. 引用常量：引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class PassiveUse {
    public static void main(String[] args) {
        System.out.println(Serival.num);
        // 但引用其他类的话还是会初始化
        System.out.println(Serival.num2);
    }
}

interface Serival {
    public static final Thread t = new Thread() {
        {
            System.out.println("Serival初始化");
        }
    };

    public static int num = 10; 
    public static final int num2 = new Random().nextInt(10);
}
  1. 调用loadClass() 方法：调用ClassLoader某个子类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化（只会加载，连解析都不一定会执行，除非传入参数要求解析）。
1
Class clazz = ClassLoader.getSystemClassLoader().loadClass("com.test.java.Person");

扩展

1
-XX:+TraceClassLoading：追踪打印类的加载信息

卸载阶段

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

在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。

一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的java类都有一个静态属性class，它引用代表这个类的Class对象。

类的生命周期

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

一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。

image-20211014213433097

loader1变量和obj变量间接应用代表Sample类的Class对象，而objClass变量则直接引用它。

如果程序运行过程中，将上图左侧三个引用变量都置为null，此时Sample对象结束生命周期，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据被卸载。

当再次有需要时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不再重新加载；如果不存在Sample类会被重新加载，在Java虚拟机的堆区会生成一个新的代表Sample类的Class实例（可以通过哈希码查看是否是同一个实例）

类的卸载

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

综合以上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能。

类加载器

类加载的方式

类加载的方式：显式加载与隐式加载

.class文件的显式加载与隐式加载的方式是指JVM加载.class文件到内存的方式。

  • 显式加载指的是在代码中通过调用ClassLoader加载class对象，如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载Class对象。
  • 隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的.class文件时，该类的.class文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载到内存中。

在日常开发以上两种方式一般会混合使用。

1
2
3
4
5
6
7
//隐式加载
User user=new User();

//显式加载，并初始化
Class clazz = Class.forName("com.test.java.User");
//显式加载，但不初始化
ClassLoader.getSystemClassLoader().loadClass("com.test.java.Parent");

Class.forName(name)与this.getClass().getClassLoader().loadClass()加载Class对象的区别：

  • Class.forName()：是一个静态方法，最常用的是Class.forName(String className); 。其根据传入的类的全限定名返回一个Class对象。该方法在将Class文件加载到内存的同时，会执行类的初始化。
  • ClassLoader.loadClass()：这是一个实例方法，需要一个ClassLoader对象来调用该方法。 该方法将Class文件加载到内存时，并不会执行类的初始化（默认情况下解析阶段也不会执行），直到这个类第一次使用时才进行初始化（见后文源码分析，loadClass() 方法并没有初始化阶段的代码）。该方法因为需要得到一个ClassLoader对象，所以可以根据需要指定使用哪个类加载器。

类加载器的必要性

一般情况下，Java开发人员并不需要在程序中显式地使用类加载器，但是了解类加载器的加载机制却显得至关重要。从以下几个方面说：

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

命名空间

何为类的唯一性？

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器都拥有一个独立的类名称空间。不同类加载器间的命名空间不同，相互不干扰。

比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等。

命名空间

  • 每个类加载器都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成
  • 在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类
  • 在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类

在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本。

类加载器的分类

JVM支持两种类型的类加载器 。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。

从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。除了引导类加载器，其他类加载器都集成自抽象类ClassLoader，因此都属于自定义类加载器。

启动类加载器通过C/C++语言编写，而自定义类加载器都是由Java语言编写的，虽然扩展类加载器和应用程序类加载器是被JDK开发人员使用java语言来编写的，但是也是由java语言编写的，所以也被称为自定义类加载器。自定义类型加载器是由引导类加载器所加载的，在JVM启动时，引导类加载器加载并调用Launcher类，创建出自定义类型加载器，并创建一个单独的Launcher线程。

无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示：

img

这里的四者之间是包含关系，不是上层和下层，也不是子系统的继承关系。正是由于子类加载器中包含着父类加载器的引用，所以可以通过子类加载器的方法获取对应的父类加载器，这也是双亲委派机制实现的基础。

img

我们通过一个类，获取它不同的加载器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class ClassLoaderTest {
    public static void main(String[] args) {
        // 获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);

        // 获取其上层的：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);

        // 试图获取 根加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);

        // 获取自定义加载器
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader);

        // 获取String类型的加载器
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);
    }
}

得到的结果，从结果可以看出根加载器无法直接通过代码获取，同时目前用户代码所使用的加载器为系统类加载器。同时我们通过获取String类型的加载器，发现是null，那么说明String类型是通过根加载器进行加载的，也就是说Java的核心类库都是使用根加载器进行加载的。

1
2
3
4
5
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@1540e19d
null
sun.misc.Launcher$AppClassLoader@18b4aac2
null

img

说明：

  • 站在程序的角度看，引导类加载器与另外两种类加载器（系统类加载器和扩展类加载器）并不是同一个层次意义上的加载器，引导类加载器是使用C++语言编写而成的，而另外两种类加载器则是使用Java语言编写而成的。由于引导类加载器压根儿就不是一个Java类，因此在Java程序中只能打印出空值。
  • 数组类的Class对象，不是由类加载器去创建的，而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说，是通过Class.getClassLoader()返回的，与数组当中元素类型的类加载器是一样的；如果数组当中的元素类型是基本数据类型，数组类是没有类加载器的。

启动类加载器（引导类加载器，Bootstrap ClassLoader）

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

扩展类加载器（Extension ClassLoader）

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

img

应用程序类加载器（系统类加载器，AppClassLoader）

  • Java语言编写，由sun.misc.Launchers$AppClassLoader实现，是Launcher类的内部类
  • 派生于ClassLoader类
  • 父类加载器为扩展类加载器
  • 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库（用户自定义的类都由该加载器加载）
  • 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
  • 通过classLoader#getSystemclassLoader()方法可以获取到该类加载器

img

用户自定义类加载器

用户自定义的类加载器的父类加载器parent是 AppClassLoader，见下图：

image-20211015211158127

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。

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

  • 隔离加载类
  • 修改类加载的方式
  • 扩展加载源
  • 防止源码泄漏

体现Java语言强大生命力和巨大魅力的关键因素之一便是，Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包，也可以是网络上的远程资源。

通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。

同时，自定义加载器能够实现应用隔离。例如Tomcat，Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好太多，想不修改C/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想。

自定义类加载器通常需要继承于ClassLoader。用户自定义类加载器实现步骤：

  • 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
  • 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中，这样就不会破坏默认loadClass()方法里的双亲委派机制逻辑。
  • 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class CustomClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {

        try {
            byte[] result = getClassFromCustomPath(name);
            if (result == null) {
                throw new FileNotFoundException();
            } else {
                //defineClass和findClass搭配使用
                return defineClass(name, result, 0, result.length);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }

        throw new ClassNotFoundException(name);
    }
    
    //自定义流的获取方式
    private byte[] getClassFromCustomPath(String name) {
        //从自定义路径中加载指定类:细节略
        //如果指定路径的字节码文件进行了加密，则需要在此方法中进行解密操作。
        return null;
    }

    public static void main(String[] args) {
        CustomClassLoader customClassLoader = new CustomClassLoader();
        try {
            Class<?> clazz = Class.forName("One", true, customClassLoader);
            Object obj = clazz.newInstance();
            System.out.println(obj.getClass().getClassLoader());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

查看根加载器所能加载的目录

根加载器只能够加载 java/lib目录下的class，我们通过下面代码验证一下

1
2
3
4
5
6
7
8
9
10
11
12
13
public class ClassLoaderTest1 {
    public static void main(String[] args) {
        System.out.println("*********启动类加载器************");
        // 获取BootstrapClassLoader 能够加载的API的路径
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL url : urls) {
            System.out.println(url.toExternalForm());
        }

        // 从上面路径中，随意选择一个类，来看看他的类加载器是什么：得到的是null，说明是  根加载器
        ClassLoader classLoader = Provider.class.getClassLoader();
    }
}

得到的结果

1
2
3
4
5
6
7
8
9
10
*********启动类加载器************
file:/E:/Software/JDK1.8/Java/jre/lib/resources.jar
file:/E:/Software/JDK1.8/Java/jre/lib/rt.jar
file:/E:/Software/JDK1.8/Java/jre/lib/sunrsasign.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jsse.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jce.jar
file:/E:/Software/JDK1.8/Java/jre/lib/charsets.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jfr.jar
file:/E:/Software/JDK1.8/Java/jre/classes
null

img

ClassLoader 源码解析

关于 ClassLoader

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）

image-20200705103516138

img

其中，ExtClassLoader 和 AppClassLoader 都是sun.misc.Launcher 类的内部类。

Launcher

sun.misc.Launcher 是Java虚拟机的入口应用（启动器），由该类负责设置当前程序的系统类加载器：

image-20211015145906637

其中，创建扩展类加载器的细节：

image-20211015145400761

获取ClassLoader的途径：

  • 获取当前ClassLoader：clazz.getClassLoader()（每个Class对象都保存有加载其的类加载器对象）
  • 获取当前线程上下文的ClassLoader：Thread.currentThread().getContextClassLoader()
  • 获取系统的ClassLoader：ClassLoader.getSystemClassLoader()
  • 获取调用者的ClassLoader：DriverManager.getCallerClassLoader()

除了以上虚拟机自带的加载器外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

loadClass() 源码

当调用类加载器主动加载类时：this.getClass().getClassLoader().loadClass()，将经过以下过程：

  • findLoadedClass(name)：先在当前加载器的缓存中查找有无目标类，如果有，直接返回。
  • loadClass(name)：首先基于双亲委派机制，不断向上找父类加载器看是否能加载该类，一直找到引导类加载器；
  • 如果父类不能加载，则尝试调用当前类加载器的 findClass(name) 方法进行加载
  • findClass(name) 方法内将调用 defineClass(name, res) 方法（底层调用 native 本地方法），根据传入的类名称 name 和二进制流 res 将目标类进行加载，为其创建一个 Class 类型对象
  • 此时才完成了类的加载阶段，但是注意还没有进行链接阶段和初始化阶段
  • 如果 loadClass(name, resolve) 方法传入了参数 resolve == true，则将进行链接阶段：resolveClass(c)
  • loadClass() 方法并没有初始化阶段的代码，说明用这种方式加载类是不会初始化的，只有等到该类第一次被调用时才会执行<clinit>()初始化（区别于 Class.forName(name) 方式，该方式是会初始化的）。

image-20211015152354574

findClass(name) 类由 URLClassLoader重写，在其内调用 defineClass(name, res) 真正进行加载Class。该方法由 protected 修饰，说明是被保护的，只能由其子类调用，外部程序无法访问该方法，这是JVM的一种类加载保护机制。

image-20211015152829587

在 defineClass(name, res) 方法内，将根据传入的类名称 name 和二进制流 res 将目标类进行加载，为其创建一个 Class 类型对象，至此才即完成了类的加载，但是还没解析和初始化。

开发人员可以自定义类加载器继承URIClassLoader类，重写 findClass() 方法，在内编写自定义的加载流程，例如加密解密，但是必须最后在其内调用 defineClass() 方法加载类。

注意不要重写 loadClass() 方法，因为开发人员自定义的 loadClass() 方法可能会破坏双亲委派机制。

双亲委派模型

Java虚拟机对.class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的.class文件加载到内存生成Class对象。而且加载某个类的.class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。使用委派模型的目的是避免重复加载 Java 类型。

但不是所有类加载都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供些默认的参考实现。例如，Java中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器。

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

工作原理

  • 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
  • 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
  • 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。

image-20200705105151258

img

源码支持

image-20211015152354574

双亲委派机制在java.lang.ClassLoader.loadClass(String, boolean)接口中体现。该接口的逻辑如下：

  • 先在当前加载器的缓存中查找有无目标类，如果有，直接返回。
  • 判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name, false)接口进行加载。
  • 反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassorNull(name)接口，让引导类加载器进行加载。
  • 如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass()系列的native接口加载目标Java类。

双亲委派的模型就隐藏在这第2和第3步中。

举例

假设当前加载的是java.lang.Object这个类，很显然，该类属于JDK中核心得不能再核心的一个类，因此一定只能由引导类加载器进行加载。当]VM准备加载java.lang.Object时，JVM默认会使用系统类加载器去加载，按照上面4步加载的逻辑，在第1步从系统类的缓存中肯定查找不到该类，于是进入第2步。由于从系统类加载器的父加载器是扩展类加载器，于是扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也一定查找不到该类，因此进入第2步。扩展类的父加载器是null，因此系统调用findClass(String)，最终通过引导类加载器进行加载。

如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadclass(String, boolean)方法，抹去其中的双亲委派机制，仅保留上面这4步中的第l步与第4步，那么是不是就能够加载核心类库了呢？

这也不行！因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器亦或扩展类加载器，最终都必须调用 java.lang.ClassLoader.defineclass(String, byte[], int, int, ProtectionDomain)方法，而该方法会执行preDefineClass()接口，该接口中提供了对JDK核心类库的保护。

双亲委派模型的优势

双亲机制可以：

  • 避免类的重复加载
  • 保护程序安全，防止核心API被随意篡改
    • 自定义类：java.lang.String
    • 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang 开头的类）

双亲委派模型的弊端

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，引导类加载器加载的类为系统核心类，包括一些重要的系统接口，而系统类加载器加载的为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中（例如JDBC）。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。（引导类加载器向加载该类时，发现接口实现方法和工厂方法都在必须由系统类加载器加载，自己无法加载）

总结上面的情况：引导类加载器负责加载比较基础的类，但如果有时这些比较基础的类又要回调回其子类实现的方法（用户的代码），则由于双亲委派模型的限制，无法处理这种情况

一个典型的例子便是JNDI服务（Java Naming and Directory Interface，命名与目录接口），JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。

https://jiges.github.io/2017/12/08/JNDI是什么/ ，https://blog.csdn.net/wanxiaoderen/article/details/106638603

但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码。现在问题来了，启动类加载器是绝不可能认识、加载这些代码的（SPI：在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI，例如JDBC）。

解决方案：使用上下文类加载管理器。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码

image-20211018103731245

上图中rt.jar中有要实现的SPI核心类的基础接口，在加载它的接口时需要调用实现类中的方法，但引导类加载器无法加载其实现类，只能交给线程上下文类加载器。

结论

Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

破坏双亲委派机制

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。

在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。

第一次破坏双亲委派机制：重写 loadClass() 方法

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前一——即JDK1.2面世以前的“远古”时代。

由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。

上文我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

第二次破坏双亲委派机制：线程上下文类加载器

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的类加载器加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础的类又要回调回其子类实现的方法（用户的代码），该怎么办呢？

一个典型的例子便是JNDI服务（Java Naming and Directory Interface，命名与目录接口），JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码。现在问题来了，启动类加载器是绝不可能认识、加载这些代码的（SPI：在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI，例如JDBC）。

为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（ThreadContextClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则。但这也是无可奈何的事情。 例如JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式（类似于Spring Boot里的自动配置原理），这才算是给SPI的加载提供了一种相对合理的解决方案。

image-20211018103725540

默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。

第三次破坏双亲委派机制：代码热替换

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：**代码热替换(Hot Swap)、模块热部署(Hot Deployment)**等（即修改了本地.class文件后，程序可以热修改，无需重新启动加载）

IBM公司主导的JSR-291（即OSGiR4.2）实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。

当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

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

说明：只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的

小结：这里，我们使用了“被破坏”这个词来形容上述不符合双亲委派模型原则的行为，但这里“被破坏”并不一定是带有贬义的。只要有明确的目的和充分的理由，突破旧有原则无疑是一种创新。

正如：OSGi中的类加载器的设计不符合传统的双亲委派的类加载器架构，且业界对其为了实现热部署而带来的额外的高复杂度还存在不少争议，但对这方面有了解的技术人员基本还是能达成一个共识，认为OSGi中对类加载器的运用是值得学习的，完全弄懂了OSGi的实现，就算是掌握了类加载器的精粹。

热替换的实现

热替换是指在程序的运行过程中，不停止服务，只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断，修改必须立即表现在正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的，比如：PHP，只要替换了PHP源文件，这种改动就会立即生效，而无需重启Web服务器。

但对Java来说，热替换并非天生就支持，如果一个类已经加载到系统中，通过修改类文件，并无法让系统再来加载并重定义这个类。因此，在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader。

注意：由不同ClassLoader加载的同名类属于不同的类型，不能相互转换和兼容。即两个不同的ClassLoader加载同一个类，在虚拟机内部，会认为这2个类是完全不同的。根据这个特点，可以用来模拟热替换的实现，基本思路如下图所示：

image-20211018103711336

因为每次热替换时都创建了新的自定义 ClassLoader 实例，所以其加载的类都是不同的，就可以实现热替换的效果。

双亲委派机制举例

示例一：我们自己定义一个java.lang包，在其下面定义一个String类，里面声明了静态代码块

img

1
2
3
4
5
6
7
8
package java.lang;

public class String {

    static {
        System.out.println("我是自定义的String类的静态代码块");
    }
}

在一个测试类中加载String类，看看加载的String类是JDK自带的，还是我们自己编写的

1
2
3
4
5
6
public class StringTest {
    public static void main(String[] args) {
        String str = new java.lang.String();
        System.out.println("你好，世界");
    }
}

结果：程序并没有输出我们静态代码块中的内容，可见仍然加载的是 JDK 自带的 String类

img

示例二：在我们自己定义的 String 类中整个 main() 方法

1
2
3
4
5
6
7
8
9
10
11
public class String {

    static {
        System.out.println("我是自定义的String类的静态代码块");
    }

    //错误: 在类 java.lang.String 中找不到 main 方法
    public static void main(String[] args) {
        System.out.println("hello,String");
    }
}

img

原因：由于双亲委派机制，我们的String类是由引导类加载器加载的，而引导类加载器并没有main()方法，所以会报错。

示例三：当我们加载 jdbc.jar 用于实现数据库连接的时候，首先我们需要知道的是 jdbc.jar 是基于SPI接口进行实现的，所以在加载的时候，会进行双亲委派，最终从根加载器中加载SPI核心类，然后在加载SPI接口类，接着在进行反向委派，通过线程上下文类加载器进行实现类 jdbc.jar 的加载。

image-20200705105810107

示例四：在java.lang包下自定义类，发现出于保护机制，不允许我们自定义类。

1
2
3
4
5
6
7
package java.lang;

public class ShkStart {
    public static void main(String[] args) {
        System.out.println("hello!");
    }
}

img

沙箱安全机制

自定义String类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main()方法，就是因为加载的是rt.jar包中的String类。

这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

沙箱安全机制：

  • 保证程序安全
  • 保护Java原生的JDK代码

Java安全模型的核心就是Java沙箱（sandbox）。什么是沙箱？沙箱是一个限制程序运行的环境。

沙箱机制就是将Java代码限定在虚拟机特定的运行范围内，并且严格限制代码对本地系统资源访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏。

沙箱主要限制系统资源访问，那系统资源包括什么？CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。所有的Java程序运行都可以指定沙箱，可以定制安全策略。

JDK 1.0 时期

在Java中将执行程序分成本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码，可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中，安全依赖于沙箱（Sandbox）机制。如下图所示JDK 1.0安全模型：

image-20211018104311131

JDK 1.1 时期

JDK 1.0中如此严格的安全机制也给程序的功能扩展带来障碍，比如当用户希望远程代码访问本地系统的文件时候，就无法实现。

因此在后续的JDK 1.1版本中，针对安全机制做了改进，增加了安全策略。允许用户指定代码对本地资源的访问权限。如下图所示JDK1.1安全模型

image-20211018104404224

JDK 1.2 时期

在JDK 1.2版本中，再次改进了安全机制，增加了代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。如下图所示JDK1.2安全模型：

image-20211018104435405

JDK 1.6 时期

当前最新的安全机制实现，则引入了**域（Domain）**的概念。

虚拟机会把所有代码加载到不同的系统域和应用域。系统域部分专门负责与关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域（Protected Domain），对应不一样的权限（Permission）。

思想类似于操作系统里的核心态和用户态，用户态想访问系统资源时必须转为核心态

存在于不同域中的类文件就具有了当前域的全部权限，如下图所示，最新的安全模型：

image-20211018104641337

自定义类的加载器

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

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

常见的场景

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

注意

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

实现方式

Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

在自定义ClassLoader的子类时候，我们常见的会有两种做法:

  • 方式一：重写loadClass()方法
  • 方式二：重写findclass()方法

对比

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

说明

  • 其父类加载器是系统类加载器
  • JVM中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)接口(自定义类加载器并重写java.lang.ClassLoader.loadClass(String)接口的除外)，连JDK的核心类库也不能例外。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class CustomClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {

        try {
            byte[] result = getClassFromCustomPath(name);
            if (result == null) {
                throw new FileNotFoundException();
            } else {
                //defineClass和findClass搭配使用
                return defineClass(name, result, 0, result.length);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }

        throw new ClassNotFoundException(name);
    }
    
    //自定义流的获取方式
    private byte[] getClassFromCustomPath(String name) {
        //从自定义路径中加载指定类:细节略
        //如果指定路径的字节码文件进行了加密，则需要在此方法中进行解密操作。
        return null;
    }

    public static void main(String[] args) {
        CustomClassLoader customClassLoader = new CustomClassLoader();
        try {
            Class<?> clazz = Class.forName("One", true, customClassLoader);
            Object obj = clazz.newInstance();
            System.out.println(obj.getClass().getClassLoader());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Java 9 新特性

https://www.yuque.com/u21195183/jvm/mrgsug#9eca4c5f

为了保证兼容性，JDK9没有从根本上改变三层类加载器架构和双亲委派模型，但为了模块化系统的顺利运行，仍然发生了一些值得被注意的变动。

  • 扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器(platform class loader)。可以通过classLoader的新方法getPlatformClassLoader()来获取。
    JDK9时基于模块化进行构建（原来的rt.jar和tools.jar被拆分成数十个JMOD文件），其中的Java类库就已天然地满足了可扩展的需求，那自然无须再保留<JAVA_HOME>\lib\ext目录，此前使用这个目录或者java.ext.dirs系统变量来扩展JDK功能的机制已经没有继续存在的价值了。
  • 平台类加载器和应用程序类加载器都不再继承自java.net.URLClassLoader。现在启动类加载器、平台类加载器、应用程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader。

image-20211018105345375

如果有程序直接依赖了这种继承关系，或者依赖了URLClassLoader类的特定方法，那代码很可能会在JDK9及更高版本的JDK中崩溃。

  • 在Java9中，类加载器有了名称。该名称在构造方法中指定，可以通过getName()方法来获取。平台类加载器的名称是platform，应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。
  • 启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器（以前是C++实现），但为了与之前代码兼容，在获取启动类加载器的场景中仍然会返回null，而不会得到BootClassLoader实例。
  • 类加载的委派关系也发生了变动。当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。

image-20211018105552699

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class ClassLoaderTest {
    public static void main(String[] args) {
        System.out.println(ClassLoaderTest.class.getClassLoader());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent().getParent());

        //获取系统类加载器
        System.out.println(ClassLoader.getSystemClassLoader());
        //获取平台类加载器
        System.out.println(ClassLoader.getPlatformClassLoader());
        //获取类的加载器的名称
        System.out.println(ClassLoaderTest.class.getClassLoader().getName());
    }
}

其它

如何判断两个 class 对象是否相同

在JVM中表示两个class对象是否为同一个类存在两个必要条件：

  • 类的完整类名必须一致，包括包名。
  • 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同。

换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的。

JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。

相关面试题

准备阶段谈到静态变量，那么对于常量和不同静态变量有什么区别？

我们定义下面这样的类型，分别提供了普通静态变量、静态常量，常量又考虑到原始类型和引用类型可能有区别。

1
2
3
4
5
6

public class CLPreparation {
  public static int a = 100;
  public static final int INT_CONSTANT = 1000;
  public static final Integer INTEGER_CONSTANT = Integer.valueOf(10000);
}

普通原始类型静态变量 a 和引用类型（即使是常量），是需要额外调用 putstatic 等 JVM 指令的，这些是在显式初始化阶段执行，而不是准备阶段调用；而原始类型常量，则不需要这样的步骤。

蚂蚁金服：

  • 描述一下JVM加载Class文件的原理机制？
  • 一面：类加载过程

百度：

  • 类加载的时机
  • java类加载过程？
  • 简述java类加载机制？

腾讯：

  • JVM中类加载机制，类加载过程？

滴滴：

  • JVM类加载机制

美团：

  • Java类加载过程
  • 描述一下jvm加载class文件的原理机制

京东：

  • 什么是类的加载？
  • 哪些情况会触发类的加载？
  • 讲一下JVM加载一个类的过程JVM的类加载机制是什么？

蚂蚁金服：

  • 深入分析ClassLoader，双亲委派机制
  • 类加载器的双亲委派模型是什么？一面：双亲委派机制及使用原因

百度：

  • 都有哪些类加载器，这些类加载器都加载哪些文件？
  • 手写一个类加载器Demo
  • Class.forName(“java.lang.String”)和Class.getClassLoader().loadClass(“java.lang.String)有什么区别？

腾讯：

  • 什么是双亲委派模型？
  • 类加载器有哪些？

小米：

  • 双亲委派模型介绍一下

滴滴：

  • 简单说说你了解的类加载器
  • 一面：讲一下双亲委派模型，以及其优点

字节跳动：

  • 什么是类加载器，类加载器有哪些？

京东：

  • 类加载器的双亲委派模型是什么？
  • 双亲委派机制可以打破吗？为什么