第3章：类的加载过程(类的生命周期)详解

概述

在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行悉类的加载。(这里的类不是狭义上的类，而是包括：接口，注解，枚举)

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

其中，验证、准备、解析3个部分统称为链接（Linking）

从程序中类的使用过程来看：

我们所说的加载完毕包括**：加载、链接、初始化三个阶段都完成之后类进入方法区**中

我们待会所讲的是按照五个阶段来进行讲解的。

大厂面试题

蚂蚁金服:
描述一下JVM加载class文件的原理机制？一面：类加载过程

百度:
类加载的时机
java类加载过程?
简述java类加载机制?

腾讯:
JVM中类加载机制，类加载过程?

滴滴:
JVM类加载机制

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

京东:
什么是类的加载?
哪些情况会触发类的加载?讲一下JVM加载一个类的过程JVM的类加载机制是什么?

过程一：Loading（加载）阶段

加载完成的操作

加载的理解

所谓加载，简而言之就是将Java类的字节码文件加载到机器内存中，并在内存中构建出Java类的原型——类模板对象。所谓类模板对象，其实就是Java类在JVM内存中的一个快照。JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样JVM在运行期便能通过类模板而获取Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用。（类模板，是放在方法区中）

反射的机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射。

加载完成的操作

加载阶段，简言之，查找并加载类的二进制数据，生成Class的实例。

在加载类时，Java虚拟机必须完成以下3件事情：

• 通过类的全名（全类名，即包名+类名），获取类的二进制数据流。
• 解析类的二进制数据流为方法区内的数据结构( Java类模型)
• 创建java.lang.Class类的实例，表示该类型。作为方法区这个类的各种数据的访问入口（堆空间中的实例，指向了方法区中的实例模板）

二进制流的获取方式

对于类的二进制数据流，虚拟机可以通过多种途径产生或获得。(只要所读取的字节码符合JVM规范即可)

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

在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为一个java.lang.Class的实例。

如果输入数据不是ClassFile的结构，则会抛出ClassFormatError。(合法的字节码文件是以**cafebabe**开头)

类模型与Class实例的位置

类模型的位置

加载的类在JVM中创建相应的类结构，类结构会存储在方法区（JDK1.8之前：永久代；JDK1.8及之后：元空间)。（）

Class实例的位置

类将.class文件加载至元空间后，会在堆中创建一个Java.lang .Class对象，用来封装类位于方法区内的数据结构，该Class对象是在加载类的过程中创建的，每个类都对应有一个Class类型的对象。（instanceKlass -->mirror：Class实例）（具体的细节要看《深入理解Java虚拟机》）

堆空间的对象的实例，指向了方法区中的类模板对象，如下图所示 。

外部可以通过Order类的Class对象来获取Class对象的类数据结构（反射）

例如

/** * @author shkstart * @create 2020-09-11 17:39 * 过程一：加载阶段 * * 通过Class类，获得了java.lang.String类的所有方法信息，并打印方法访问标识符、描述符 */
public class _1LoadingTest {
    
    public static void main(String[] args) {
    
        try {
    
            Class clazz = Class.forName("java.lang.String");
            //获取当前运行时类声明的所有方法
            Method[] ms = clazz.getDeclaredMethods();
            for (Method m : ms) {
    
                //获取方法的修饰符
                String mod = Modifier.toString(m.getModifiers());
                System.out.print(mod + " ");
                //获取方法的返回值类型
                String returnType = m.getReturnType().getSimpleName();
                System.out.print(returnType + " ");
                //获取方法名
                System.out.print(m.getName() + "(");
                //获取方法的参数列表
                Class<?>[] ps = m.getParameterTypes();
                if (ps.length == 0) System.out.print(')');
                for (int i = 0; i < ps.length; i++) {
    
                    char end = (i == ps.length - 1) ? ')' : ',';
                    //获取参数的类型
                    System.out.print(ps[i].getSimpleName() + end);
                }
                System.out.println();
            }
        } catch (ClassNotFoundException e) {
    
            e.printStackTrace();
        }

    }
}

再说明

Class类的构造方法是私有的，只有JVM能够创建。

    private Class(ClassLoader loader) {
    
        // Initialize final field for classLoader. The initialization value of non-null
        // prevents future JIT optimizations from assuming this final field is null.
        classLoader = loader;
    }

