类加载子系统

来源Bilibili尚硅谷宋红康老师JVM教程：硅谷2020最新版宋红康JVM教程

概述

完整图如下

类加载器子系统作用

• 类加载器子系统负责从 文件系统 或者 网络 中 加载Class文件 ，class文件在文件开头有特定的文件标识 –CAFE BABY。
• ClassLoader只负责 class 文件的加载，至于它是否可以运行，则由执行引擎 Execution Engine 决定。
• 加载的 类信息存放于一块称为方法区 的内存空间。除了类的信息外，方法区中还会 存放运行时常量池信息 ，可能还包括字符串字面量和数字常量（这部分常量信息是 Class 文件中常量池部分的内存映射）

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

类的加载过程

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

/**
 * @author C-z-k
 * @date 2022/6/30
 */
public class HelloLoader {
    public static void main(String[] args) {
        System.out.println("我已经被加载啦");
    }
}

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

完整的流程图如下所示

类加载的过程包括 加载 、验证 、准备 、解析 、初始化 。其中 加载 、验证 、准备 、初始化 这四个阶段发生的顺序是固定的，而 解析 阶段是有可能发生在初识化之后的。这与 Java 支持的 运行时绑定（晚期绑定或动态绑定）有关。除此之外，要注意的是 这几个阶段 是按顺序开始，而不是按顺序完成或结束，因为这些阶段通常是交叉混合的进行，通常一个阶段执行的过程种调用或激活另一个阶段。

加载阶段

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

加载class文件的方式

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

加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。

链接阶段

验证 Verify

目的在于确保 Class 文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。

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

• 文件格式验证: 验证字节流是否符合Class文件格式的规范；例如: 是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
• 元数据验证: 对字节码描述的信息进行语义分析(注意: 对比javac编译阶段的语义分析)，以保证其描述的信息符合Java语言规范的要求；例如: 这个类是否有父类，除了java.lang.Object之外。
• 字节码验证: 通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
• 符号引用验证: 确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用 -Xverifynone 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

工具：Binary Viewer查看

如果出现不合法的字节码文件，那么将会验证不通过，例如每个 .class 文件都以 CAFE BABY 开头，也被称为 魔数，协议的开头

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

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

准备 Prepare

为类变量分配内存并且设置该类变量的默认初始值，即零值。

/**
 *
 * @author C-z-k
 * @date 2022/6/30
 */
public class HelloApp {
    private static int a = 1;
    public static void main(String[] args) {
        System.out.println(a);
    }
}

• 上面的静态变量（类变量）a 在准备阶段会赋初始值，但不是1，而是0。（类变量在准备阶段 会赋初始默认值，数值类型即为0，引用类型为null）
• 这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化；（此时就是常量，直接赋值）
• 这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。

解析 Resolve

• 将常量池内的符号引用转换为直接引用的过程。直接引用 就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。解析动作主要针对 类 或 接口 、字段 、类方法 、接口方法 、方法类型 等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等

初始化阶段

• 初始化阶段就是执行类构造器法（）的过程。
• 此方法不需定义，是 javac 编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。也就是说，当我们代码中包含 static 变量的时候，就会有 clinit 方法
• 构造器方法中指令按语句在源文件中出现的顺序执行。
• （）不同于类的构造器。（关联：构造器是虚拟机视角下的（））若该类具有父类，JVM会保证子类的（）执行前，父类的 （）已经执行完毕。

初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式:

• 声明类变量是指定初始值
• 使用静态代码块为类变量指定初始值

JVM初始化步骤

• 假如这个类还没有被加载和连接，则程序先加载并连接该类
• 假如该类的直接父类还没有被初始化，则先初始化其直接父类
• 假如类中有初始化语句，则系统依次执行这些初始化语句

/**
 *
 * @author C-z-k
 * @date 2022/7/1
 */
public class ClassInitTest {
    private static int num = 1;
    static {
        num = 2;
        number = 20;
        System.out.println(num);
//        System.out.println(number);  //报错，非法的前向引用（static只能赋值，不能调用）
    }

