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

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

一、过程一：Loading（加载）阶段

1、做了哪些事？

在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。

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

加载完成的操作

加载阶段，简言之，查找并加载类的二进制数据，生成Class的实例。在加载类时，Java虚拟机必须完成以下3件事情:

• 通过类的全名，获取类的二进制数据流。
• 解析类的二进制数据流为方法区内的数据结构（Java类模型）
• 创建java.lang.Class类的实例，表示该类型。作为方法区这个类的各种数据的访问入口

2、什么是类模板对象？

类模板对象，其实就是Java类在JVM内存中的一个快照，JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样JVM在运行期便能通过类模板而获取Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用。

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

类模板的位置

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

3、二进制流的获取方式有哪些？

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

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

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

如果输入数据不是ClassFile的结构，则会抛出ClassFormatError。（比如如果不是cafebabe开头，就会抛出ClassFormatError）

4、Class实例的位置在哪？

类将.class文件加载至元空间后，会在堆中创建一个Java.lang.Class对象，用来封装类位于方法区内的数据结构，该Class对象是在加载类的过程中创建的，每个类都对应有一个Class类型的对象。（instanceKlass → mirror : Class的实例）

外部可以通过访问代表Order类的Class对象来获取Order的类数据结构

5、数组类的加载

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

1、 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型；
2、 JVM使用指定的元素类型和数组维度来创建新的数组类；
3、 如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定否则数组类的可访问性将被缺省定义为public；

二、过程二：Linking（链接）阶段

1、验证Verification

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

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

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

2、准备Preparation

简言之，为类变量分配内存，并将其初始化为默认值。Java虚拟机为各类型变量默认的初始值如表所示：

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

• 这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显式赋值。
• 注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。
• 在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。

3、解析Resolution

简言之，将类、接口、字段和方法的符号引用转为直接引用。

1、 符号引用：符号引用以一组符号来描述所引用的目标符号引用可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可，符号引用和虚拟机的布局无关个人理解为：在编译的时候一个每个java类都会被编译成一个class文件，但在编译的时候虚拟机并不知道所引用类的地址，多以就用符号引用来代替，而在这个解析阶段就是为了把这个符号引用转化成为真正的地址的阶段；
2、 直接引用：直接引用和虚拟机的布局是相关的，不同的虚拟机对于相同的符号引用所翻译出来的直接引用一般是不同的如果有了直接引用，那么直接引用的目标一定被加载到了内存中；

直接引用可以是：
直接指向目标的指针。（个人理解为：指向对象，类变量和类方法的指针）
相对偏移量。（指向实例的变量，方法的指针）
一个间接定位到对象的句柄。

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

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

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

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

1、子类加载前先加载父类？

在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的总是在子类之前被调用。也就是说，父类的static块优先级高于子类。

2、哪些类不会生成<clinit>方法？

1、 一个类中并没有声明任何的类变量，也没有静态代码块时；
2、 一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时；
3、 一个类中包含staticfinal修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式；

    public class test {
        //场景1:对于非静态的字段，不管是否进行了显式赋值，都不会生成<clinit>()方法
        public int num = 1;
        //场景2:静态的字段，没有显式的赋值，不会生成<cLinit>()方法
        public static int num1;
        //场景3:比如对于声明为static final的基本数据类型的字段，不管是否进行了显式赋值，都不会生成<clinit>()方法
        public static final int num2 = 1;
    }

3、static与final的搭配问题

使用static + final修饰的成员变量，称为：全局常量。

什么时候在链接阶段的准备环节：给此全局常量附的值是字面量或常量，不涉及到方法或构造器的调用。

除此之外，都是在初始化环节赋值的。

    public class test {     
        public static int a = 1;    //初始化阶段赋值

        public static final int INT_CONSTANT = 10;  //链接阶段的准备环节赋值

        public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100);   //初始化阶段赋值

        public static Integer INTEGER_CONSTANT2 = Integer.valueOf(1000);    //初始化阶段赋值

        public static final String s0 = "helloworld0";  //链接阶段的准备环节赋值

        public static final String s1 = new String("helloworld1");  //初始化阶段赋值

        public static String s2 = "helloworld2";    //链接阶段的准备环节赋值

        public static final int NUM = 2;    //链接阶段的准备环节赋值

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

4、<clinit>会发生死锁吗

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

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

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

死锁demo：

• loadA线程加载了staticA，staticA加载了staticB
• loadB线程加载了staticB，staticB加载了staticA
• staticA和staticB都有1s的阻塞，所以当staticA想要加载staticB的时候，staticB已经被loadB线程先加载
• 所以loadA线程需要等待staticB，而loadB线程也要等待staticA
• 由此出现了类的交叉加载行为，继而出现了类的死锁行为
• 程序呈现出僵持状态，输出语句不会打印，相当于程序进入阻塞状态，出现了事实上的死锁

class StaticA {
    static {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
        }
        try {
            Class.forName("StaticB");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        System.out.println("StaticA init OK");
    }
}

class StaticB {
    static {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
        }
        try {
            Class.forName("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("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();
    }
}

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

（1）主动使用

主动使用 = 哪些情况会发出类的加载、类加载时机

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方法句柄对应的类）；

注意：只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。

（2）被动使用

除了以上的情况属于主动使用，其他的情况均属于被动使用。被动使用不会引起类的初始化。

也就是说：并不是在代码中出现的类，就一定会被加载或者初始化。如果不符合主动使用的条件，类就不会初始化。

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

• 当通过子类引用父类的静态变量，不会导致子类初始化
  2、 通过数组定义类引用，不会触发此类的初始化；
  3、 引用常量不会触发此类或接口的初始化因为常量在链接阶段就已经被显式赋值了；
  4、 调用ClassLoader类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化；

四、过程四：类的Using使用

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

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

例：加载一个类时，以Order类为例：

• 方法区存放Order类模板数据/对象
• 堆空间中创建一个Order类的Class实例，这个实例指向了方法区中的类模板对象
• 栈中（栈帧的局部变量表中）中声明了一个class对象，class对象指向了堆空间中的Class实例
• Order的对象实例存放在堆中

五、过程五：类的Unloading（卸载）

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

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

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

2、类什么情况会被卸载？

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

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

3、类卸载在实际生产中的情况如何？

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

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

4、方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。

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

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

Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。