java.lang.Class实例是访问类型元数据的接口，也是实现反射的关键数据、入口。通过Class类提供的接口，可以获得目标类所关联的.class文件中具体的数据结构：方法、字段等信息。

数组类的加载

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

1. 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载（也就是加载数组中的引用数据类型）和创建数组A的元素类型；
2. JVM使用指定的元素类型和数组维度来创建新的数组类。

如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。(如果是基本数据类型，就看作是public就行)

过程二：Linking（链接）阶段

环节1：链接阶段之Verification（验证）

验证阶段(Verification)
当类加载到系统后，就开始链接操作，验证是链接操作的第一步。
它的目的是保证加载的字节码是合法、合理并符合规范的。

验证的步骤比较复杂，实际要验证的项目也很繁多，大体上Java虚拟机需要做以下检查，如图所示。

整体说明:
验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证，以及符号引用验证等。

• 其中格式验证会和加载阶段一起执行。验证通过之后，类加载器才会成功将类的二进制数据信息加载到方法区中。
• 格式验证之外的验证操作将会在方法区中进行。

链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行各种检查。(磨刀不误砍柴工)

具体说明：

1. 格式验证：是否以魔数0xCAFEBABE开头，主版本和副版本号是否在当前Java虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。

2. Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给予验证通过。比如：

   1. 是否所有的类都有父类的存在(在java里，除了object外，其他类都应该有父类)
   2. 是否一些被定义为final的方法或者类被重写或继承了
   3. 非抽象类是否实现了所有抽象方法或者接口方法
   4. 是否存在不兼容的方法（比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度；abstract情况下的方法，就不能是final的了)

3. Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：

   1. 在字节码的执行过程中，是否会跳转到一条不存在的指令
   2. 函数的调用是否传递了正确类型的参数
   3. 变量的赋值是不是给了正确的数据类型等

栈映射帧(StackMapTable)就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的。

在前面3次检查中，已经排除了文件格式错误、语义错误以及字节码的不正确性。但是依然不能确保类是没有问题的。

4. 校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个方法无法被找到，则会抛出NoSuchMethodError。
   此阶段在解析环节才会执行。

环节2：链接阶段之Preparation（准备）

准备阶段(Preparation)，简言之，为类的**静态变量（类变量）**分配内存，并将其初始化为默认值。（类的加载阶段，初始化的肯定是类变量也就是静态变量）
当一个类验证通过时，虚拟机就会进入准备阶段。在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值。Java虚拟机为各类型变量默认的初始值如表所示。

注意：Java并不支持boolean类型，对于boolean类型，内部实现是int ,由于int的默认值是0 ,故对应的， boolean的默认值就是false。

1. 这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显式赋值。
2. 其实不管是静态还是非静态只要用final修饰，它的值在编译期间就已经确定好了的。
3. 注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。
4. 在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。

源代码

public class _2LinkingTest {
    
    private static long id;//
    private static final int num = 1; //
    private  final int result = 33; //

    public static final String constStr = "CONST";
// public static final String constStr1 = new String("CONST");

    public Object getObj(){
    
        return null;
    }

    public void print1(){
    
        System.out.println("hello");
    }
}

字节码

public class _2LinkingTest {
    
    private static long id;
    private static final int num = 1;
    private final int result = 33;
    public static final String constStr = "CONST";

    public _2LinkingTest() {
    
    }

    public Object getObj() {
    
        return null;
    }

    public void print1() {
    
        System.out.println("hello");
    }
}

如果使用字面量的方式定义一个字符串的常量的话，也是在准备环节直接进行显示赋值。

可以看到下图的constStr1并没赋值，没有那ConstantValue

环节3：链接阶段之Resolution(解析)

在准备阶段完成后，就进入了解析阶段。
解析阶段(Resolution)，简言之，将类、接口、字段和方法的符号引用转为直接引用。

1. 具体描述：

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

举例：输出操作System.out. println()对应的字节码:

invokevirtual #5 <java/io/PrintStream.println>

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

2. 小结

所谓解析就是将符号引用转为直接引用，也就是得到类、字段、方法在内存中的指针或者偏移量。因此，可以说，如果直接引用存在，那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用，不能确定系统中一定存在该结构。

不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中，加载、验证、准备和初始化会按照顺序有条不紊地执行，但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。

3. 字符串的复习