    private static int number = 10;//在linking 的准备阶段 会赋初始默认值

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

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

/**
 * @author C-z-k
 * @date 2022/7/1
 */
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);
    }
}

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

iconst_1
putstatic #2 <com/atguigu/java/chapter02/ClinitTest1$Father.A>
iconst_2
putstatic #2 <com/atguigu/java/chapter02/ClinitTest1$Father.A>
return

虚拟机必须保证一个类的（）方法在多线程下被同步加锁。

/**
 *
 * @author C-z-k
 * @date 2022/7/1
 */
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) {//保证在第一次加载该类时，就是执行 cllint 类构造器时，停住

            }
        }
    }
}

上面的代码，输出结果为

t1	 线程t1开始
t2	 线程t2开始
t1	 初始化当前类

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

类初始化时机

只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种:

• 创建类的实例，也就是new的方式
• 访问某个类或接口的静态变量，或者对该静态变量赋值
• 调用类的静态方法
• 反射(如Class.forName(“com.pdai.jvm.Test”))
• 初始化某个类的子类，则其父类也会被初始化
• Java虚拟机启动时被标明为启动类的类(Java Test)，直接使用java.exe命令来运行某个主类

类加载器的分类

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

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

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

这里的四者之间是包含关系，不是上层和下层，也不是子系统的继承关系。

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

/**
 *
 * @author C-z-k
 * @date 2022/6/30
 */
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);
    }
}

输出结果为：

sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@4554617c
null
sun.misc.Launcher$AppClassLoader@18b4aac2
null

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

虚拟机自带的加载器

类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误(LinkageError错误)如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。

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

启动类加载器: Bootstrap ClassLoader，负责加载存放在 JDK\jre\lib (JDK代表JDK的安装目录，下同)下，或被 -Xbootclasspath 参数指定的路径中的，并且能被虚拟机识别的类库(如 rt.jar ，所有的 java.* 开头的类均被 Bootstrap ClassLoader 加载)。启动类加载器是无法被 Java 程序直接引用的。

扩展类加载器（Extension ClassLoader）

扩展类加载器: Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.*开头的类)，开发者可以直接使用扩展类加载器。

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

应用程序类加载器: Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径(ClassPath)所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

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

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

用户自定义类加载器实现步骤：

• 开发人员可以通过继承抽象类ava.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
• 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写1oadClass（）方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖1oadclass（）方法，而是建议把自定义的类加载逻辑写在findclass（）方法中
• 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass（）方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

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

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

/**
 * @author C-z-k
 * @date 2022/6/30
 */
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();
    }
}

得到的结果

*********启动类加载器************
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/lib/resources.jar
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/lib/rt.jar
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/lib/sunrsasign.jar
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/lib/jsse.jar
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/lib/jce.jar
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/lib/charsets.jar
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/lib/jfr.jar
file:/D:/Program%20Files/Java/jdk1.8.0_91/jre/classes

关于ClassLoader

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

sun.misc.Launcher 它是一个java虚拟机的入口应用

获取ClassLoader的途径

• 获取当前ClassLoader：clazz.getClassLoader()
• 获取当前线程上下文的ClassLoader：Thread.currentThread().getContextClassLoader()
• 获取系统的ClassLoader：ClassLoader.getSystemClassLoader()
• 获取调用者的ClassLoader：DriverManager.getCallerClassLoader()

JVM类加载机制

全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他 Class 也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入

父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类

缓存机制，缓存机制将会保证所有加载过的 Class 都会被缓存，当程序中需要使用某个 Class 时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成 Class 对象，存入缓存区。这就是为什么修改了 Class 后，必须重启JVM，程序的修改才会生效

双亲委派机制, 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

双亲委派机制过程

1. 当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。
2. 当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。
3. 如果 BootStrapClassLoader 加载失败(例如在$JAVA_HOME/jre/lib里未查找到该class)，会使用 ExtClassLoader 来尝试加载；
4. 若 ExtClassLoader 也加载失败，则会使用 AppClassLoader 来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。

沙箱安全机制

自定义string类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class）。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

双亲委派机制的优势

通过上面的例子，我们可以知道，双亲机制可以

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

其它

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

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

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

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

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