JVM_01_内存与垃圾回收_02_类加载子系统

本文介绍类加载子系统

1. 概述

我们知道，JVM的输入是class文件，首先就是通过类加载子系统将class文件生成到内存（方法区）中。可以说，类加载子系统是程序运行的基础。类加载子系统由加载、链接和初始化三部分组成。

1.1 作用

• 类加载子系统负责从文件系统中或者网络中加载Class文件，class文件在文件开头中有特定的文件标识【CAFEBABE】。
• 类加载器只负责class文件的加载，至于它是否能够运行，则由执行引擎来判断决定。
• 加载的类信息存放于一块称为方法区的内存空间，除了类的信息之外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量、数字常量等。【其实就是类代码、和常量信息】

一句话，类加载子系统就是充当一个快递员的作用，将class文件从硬盘加载到内存特定的位置。供后续执行引擎调用这些内存数据。

2. 类加载器与类的加载过程

类加载分为加载、链接和初始化三个步骤。

2.1 加载

注意，这里的加载指的是加载过程中的第一个步骤。加载的相关步骤说明如下：

1. 通过一个类的全限定名获取定义此类的二进制字节流；
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
3. 在内存中生成一个代表这个类的java.lang.Class对象【反射机制】，作为方法区这个类的各种数据的访问入口。

另外，.class字节码文件不只是可通过本地程序编译后获得，也可直接读取jar包等方式获取。主要有以下几种生成方式：

1. 从本地系统中直接加载【本地硬盘】
2. 通过网络获取，典型场景：Web Applet
3. 从zip压缩包中读取，比如jar、war格式的压缩包
4. 运行时计算生成，使用最多的是：动态代理技术
5. 由其他文件生成，典型场景：JSP应用
6. 从专有数据库中提取.class文件，比较少见
7. 从加密文件中获取，典型的防class文件被反编译的保护措施【因为一般情况下，可通过反编译class文件来还原出源码，从而盗版软件】

其实通过上面的第三个步骤，生成Class对象，可知，反射机制就是获取到这个Class对象，从而获取到该类中的一些源码操作。

2.2 链接

链接阶段可分为三个子过程：

1. 验证（Verify）

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

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

2. 准备（Prepare）

   为类变量分配内存并且设置该类变量的默认初始值，即零值。注意，是赋0，并不是初始化。

   注意，这里不包含用final修饰的static，因为final在编译的时候就会分配了（赋0），准备阶段会显式初始化，即不赋0，而是初始化。也不会为实例变量分配初始化，类变量会分配在方法区，而实例变量是会随着对象一起分配到Java堆中。因此说，这里的类变量实际上就是静态变量，也就是类变量。【注意类变量（静态变量）、类常量、实例变量的区别】。

3. 解析（Resolve）

   • 将常量池内的符号引用转换为直接引用的过程。【这里说的是，一个普通的java程序，虽然比较短小，但是也包含了一些常用的基础类，比如System、Object等等，这些没有显式调用，此时就是符号引用】
   • 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
   • 符号引用就是一组符号来描述引用的目标。而直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
   • 解析操作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。

2.3 初始化

• 初始化阶段就是执行类构造器方法<clinit>()的过程，这个方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。注意，类变量和静态代码块，以及赋值操作，是针对上面准备阶段的赋0操作的后续操作，如果没有类变量和静态代码块，就不会有这个<clinit>()类构造器方法。

• 构造器方法中指令按语句在源文件中出现的顺序执行。注意，这个类构造器方法<clinit()>不同于类的构造器（关联：构造器是虚拟机视角下的<init>()）

• 若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕。和类构造器类似。

• 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。

  我们知道，对于一个类，只会在方法区内存中加载一份，即只会调用一次<clinit>()方法。所以如果在多线程环境下，其实<clinit>()实现了单例模式。

注意，类构造器方法<clinit>()和类构造器<init>()的区别。任何一个类，肯定会有<init>()，但是不一定有<clinit>()，只有有类变量或静态代码块才会有该类构造器方法。

2.4 案例

public class ClassInitTest{
    