最后，再来看一下CONSTANT_String的解析。由于字符串在程序开发中有着重要的作用，因此，读者有必要了解一下String在Java虚拟机中的处理。当在Java代码中直接使用字符串常量时，就会在类中出现CONSTANT_String，它表示字符串常量，并且会引用一个CONSTANT_UTF8的常量项。在Java虚拟机内部运行中的常量池中，会维护一张字符串拘留表(intern)，它会保存所有出现过的字符串常量并且没有重复项。只要以CONSTANT_String形式出现的字符串也都会在这张表中。使用String.intern()方法可以得到一个字符串在拘留表中的引用，因为该表中没有重复项，所以任何字面相同的字符串的String.intern()方法返回总是相等的。（其实就是之前学的字符串的相关面试题）

过程三：Initialization（初始化）阶段

初始化阶段，简言之，为类的静态变量赋予正确的初始值。

1. 具体描述

类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。（即：到了初始化阶段，才真正开始执行类中定义的 Java程序代码。)
初始化阶段的重要工作是执行类的初始化方法（类构造器方法）：<clinit>()方法。。

• 该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成。
• 它是由类静态成员的赋值语句以及static语句块合并产生的。

给静态变量或者代码块显示赋值

2. 说明

2.1 在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<clinit>总是在子<clinit>之前被调用。也就是说，父类的static块优先级高于子类。
口诀：由父及子，静态先行。

父类

public class _3InitializationTest {
    
    public static int id = 1;
    public static int number;

    static {
    
        number = 2;
        System.out.println("father static{}");
    }
}

子类

public class _4SubInitialization extends _3InitializationTest {
    
    static{
    
        number = 4; // 这里要使用number属性，必须提前已经加载，所以一定是先加载父类
        System.out.println("son static{}");
    }

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

输出结果

father static{
    }
son static{
    }
4

2. 2 Java编译器并不会为所有的类都产生<clinit>()初始化方法。哪些类在编译为字节码后，字节码文件中将不会包含<clinit>()方法
   • 一个类中并没有声明任何的类变量，也没有静态代码块时
   • 一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时
   • 一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式

static与final的搭配问题

说明：使用static + final修饰的字段的显式赋值的操作，到底是在哪个阶段进行的赋值？
情况1：在链接阶段的准备环节赋值
情况2：在初始化阶段<clinit>()中赋值

结论：

在链接阶段的准备环节赋值的情况：

1. 对于基本数据类型的字段来说，如果使用static final修饰，则显式赋值(直接赋值常量，而非调用方法）通常是在链接阶段的准备环节进行，如果只是static修饰那就是在初始化阶段（<clinit>）赋值
2. 对于String来说，如果使用字面量的方式赋值，使用static final修饰的话，则显式赋值通常是在**链接阶段的准备环节进行**
3. 没有使用final修饰，那就考虑是在初始化阶段进行

在初始化阶段<clinit>()中赋值的情况：
排除上述的在准备环节赋值的情况之外的情况。

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

public class _6InitializationTest2 {
    
    public static int a = 1;//在初始化阶段<clinit>()中赋值
    public static final int INT_CONSTANT = 10;//在链接阶段的准备环节赋值

    public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100);//在初始化阶段<clinit>()中赋值
    public static Integer INTEGER_CONSTANT2 = Integer.valueOf(1000);//在初始化阶段<clinit>()中赋值，这可能是应为调用了Integer

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

    public static String s2 = "helloworld2";

    public static final int NUM1 = new Random().nextInt(10);//在初始化阶段<clinit>()中赋值
}

<clinit>的字节码文件

