Java中类的加载过程（类的生命周期）详解_java类在什么时候加载

1、概述

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

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

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

从程序中类的使用过程看

下面我们针对每个阶段详细介绍。

2、Loading（加载）阶段

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

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

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

• 通过类的全名，获取类的二进制数据流。

• 解析类的二进制数据流为方法区内的数据结构（Java类模型）

• 创建java.lang.Class类的实例，表示该类型。作为方法区这个类的各种数据的访问入口

2.1、二进制流的获取方式

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

• 虚拟机可能通过文件系统读入一个class后缀的文件（最常见）

• 读入jar、zip等归档数据包，提取类文件。

• 事先存放在数据库中的类的二进制数据

• 使用类似于HTTP之类的协议通过网络进行加载

• 在运行时生成一段class的二进制信息等

2.2、类模型与Class实例在内存中的存储位置

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

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

2.3、数组类的加载

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

• 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型；

• JVM使用指定的元素类型和数组维度来创建新的数组类。

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

2、Linking（链接）阶段

2.1、Verification（验证）

当类加载到系统后，就开始链接操作，验证是链接操作的第一步。

它的目的是保证加载的字节码是合法、合理并符合规范的。

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

整体说明：

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

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

• 格式验证之外的验证操作将会在方法区中进行

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

具体说明：

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

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

• 是否所有的类都有父类的存在（在Java里，除了object外，其他类都应该有父类）

• 是否一些被定义为final的方法或者类被重写或继承了

• 非抽象类是否实现了所有抽象方法或者接口方法

③、字节码验证：Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程

它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：

• 在字节码的执行过程中，是否会跳转到一条不存在的指令

• 函数的调用是否传递了正确类型的参数

• 变量的赋值是不是给了正确的数据类型等

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

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

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

2.2、Preparation（准备）

准备阶段（Preparation），简言之，为类的静态变分配内存，并为其赋默认初始化值。

当一个类验证通过时，虚拟机就会进入准备阶段。在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值。Java虚拟机为各类型变量默认的初始值如表所示。

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

注意：

针对基本数据类型

非final修饰的变量，在准备环节进行默认化赋值。

final修改的常量，在编译为class文件后已经赋了默认值，在准备阶段是进行显示赋值

final static 修饰并且通过字面量方式声明的字符串，也是在准备环节进行显示赋值

    /**
     * 准备阶段赋初始值
     */
    public static long num1;
 
    /**
     * 编译阶段赋初始值，准备阶段显示赋值
     */
    public static final int num2 = 2;
 
    /**
     * 准备阶段显示赋值
     */
    public static final String str1 = "str";

• 注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。

• 在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。

2.3、Resolution（解析）

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

具体描述：

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

3、Initialization（初始化）阶段

类的初始化是类装载的最后一个阶段，如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。（即：到了类的初始化阶段，才正在开始执行类中定义的Java程序代码）。

初始化阶段的重要工作是执行类的初始化方法：<client>()方法

• 该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是有字节码指定所组成。

• 它是类静态程序的赋值语句以及static语句块合并产生的。

通过jclasslib即可看出

说明：

在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的clinit方法总是在子类clinit方法之前调用，这也就是我们知道的，父类的static代码块块优先级高于子类。

3.1、static与final的搭配问题

说明：使用static+ final修饰的字段的显式赋值的操作，到底是在哪个阶段进行的赋值？

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

• 情况2：在初始化阶段<clinit>()中赋值

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

• 对于基本数据类型的字段来说，如果使用static final修饰，则显式赋值(直接赋值常量，而非调用方法通常是在链接阶段的准备环节进行

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

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

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

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>()中赋值

3.2、<clinit>()的线程安全性

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

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

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

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

4、类的Using（使用）

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

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

5、类的Unloading（卸载）

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

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

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

5.2、类的生命周期

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

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

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

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

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

5.3、类的卸载

（1）启动类加载器加载的类型在整个运行期间是不可能被卸载的

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

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

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