    private static int num = 1;
    
    static {
        num = 2;
        number = 20;
    }
    
    private static int number = 10;
    
    public static void main(String[] args) {
        
        System.out.println(ClassInitTest.num); // 2
        Systen.out.println(ClassInitTest.number); // 10
        
    }
    
}

注意，在Java语法阶段，静态变量是可以先使用后定义的，也就是在static中使用，后面定义。这是为什么呢？因为类加载后三个阶段，加载、链接和初始化，在链接中的准备阶段，会先对类变量赋0操作，即此时已经有了这个变量了。而

不过，虽然可以赋值，但是不允许使用这个number变量，报错：非法的前向引用。这里只是为了说明可以赋值这样操作，以及类加载的各个阶段，真实情况下是不会写这样的代码的。

3. 类加载器分类

上面讲解了类的加载过程，接下来讲解一下类加载器分类。

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

注意，从字面意思上说，自定义类加载器指的是我们自己定义的类加载器，但是这里并不然。JVM规范中指出，所有继承自抽象类ClassLoader的类加载器都划分为自定义类加载器。因此，在概述中讲到的扩展类加载器和系统类加载器（应用程序类加载器）都属于自定义类加载器。

如下所示，注意，四类加载器不是继承关系，而是包含关系、上下层关系。Bootstrap ClassLoader是用C++语言写的，而下面的三类类加载器则是Java语言编写的。个人认为：引导类加载器似乎属于系统级别/根级别的。

下面代码是获取各个类加载器。

用户自定义类的类加载器默认是系统类加载器，而Java核心类库中的类，使用的是引导类加载器。

public class Jvm_test01 {

    public static void main(String[] args) {

        // 获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);
        // jdk.internal.loader.ClassLoaders$AppClassLoader@6d06d69c

        // 获取系统类加载器的上层：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);
        // jdk.internal.loader.ClassLoaders$PlatformClassLoader@6b884d57

        // 获取扩展类加载器的上层：【本应该是引导类加载器，但是这里是无法获取到的】
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);
        // null

        // 对于用户自定义类来说，默认使用系统类加载器进行加载
        ClassLoader classLoader = Jvm_test01.class.getClassLoader();
        System.out.println(classLoader);
        // jdk.internal.loader.ClassLoaders$AppClassLoader@6d06d69c

        // 对于Java自带的类来说，使用的类加载器，这里输出也是null，可以推测应该就是引导类加载器
        // 因此，Java核心类库，都是使用的是引导类加载器加载的。
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);
        // null

    }
}

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

1. 这个类加载使用C/C++语言实现的，嵌套在JVM内部。所以无法获取到具体的类名。
2. 它用来加载Java的核心库，用于提供JVM自身需要的类。（JAVA_HOME/jre/lib/rt.jar、resources.jar、sun.boot.class.path路径下的内容）。
3. 并不继承自java.lang.ClassLoader，没有父加载器。
4. 加载扩展类和系统类加载器，并指定为他们的父类加载器。
5. 处于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类（即核心类库）

3.2 扩展类加载器（Extension ClassLoader）

1. Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。
2. 继承自ClassLoader类
3. 父类加载器为启动类加载器【注意，父类加载器并不是继承】
4. 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录下的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的jar放在此目录下，也会自动由扩展类加载器加载。即核心类库之外的扩展类库。

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

1. Java语言编写，由sun.misc.Launcher$AppClassLoader实现
2. 继承自ClassLoader类
3. 父类加载器为扩展类加载器【注意，父类加载器并不是继承】
4. 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库。
5. 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来加载完成。
6. 通过ClassLoader.getSystemClassLoader()方法可以获取到该类加载器。

3.4 用户自定义类加载器

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

那么为什么要自定义类加载器呢？或者什么需求时需要自定义加载器呢？

1. 隔离加载类（比如说，不同的包之间）
2. 修改类加载的方式
3. 扩展加载源
4. 防止源码泄露（比如对加密的.class文件进行自定义解密，从而还原出真正的class文件，生成Class对象）

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

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

4. ClassLoader的使用说明