 0 iconst_1
 1 putstatic #2 <com/atguigu/java/_6InitializationTest2.a> // 这里可以看到a是在初始化阶段进行复制的
 4 bipush 100
 6 invokestatic #3 <java/lang/Integer.valueOf>
 9 putstatic #4 <com/atguigu/java/_6InitializationTest2.INTEGER_CONSTANT1> // 可以看到是在准备阶段赋值
12 sipush 1000
15 invokestatic #3 <java/lang/Integer.valueOf>
18 putstatic #5 <com/atguigu/java/_6InitializationTest2.INTEGER_CONSTANT2> // 可以看到是在准备阶段赋值
21 new #6 <java/lang/String>
24 dup
25 ldc #7 <helloworld1>
27 invokespecial #8 <java/lang/String.<init>>
30 putstatic #9 <com/atguigu/java/_6InitializationTest2.s1>
33 ldc #10 <helloworld2>
35 putstatic #11 <com/atguigu/java/_6InitializationTest2.s2>
38 new #12 <java/util/Random>
41 dup
42 invokespecial #13 <java/util/Random.<init>>
45 bipush 10
47 invokevirtual #14 <java/util/Random.nextInt>
50 putstatic #15 <com/atguigu/java/_6InitializationTest2.NUM1>
53 return

static final修饰的基本数据类型是在初始化阶段进行赋值

对于String来说，如果使用字面量的方式赋值，使用static final修饰的话，则显式赋值通常是在**链接阶段的准备环节进行**，不是字面量的话，就是在初始化阶段进行赋值的。

21 new #6 <java/lang/String>
24 dup
25 ldc #7 <helloworld1>

<client>()的线程安全性

这是下面的死锁情况，初始化A的时候又去加载B，初始化B的时候又去加载A

回顾一下死锁的四个条件

1. 互斥：资源必须处于非共享模式，即一次只有一个进程可以使用。如果另一进程申请该资源，那么必须等待直到该资源被释放为止。
2. 占有并等待：一个进程至少应该占有一个资源，并等待另一资源，而该资源被其他进程所占有。
3. 非抢占：资源不能被抢占。只能在持有资源的进程完成任务后，该资源才会被释放。
4. 循环等待：有一组等待进程 {P0, P1,..., Pn}， P0 等待的资源被 P1 占有，P1 等待的资源被 P2 占有，…，Pn-1 等待的资源被 Pn 占有，Pn 等待的资源被 P0 占有。

这下面的代码会出现死锁

class StaticA {
    static {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
        }
        try {
            // 在初始化A的时候，去加载B
            Class.forName("com.atguigu.java1.StaticB");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        System.out.println("StaticA init OK");
    }
}
class StaticB {
    static {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
        }
        try {
            // 在初始化B的时候去加载A
            Class.forName("com.atguigu.java1.StaticA");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        System.out.println("StaticB init OK");
    }
}

public class StaticDeadLockMain extends Thread {
    private char flag;

    public StaticDeadLockMain(char flag) {
        this.flag = flag;
        this.setName("Thread" + flag);
    }

    @Override
    public void run() {
        try {
            Class.forName("com.atguigu.java1.Static" + flag);
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        System.out.println(getName() + " over");
    }

    public static void main(String[] args) throws InterruptedException {
        StaticDeadLockMain loadA = new StaticDeadLockMain('A');
        loadA.start();
        StaticDeadLockMain loadB = new StaticDeadLockMain('B');
        loadB.start();
    }
}

类的初始化情况：主动使用vs被动使用

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

主动使用的类就会调用<clinit>，被动使用类就不会调用<clinit>

主动使用

Class只有在必须要首次使用的时候才会被装载，Java虚拟机不会无条件地装载Class类型。Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里指的"使用"，是指主动使用，主动使用只有下列几种情况:（即：如果出现如下的情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成。)

1. 当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化。
2. 当调用类的静态方法时，即当使用了字节码invokestatic指令。
3. 当使用类、接口的静态字段时(final修饰特殊考虑)，比如，使用getstatic或者putstatic指令。(对应访问变量、赋值变量操作）
4. 当使用java.lang.reflect包中的方法反射类的方法时。比如: Class.forName(" com.atguigu.java.Test")
5. 当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
6. 如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化。
7. 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
8. 当初次调用MethodHandle实例时，初始化该MethodHandle指向的方法所在 的类。(涉及解析
   REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类)

针对5，补充说明:
当Java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则并不适用于接口。

在初始化一个类时，并不会先初始化它所实现的接口

在初始化一个接口时，并不会先初始化它的父接口

因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。

被动使用

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

1. 当访问一个静态字段时，只有真正声明这个字段的类才会被初始化。

   • 当通过子类引用父类的静态变量，不会导致子类初始化

2. 通过数组定义类引用，不会触发此类的初始化

3. 引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。

4. 调用ClassLoader类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化。

主动使用代码示例

代码示例：

1. 反序列化导致主动使用

    //反序列化的过程：（验证）
    @Test
    public void test2() {
    
        ObjectInputStream ois = null;
        try {
    
            ois = new ObjectInputStream(new FileInputStream("order.dat"));

            Order order = (Order) ois.readObject();
        } catch (IOException e) {
    
            e.printStackTrace();
        } catch (ClassNotFoundException e) {
    
            e.printStackTrace();
        } finally {
    
            try {
    
                if (ois != null)
                    ois.close();
            } catch (IOException e) {
    
                e.printStackTrace();
            }
        }

    }

2. 调用静态方法导致主动使用

3. 接口中的主动调用

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

    public static final int NUM1 = 1; // 1
// public static final int NUM2 = new Random().nextInt(10); //CompareA的初始化 1


}
    @Test
    public void test2() {
    
        System.out.println(CompareA.NUM1);
// System.out.println(CompareA.NUM2);
    }

CompareA的字节码

