1. 概述

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

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

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

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

2. 加载阶段（Loading）

2.1 加载完成的操作

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

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

加载完成的操作加载阶段，简言之，查找并加载类的二进制数据，生成Class的实例。在加载类时，JVM必须完成以下三件事：

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

2.2 二进制流的获取方式

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

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

在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为一个java.lang.Class的实例；如果输入数据不是ClassFile的结构，则会抛出ClassFormatError

2.3 类模型与Class实例的位置

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

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

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

再说明

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

2.4 数组类的加载

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

如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型
JVM使用指定的元素类型和数组维度来创建数组类

如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定；否则数组类的可访问性奖杯默认定义为public

3. 链接阶段（Linking）

3.1 链接阶段之验证（Verification）

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

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

格式检查
- 魔数检查
- 版本检查
- 长度检查
语义检查
- 是否继承final
- 是否有父类
- 抽象方法是否有实现
字节码验证
- 跳转指令是否指向正确位置
- 操作数类型是否合理
符号引用验证
- 符号引用的直接引用是否存在

整体说明验证的内容涵盖了类数据信息的格式验证、语义检查、字节码验证以及符号引用验证等，其中格式验证会和加载阶段一起验证。验证通过后，类加载器才会成功将类的二进制数据信息加载到方法区中 ；格式验证之外的验证操作将会在方法区中进行

链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行各种检查

具体说明

格式验证：是否以魔数0xCAFEBABE开头，主版本和副版本号是否在当前Java虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等
Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会予以验证通过，比如：
- 是否所有的类都有父类的存在（在Java里，除了Object类之外，其他的类都应该有父类）
- 是否一些被定义为final的方法或者类被重写或继承了
- 非抽象类是否实现了所有抽象方法或者接口方法
- 是否存在不兼容的方法（比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度；abstract的方法，就不能是final的了）
Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行，比如：
- 在字节码的执行过程中，是否会跳转到一条不存在的指令
- 函数的调用是否传递了正确类型的参数
- 变量的赋值是不是给了正确的数据类型等栈映射帧（StackMapTable）就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，百分百准确地判断一段字节码是否可以被安全执行是无法实现的，因此该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的
校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个方法无法被找到，则会抛出NoSuchMethodError。此阶段在解析环节才会执行

3.2 链接阶段之准备（Preparation）

准备阶段，简言之，是为类的静态变量分配内存，并将其初始化为默认值

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

类型	默认初始值
byte	(byte)0
short	(short)0
int	0
long	0L
float	0.0f
double	0.0
char	\u0000
boolean	false
reference	null

注意

Java并不支持boolean类型，对于boolean类型内部实现是int，由于int的默认值是0，所以boolean的默认值就是false
这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译期间就会分配，准备阶段会显式赋值
这里不会为实例变量分配初始值，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中
这个阶段不会像初始化阶段中那样会有初始化或者代码被执行

代码测试

public class LinkingTest {
    private static long id;
    private static final int num = 2;
}

编译后看到如下信息：

其中对应的常量值索引cp_info #9如下：

对于以下代码：

public class LinkingTest2 {
    public static final String s1 = "test";
    public static final String s2 = new String("test2");
}

可以看到s1和s2解析方式有所不同，s2实际是在初始化阶段进行显式赋值。查看<clinit>字节码指令如下：

 0 new #2 <java/lang/String>
 3 dup
 4 ldc #3 <test2>
 6 invokespecial #4 <java/lang/String.<init>>
 9 putstatic #5 <com/nasuf/jdk8/LinkingTest2.s2>
12 return

也就是说：

如果使用字面量的方式定义常量，是在准备环节直接进行显式赋值
非final修饰的变量，在准备环节进行默认初始化赋值
final修饰的变量，在准备环节直接进行显式初始化

3.3 链接阶段之解析（Resolution）

解析阶段，将类、接口、字段和方法的符号引用转为直接引用

具体描述符号引用就是一些字面量的引用，和虚拟机内部数据结构和内存布局无关。比较容易理解的就是在Class类文件中，通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的。以方法为例，Java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中，当需要一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作，符号引用就可以转变为目标方法在类中方法表中的位置，从而使得方法被成功调用小结所谓解析，就是将符号引用转为直接引用，也就是得到类、字段、方法在内存中的指针或者偏移量。因此可以说，如果直接引用存在，那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用，不能确定系统中一定存在该结构

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

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

4. 初始化阶段（Initialization）

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

4.1 关于 static 和 final

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

初始化阶段的重要工作是执行类的初始化方法：\<clinit>方法

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

代码演示

public class InitializationTest {
    public static int id = 1;
    public static int number;
    static {
        number = 2;
        System.out.println("initialization");
    }
}

对应\<clinit>字节码指令如下：

 0 iconst_1
 1 putstatic #2 <com/nasuf/jdk8/InitializationTest.id>
 4 iconst_2
 5 putstatic #3 <com/nasuf/jdk8/InitializationTest.number>
 8 getstatic #4 <java/lang/System.out>
11 ldc #5 <initialization>
13 invokevirtual #6 <java/io/PrintStream.println>
16 return