ClassLoader抽象类是除了引导类加载器之外，其他所有类加载器的父类。ClassLoader主要有以下常用的非抽象方法：

方法名称	描述
getParent()	返回该类加载器的父类加载器
loadClass(String name)	加载名称为name的类，返回结果为java.lang.Class类的实例
findClass(String name)	查找名称为name的类，返回结果为java.lang.Class类的实例
findLoadedClass(String name)	查找名称为name的已经被加载的过的类，返回结果为java.lang.Class类的实例
definedClass(String name, byte[] b, int off, int len)	把字节数组b中的内容转换为一个java类，返回结果为java.lang.Class类的实例
resolveClass(Class<?> c)	连接指定的一个Java类

获取ClassLoader有如下几种方式：

方式	描述
class.getClassLoader()	获取当前类的ClassLoader
Thread.currentThread().getContextClassLoader()	获取当前线程上下文的ClassLoader（系统类加载器）
ClassLoader.getSystemClassLoader()	获取系统的ClassLoader（系统类加载器）
DriverManager.getCallerClassLoader()	获取调用者的ClassLoader

5. 双亲委派机制

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

可以想象，如果自定义的类和Java自带的类是重名的，这该怎么办呢？显然这是不允许的，类似保留字，不允许被用户自定义同名变量。【当然这和IDEA等IDE是没有关系的，即使IDE提示了，但是和JVM是没有关系的。】

那么上述问题该怎么解决呢？双亲委派机制。

工作原理：

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

因此，回到上面的问题，当自定义和Java类库重名的类时，因为系统类加载器最终会递归到引导类加载器，此时就会引导类加载器以及扩展类记载器就会加载Java核心类库以及扩展类库中的类，所以，如果重名，显然父类类加载器完成了加载任务，此时系统类加载器就不再加载了，其实就是自定义类的加载优先级最最低的。即使定义了重名类名，也不会“干扰”程序运行。即向上委托，向下加载。

因此，双亲委派机制有以下几个优点：

1. 避免类的重复加载
2. 保证程序安全，防止核心API被随意篡改
   1. 比如自定义类和Java核心类等重名：java.lang.String。加载的时候，由引导类加载器加载。
   2. 自定义类的包名和Java核心包重名：java.lang.Hianian。加载的时候，依然由引导类记载器加载，但是在该包中找不到这个类，报错，不允许出现该包中不存在的类，即该包中的类一定能找到，但是这里竟然找不到，所以会报SecurityException。

5.1 沙箱安全机制

这个其实就是双亲委派机制的衍生品，因为双亲委派机制保证了Java核心源码的安全性，即沙箱安全机制。

6. 其他

6.1 class对象以及类加载器引用

在Java普通对象中，如果二者相等，那么一定是其内存地址相同。那么对于Class对象呢？

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

1. 类的完整类名必须一致，包括包名。
2. 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同，如均为引导类加载器、系统类加载器等等。

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

另外，JVM必须知道一个类型到底是由引导类加载器加载的还是由自定义类加载器加载的。如果一个类型是由自定义类加载器加载的，那么JVM将会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中（即前面通过class对象.getClassLoader()可获取到自定义类加载器）。

当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的（即引导类加载器和自定义类加载器）。

6.2 类的主动使用和被动使用

Java程序对类的使用方式分为：主动使用和被动使用。二者的区别就是是否会导致类的初始化【clinit】。

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

1. 创建类的实例

2. 访问某个类或接口的静态变量，或者对该静态变量赋值

3. 调用类的静态方法

4. 反射（比如：Class.forName(“org.hianian.Test”)）

5. 初始化一个类的子类

6. Java虚拟机启动时被标明为启动类的类

7. JDK 7 开始提供的动态语言支持：

   java.lang.invoke.MethodHandle实例的解析结果，REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化

除了上述7种主动使用，其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化。

注意，无论主动还是被动，都是使用了这个类，肯定会类加载中的加载，但是不一定会涉及到类加载中的初始化【即静态变量、静态代码块】。

7. 备注

参考B站《尚硅谷》。