 0 new #1 <com/atguigu/java1/CompareA$1>
 3 dup
 4 invokespecial #2 <com/atguigu/java1/CompareA$1.<init>>
 7 putstatic #3 <com/atguigu/java1/CompareA.t>
10 return

它的这个new #1 其实就是new Thread，跳转到了下面

 0 aload_0
 1 invokespecial #1 <java/lang/Thread.<init>>
 4 getstatic #2 <java/lang/System.out>
 7 ldc #3 <CompareA的初始化>
 9 invokevirtual #4 <java/io/PrintStream.println>
12 return

所以因此可以验证，只要出现了CompareA的初始化就说明是接口被初始化了，即主动使用。

使用-XX:+TraceClassLoading参数打印类的加载信息

被动使用代码示例

关于类的被动使用，即不会进行类的初始化操作，即不会调用<clinit>()

1. 当通过子类引用父类的静态变量，不会导致子类初始化

    @Test
    public void test1(){
    
        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;
}

输出结果

Parent的初始化过程
1

2. 通过数组定义类引用，不会触发此类的初始化

    @Test
    public void test2(){
    
        Parent[] parents = new Parent[10];
            }

3. 引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。

变量值没有加final修饰，就会触发<clinit>，这个是在初始化阶段进行赋值的。

    @Test
    public void test1(){
    
        System.out.println(Person.NUM); // 会触发<clinit>
    }

class Person{
    
    static{
    
        System.out.println("Person类的初始化");
    }
    public static  int NUM = 1;//在链接过程的准备环节就被赋值为1了。
    public static final int NUM1 = new Random().nextInt(10);//此时的赋值操作需要在<clinit>()中执行
}

变量值加上final修饰，就会不会触发<clinit>，因为这个变量的值是在链接阶段的准备阶段就已经赋好值了的。

    @Test
    public void test1(){
    
        System.out.println(Person.NUM); // 不会触发<clinit>
    }

class Person{
    
    static{
    
        System.out.println("Person类的初始化");
    }
    public static final int NUM = 1;//在链接过程的准备环节就被赋值为1了。
    public static final int NUM1 = new Random().nextInt(10);//此时的赋值操作需要在<clinit>()中执行
}

4. 调用ClassLoader类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化。

    @Test
    public void test3(){
    
        try {
    
            Class clazz = ClassLoader.getSystemClassLoader().loadClass("com.atguigu.java1.Person");
        } catch (ClassNotFoundException e) {
    
            e.printStackTrace();
        }
    }

过程四：类的Using（使用）

任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后，便“万事俱备，只欠东风”，就等着开发者使用了。

开发人员可以在程序中访问和调用它的静态类成员信息（比如:静态字段、静态方法)，或者使用new关键字为其创建对象实例。

过程五：类的写在Unloading（卸载）

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

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

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

类的生命周期

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

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

判断是否是垃圾的算法（GC算法），有两种：引用计数算法（会造成循环引用，不能清除）和可达性分析算法（HotSpot VM采用）

回顾：方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。
HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。

判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：

• 该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例。
• 加载该类的类加载器已经被回收。这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、3SP的重加载等，否则通常是很难达成的。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。（显而易见，因为是堆空间或者方法区到了阈值或者满了才会触发GC）

类的卸载

(1）启动类加载器加载的类型在整个运行期间是不可能被卸载的(jvm和jls规范)

(2）被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小。

（3）被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中(比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能)，被加载的类型在运行期间也是几乎不太可能被卸载的(至少卸载的时间是不确定的)。

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