说明

在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的\<clinit>总是在子类\<clinit>之前被调用，也就是说，父类的static块优先级高于子类
Java编译器并不会为所有的类都产生\<clinit>初始化方法，包含以下几种情况：
- Case 1: 一个类中并没有声明任何的类变量，也没有静态代码块
- Case 2: 一个类中声明了类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作
- Case 3: 一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式
```
public class InitializationTest {
    public int num = 1;
    public static int num1;
    public static final int num2 = 1;
}
```

static final 描述符的进一步说明查看如下代码：

public class InitializationTest2 {
    public static final int INT_CONSTANT = 10; // 在链接阶段的准备环节赋值
    public static final int INT_CONSTANT2 = new Random().nextInt(10); // 在初始化阶段<clinit>中赋值
}

可以看到\<clinit>方法并不存在，如下：

同时会有字段中的ConstantValue存在，赋值为10，表明是在链接阶段的准备环节中赋值

修改代码如下：

public class InitializationTest2 {
    public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100); // 在初始化阶段<clinit>中赋值
    public static Integer INTEGER_CONSTANT2 = Integer.valueOf(1000); //  在初始化阶段<clinit>中赋值
}

再次修改代码如下：

public class InitializationTest2 {
    public static final String s0 = "helloworld#0"; // 在链接阶段的准备环节赋值
    public static final String s1 = new String("helloworld#1");  // 在初始化阶段<clinit>中赋值
}

总结如下：

在链接阶段准备环节赋值的情况：
- 对于基本数据类型的字段来说，如果使用static final修饰，则显式赋值（直接赋值常量的方式，而非调用方法）是在链接阶段准备环节进行
- 对于String来说，如果使用字面量方式赋值，使用static final修饰，则显式赋值是在链接阶段准备环节进行
排除上述在链接阶段准备环节赋值的情况，其他情况都是在初始化阶段\<clinit>进行显式赋值

最终结论使用static final修饰，且显式赋值中不涉及到方法或构造器调用的基本数据类型或String类型，是在链接阶段的准备环节进行；其他情况下都是在初始化阶段\<clinit>进行显式赋值

4.2 <clinit>()的线程安全性

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

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

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

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

死锁代码

class staticA {
    static {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        try {
            Class.forName("com.nasuf.jdk8.staticB");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        System.out.println("StaticA init done.");
    }
}

class staticB {
    static {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        try {
            Class.forName("com.nasuf.jdk8.staticA");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        System.out.println("StaticB init done.");
    }
}

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.nasuf.jdk8.static" + flag);
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        System.out.println(getName() + " over");
    }

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

实际代码运行时，会发生死锁

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

Java程序对类的使用分为两种：主动使用和被动使用；对类的主动使用会执行类的初始化阶段，而对类的被动使用不会执行类的初始化阶段

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

当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化
当调用类的静态方法时，即当使用了字节码invokestatic指令
当使用类、接口的静态字段时（final修饰特殊考虑，见上文分析），比如使用getstatic或者putstatic指令（对应访问变量、赋值变量操作）
当使用java.lang.reflect包中的方法反射类的方法时，比如Class.forName('xxx.xxx')
当初始化子类时，如果发现其父类还没有进行初始化，则需要先触发其父类的初始化，但该规则并不适用于接口 （设置参数-XX:+TraceClassLoading可以追踪类的加载信息并打印出来）
- 在初始化一个类时，并不会先初始化它所实现的接口
- 在初始化一个接口时，并不会先初始化它的父接口 （一个父接口并不会因为它的子接口或者实现类的初始化而初始化，只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化）
如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类初始化，该接口要在其之前被初始化
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类
- JVM启动的时候通过引导类加载器加载一个初始类。这个类在调用public static void main(String[] args)方法之前被链接和初始化，这个方法的执行将依次导致所需的类的加载、链接和初始化
当初次使用MethodHandle实例时，初始化该MethodHandle指向的方法所在的类（设计解析REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类）

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

当访问一个静态字段时，只有真正声明这个字段的类才会被初始化
- 当通过子类引用父类的静态变量，不会导致子类初始化
通过数组定义类引用，不会触发此类的初始化（比如：Order[] orders = new Order[10];，不会导致Order类初始化，但是该类会被加载）
引用常量不会触发此类或者接口的初始化。因为常量在链接阶段的准备阶段就已经被显式赋值了
调用ClassLoader类的loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化；注意上文提到的主动使用的情况：当使用java.lang.reflect包中的方法反射类的方法时，比如Class.forName('xxx.xxx')，会导致类的初始化

要注意：没有初始化不意味着该类没有被加载

5. 类的使用

任何一个类型在使用之前都必须经历过完整的加载、链接、初始化这三个类加载步骤。一旦一个类型成功经历过这三个步骤之后，就可以被使用了。开发人员可以在程序中访问和调用它的静态类成员信息（比如静态字段、静态方法），或者使用new关键字为其创建对象实例

6. 类的卸载

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

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

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

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

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

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

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

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

类的卸载

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

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

JVM系列（十七）类的生命周期