目录
背景
阅读此文之前，可以先看看我之前笔记中关于类加载器子系统的章节，这篇笔记将详细描述类的各个加载过程，特别是类的初始化、主动加载和被动加载。
概述
java中的数据类型分为基本数据类型和引用数据类型，其中基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。
按照JVM规范，从class文件到加载到内存中的类，到类卸载出内存为止，类的整个生命周期包括如下三个阶段：
加载(Loading)阶段
所谓加载，就是把java类的字节码文件加载到内存中，并在内存中构建出java类的原型——类模板对象。所谓类模板对象，就是java类在JVM内存中的一个快照，存储从字节码文件中解析出来的常量池、类字段、类方法等等信息，如此JVM就可以在运行期通过类模板获取java类中的任意信息，比如对java类的成员变量进行遍历、方法的调用、反射等。
加载完成的操作
简而言之，就是查找并加载类的二进制数据，生成class实例。
在加载类时，JVM必须完成以下三件事情：
- 通过类的全名，获取类的二进制数据流；
- 解析类的二进制数据流为方法区的数据结构(模板类)
- 创建class类实例以表示此类，作为方法区这个类的各种数据访问入口
二进制流的获取方式
对于类的二进制数据流，JVM可以通过多种途径产生或获得：（只要所读取的字节码符合JVM规范即可）
- 从文件系统读入一个class后缀的文件；
- 读入jar、zip等压缩包，提取类文件；
- 事先存放在数据库中的类二进制数据；
- 使用网络协议通过网络传输进行加载；
- 在运行时生成一段class的二进制信息等
在获取到类的二进制信息后，JVM会处理这些数据，并最终转换为一个class实例。如果输入数据不是ClassFile的结构，会抛出ClassFormatError
类模型与class实例的位置
被加载的类在JVM中被创建为相应的类结构，存储在方法区。
类将class文件加载到方法区后，会在堆中创建一个Class对象，用来封装类位于方法区的数据结构，这个Class对象是在加载类的过程中创建的，每个类都对应一个Class对象
Class类的构造方法是私有的，这个类只能由JVM创建对象。Class实例是访问类型元数据的接口，也是实现反射的关键数据和入口。通过Class类提供的接口，可以获得目标类所关联的class文件中具体的数据结构，比如方法、字段等
数组类的加载
创建数组类的情况略有特殊，因为数组类本身不使用类加载器负责创建，而是由JVM在运行时根据需要而直接创建，但数组的元素类型仍然需要依靠类加载器区创建，过程如下：
- 如果数组元素类型为引用类型，那么就遵循定义的加载过程递归加载创建数组的元素类型；否则直接执行下一步
- JVM再使用指定的元素类型和数组维度来创建数组类对象
如果数组元素的数据类型为引用类型，数组类的可访问性就由元素类型的可访问性决定，否则就默认是public
链接阶段
验证
当类加载到内存中后，就开始进行链接操作，而链接的第一步就是验证。验证的目的是保证加载字节码是合法合理并符合规范的。验证的步骤比较复杂，大体上如下图所示
整体说明：
- 验证的内容焊膏了类数据信息的格式验证、语义检查、字节码验证、符号引用验证等。其中格式检查会和加载阶段一起执行。验证通过后，类加载器才会成功将类的二进制数据加载到方法区中。除了格式验证之外的验证操作会在方法区中进行。
- 链接阶段的验证虽然拖慢了加载速度，但是避免了字节码运行时还要进行各种检查
具体说明：
- 格式验证：是否以魔数0xCAFEBABE开头、主版本号和副版本号是否在当前JVM的支持范围内、数据中的每一项是否有正确的长度等
- 语义检查：是否所有的类都有父类存在(Object类除外)、是否一些被定义为final的方法或者类被覆写或继承了；非抽象类是否实现了所有的抽象方法或接口方法；是否存在不兼容的方法（比如方法的签名除了返回值不同，其他都一样；abstract和final共存等）
- 字节码验证：这是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析来判断字节码是否可以被正确执行，比如在字节码执行过程中是否会跳转到一条不存在的指令、函数的调用是否传递了正确类型的参数、变量的赋值是否给了正确的数据类型等。栈映射帧就发生在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。只可惜，百分百准确判断一段字节码文件是否可以被安全执行是无法实现的，因此此过程只能尽可能检查出可预知的明显问题。如果在此阶段无法通过检查，JVM不会正确装载这个类，但即便通过了此阶段检查，也不能说明这个类是完全没有问题的。
- 引用符号验证：在前面三次检查中，已经排除了文件格式、语义和字节码方面的错误，但依旧不能保证类是没有问题的。因为class文件在其常量池里会通过字符串记录自己将要使用的其他类或者方法，因此在JVM会在引用符号验证时检查这些类或者方法是确实存在，并且当前类有权限访问这些数据。如果一个需要使用的类或者方法无法在系统中被找到，那么就会抛出NoClassDefFountError或NoSuchMethodError。这一阶段的检查在解析阶段才会执行
准备
这个阶段负责对类的静态变量分配内存，并将其初始化为默认值。
当一个类验证通过时，JVM对它的链接会进入准备阶段。在此阶段，JVM会为这个类分配相应的内存空间，并设置默认初始值。JVM为各类型变量设置的默认初始值如下表所示
| 类型 |
默认初始值 |
| byte |
(byte) 0 |
| short |
(short) 0 |
| int |
0 |
| long |
0L |
| float |
0.0f |
| double |
0.0 |
| char |
\u0000 |
| boolean |
false |
| reference |
null |
注意：
- JVM底层不支持boolean类型，对于boolean类型，内部实现为int，由于int的默认值为0，故对应的boolean的默认值就为false；
- 这里不包含基本数据类型字段使用static final修饰的情况，因为final字段的值在编译时就作为字面量被分配在常量池中了，准备阶段会被显式赋值给final字段；
- 这里不会为实例变量进行初始化，类变量会分配在方法区中，而实例变量会随着对象一起分配到java堆中；
- 这个阶段不会像初始化阶段那样有初始化或者有代码被执行
对于静态字段的赋值：
- 基本数据类型或者字面量定义的字符串常量：非final会在准备阶段进行默认初始化赋值，final字段会在准备阶段直接显式赋值
- 对于引用数据类型或者非字面量定义的字符串常量(new String)，就会推迟到初始化阶段再进行赋值
解析
解析阶段负责把类、接口、字段和方法的符号引用转换成直接引用。
符号引用就是一些字面量的引用，和虚拟机内部数据结构和内存布局无关。但是程序运行时，系统只要符号引用的方法等在内存中的位置。
以方法为例，JVM为每一个类都准备了一张方法表，将其所有的方法都列在表中，当需要调用一个类的方法的时候，只需要知道这个方法在方法表中的偏移量就可以对其进行调用。通过解析操作，符号引用就可以变为目标方法在类方法表中的位置，从而使得方法被成功调用。
因此，所谓解析就是把符号引用转为直接引用，也就是得到类、字段、方法在内存中的指针或者偏移量。可以说，如果直接引用存在，系统中就肯定存在此类、方法或者字段，但是符号引用的存在就不能确定系统中一定存在该结构。
不过JVM也没有明确要求解析阶段一定要按照顺序执行。在HotSpot虚拟机中，加载、验证、准备和初始化会按照顺序有条不紊地进行，但链接阶段中的解析操作往往会在JVM在执行完初始化之后再去执行
初始化阶段
初始化阶段负责为类的静态变量赋予正确的初始值。这一阶段是类装载的最后一个阶段，如果前面的步骤都没有问题，表示类可以顺利地被装载到内存中。此时，类才会开始执行字节码。
初始化阶段的重要工作就是执行类的初始化方法(<clinit>())，此方法仅能由java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更不能在java程序中直接调用此方法，即便此方法也是由字节码指令组成。此方法由类静态成员的赋值语句和static代码块合并产生，例如下面这个类
public class LinkTest {
public static int a = 1;
public static int b;
static {
b = 4;
}
}首先它有一个<clinit>方法
再者其<clinit>字节码指令如下
0 iconst_1
1 putstatic #2 <LinkTest.a>
4 iconst_4
5 putstatic #3 <LinkTest.b>
8 return在加载一个类之前，JVM总是会试图加载该类的父类，因此父类的<clinit>总是在子类<clinit>之前被调用，也就是说父类的static块的优先级高于子类
public class SonTest extends FatherL {
static {
System.out.println("Son static");
}
public static void main(String[] args) {
System.out.println(SonL.x); // 1
}
}
class FatherL {
public static int x;
static {
x = 1;
System.out.println("Father static");
}
}但如果只是调用子类中父类的静态字段，而不执行调用子类中的方法或字段、实例化子类对象等操作，那么子类压根儿不会被装载到JVM中，它的初始化阶段也不会执行
public class LinkTest {
public static void main(String[] args) {
System.out.println(SonL.x); // 1
}
}
class FatherL {
public static int x;
static {
x = 1;
System.out.println("Father static");
}
}
class SonL extends FatherL {
static {
x = 4;
System.out.println("Son static");
}
}java编译器不会为所有的类都产生<clinit>()初始化方法，这些类包括：
- 没有声明任何类变量，也没有静态代码块的类；
- 声明了类变量，但没有明确使用类变量的初始化语句以及静态代码块来进行初始化的类；
- 包含static final修饰的基本数据类型字段的类，这种字段的初始化语句会采用编译时的常量表达式
static和final的搭配问题
情况1：在链接阶段的准备环节赋值
情况2：在初始化阶段赋值
示例代码如下：
public class CliInitTest {
public static int a; // 情况2
public static final int b = 1; // 情况1
public static Integer i0 = Integer.valueOf(10); // 情况2
public static final Integer i1 = Integer.valueOf(100); // 情况2
public static final String s = "szc"; // 情况1
public static final String s1 = new String("sss"); // 情况2
}对于static字段的初始化问题，总结一下：
- 非final：初始化阶段
- final且非字面量初始化：初始化阶段
- final且为字面量初始化：链接时的准备环节
2）、<clinit>()的线程安全性
对于<clinit>方法的调用，JVM会在内部确保其线程安全性。也就是说虚拟机会保证一个类的<clinit>方法在多线程场景下被正确加锁同步，如果多个线程同时去初始化一个类，那么只有一个线程会去执行此类的<clinit>方法，别的线程就得阻塞等待，直到活动线程执行<clinit>完成。
正是因为<clinit>是带锁线程安全的，因此如果在一个类的<clinit>方法中执行耗时很长的操作，就可能造成多个线程阻塞引发死锁，并且这种死锁是很难发现的，因为看起来没有什么可用的信息。例如以下代码
public class StaticDeadlockTest extends Thread {
private int flag;
public static void main(String[] args) {
StaticDeadlockTest test1 = new StaticDeadlockTest();
StaticDeadlockTest test2 = new StaticDeadlockTest();
test1.flag = 1;
test2.flag = 2;
test1.start();
test2.start();
}
@Override
public void run() {
try {
Class.forName("Test" + flag);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
class Test1 {
static {
try {
Thread.sleep(1000);
Class.forName("Test2");
} catch (Exception e) {}
}
}
class Test2 {
static {
try {
Thread.sleep(1000);
Class.forName("Test1");
} catch (Exception e) { }
}
}两个线程分别加载Test1和Test2，但是Test1要加载Test2，Test2又要加载Test1，因此形成了环形等待，形成死锁
如果之前的线程成功加载了类，则等待队列中的线程就没有机会再执行<clinit>方法。那么当需要使用这个类时，JVM会直接返回给它已经准备好的信息
类的初始化情况：主动使用与被动使用
java对类的使用分为主动使用和被动使用两种。
主动使用：Class只有在必须要首次使用的时候才会被装载，JVM不会无条件装载Class类型。JVM规定，一个类或者接口在初次使用前，必须要进行初始化。这里的使用就是主动使用。主动使用只有以下几种情况（出现下面几种情况，就会对类进行初始化，而初始化之前的加载、验证、准备、解析等过程都正确执行完成）：
- 创建类的实例（new、反射、克隆、反序列化等）；
- 调用类的静态方法（使用了字节码指令invokestatic）；
- 使用类、接口的静态字段（使用getstatic、putstatic指令）；
- 使用java.lang.reflect包中的方法反射类的方法是（比如Class.forName()）；
- 初始化子类时，如果发现其父类还没初始化，则要先触发父类的初始化；
- 一个接口定义了default方法，那么如果初始化直接实现或间接该接口的实现类，接口会在此之前被初始化；
- JVM启动时，用户要指定一个主类(main()方法所在类)，JVM会先初始化这个主类；
- 当初次调用MethodHandle实例时，初始化改MethodHandle指向的方法所在类（对应REF_getStatic、REF_putStatic和REF_invokeStatic方法句柄对应的类）
注意，当JVM初始化一个类时，要求它所有的父类都已经被初始化，但不会先初始化它实现的接口
被动使用：除了主动使用的情况就都是被动使用了，被动使用不会引起类的初始化。也就是说，并不是在代码中出现的类就都会被加载或初始化，如果不符合主动使用的条件，就不会进行类的初始化。被动使用的情况有以下几种：
- 访问静态字段时，只有真正声明这个字段的类才会被初始化（当通过子类引用父类的静态变量，就不会导致子类的初始化）；
- 通过数组定义类引用，不会触发类的初始化；
- 引用常量不会触发类或接口的初始化，因为常量在准备阶段就已经被显式赋值了；
- 调用ClassLoader的loadClass()方法加载一个类，也不会导致类的初始化
我们验证一下上面关于类的主动被动使用的场景
主动使用
创建类的实例（new、反射、克隆、反序列化等）
public class ActiveUse {
public static void main(String[] args) {
Test t = new Test(); // new对象，会导致类的初始化，<clinit>被执行
}
}
class Test {
static {
System.out.println("Test has been initialized");
}
}类的反序列化
public class ActiveUse {
public static void main(String[] args) {
// serialization(); // 要先执行序列化
deserialization();
}
private static void serialization() {
try {
Test t = new Test();
ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("test"));
outputStream.writeObject(t);
outputStream.flush();
outputStream.close();
} catch (Exception e) {}
}
private static void deserialization() {
try {
ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream("test"));
Test t = (Test) inputStream.readObject(); // 反序列化也会导致<clinit>的执行
inputStream.close();
} catch (Exception e) {}
}
}
class Test implements Serializable {
static {
System.out.println("Test has been initialized");
}
}调用类的静态方法（使用了字节码指令invokestatic）
public class ActiveUse {
public static void main(String[] args) {
Test.f(); // 调用类的静态方法，会导致<clinit>的执行
}
}
class Test implements Serializable {
static {
System.out.println("Test has been initialized");
}
public static void f() {
System.out.println("f has been invoked");
}
}使用类、接口的静态字段（使用getstatic、putstatic指令），注意final static要另外考虑是否是字面量初始化，是的话就不会
public class ActiveUse {
public static void main(String[] args) {
System.out.println(Test.s); // 使用静态字段，会导致<clinit>的执行
System.out.println(Test.s1); // 准备期初始化，不会执行<clinit>
}
}
class Test implements Serializable {
public static int s = 0;
public static final int s1 = 1;
static {
System.out.println("Test has been initialized");
}
}使用java.lang.reflect包中的方法反射类的方法是（比如Class.forName()）
public class ActiveUse {
public static void main(String[] args) {
try {
Class.forName("Test"); // 对类进行反射，会导致<clinit>的执行
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
class Test implements Serializable {
static {
System.out.println("Test has been initialized");
}
public static void f() {
System.out.println("f has been invoked");
}
}初始化子类时，如果发现其父类还没初始化，则要先触发父类的初始化，但是子接口的初始化不会导致父接口的初始化，而且如果接口中没有默认方法，那么实现类的初始化也不会导致接口的初始化
public class ActiveUse {
public static void main(String[] args) {
TestSon s = new TestSon(); // 会先输出Test，再输出Test Son，但不会输出iA和iFather
}
}
class Test {
static {
System.out.println("Test has been initialized");
}
}
class TestSon extends Test implements iA {
static {
System.out.println("Test Son has been initialized");
}
@Override
public void f0() {}
}
interface iFather {
public static Object o = new Object() {
{
System.out.println("iFather has been initialized");
}
};
}
interface iA extends iFather {
public static Object o = new Object() {
{
System.out.println("iA has been initialized");
}
};
public void f0();
// default public void f0() {} // 如果换成这种写法，TestSon的初始化导致iA的初始化
}对于父类子类、接口与实现类、父接口与子接口是否会被初始化，可以总结一下：要看当前访问的字段或调用的方法，再结合接口初始化的规则，最少要初始化哪些类与接口，就初始化哪些类与接口。看以下例子
public class ActiveUse3 {
public void test4() {
System.out.println(Son2.num); // Son2.num在Son2中被初始化，且非final，因此先后初始化父类和子类
System.out.println(Son2.NUM1); // Son2.NUM1在子接口中被初始化，且非final，因此只初始化子接口
System.out.println(Son2.numf); // Son2.numf在父类中被初始化，且非final，因此只初始化父类
}
public static void main(String[] args) {
new ActiveUse3().test4();
}
}
class Father2 {
static {
System.out.println("Father类的初始化过程");
}
public static int numf = 1;
}
class Son2 extends Father2 implements CompareC {
static {
System.out.println("Son类的初始化过程");
}
public static int num = 1;
@Override
public void method1() {}
}
interface CompareB {
public static final Thread t = new Thread() {
{
System.out.println("CompareB的初始化");
}
};
public void method1();
}
interface CompareC extends CompareB {
public static final Thread t = new Thread() {
{
System.out.println("CompareC的初始化");
}
};
public static final int NUM1 = new Random().nextInt();
}一个接口定义了default方法，那么如果初始化直接实现或间接该接口的实现类，接口会在此之前被初始化：
public class ActiveUse {
public static void main(String[] args) {
TestInterface testInterface = new TestInterface(); // 先输出iA，再输出TestInterface
}
}
interface iA {
public static Object o = new Object() {
{ // 如果iA的<clinit>被执行，这个静态对象必然被实例化，以下代码必被执行
System.out.println("iA has been initialized");
}
};
default void f0() {
System.out.println("f0 in iA");
}
}
class TestInterface implements iA {
static {
System.out.println("TestInterface has been initialized");
}
@Override
public void f0() {
System.out.println("f0 in TestInterface");
}
}JVM启动时，用户要指定一个主类(main()方法所在类)，JVM会先初始化这个主类
public class ActiveUse {
static {
System.out.println("ActiveUse被初始化"); // 主类的启动会导致其<clinit>被执行
}
public static void main(String[] args) {
}
}当初次调用MethodHandle实例时，初始化改MethodHandle指向的方法所在类（对应REF_getStatic、REF_putStatic和REF_invokeStatic方法句柄对应的类），略
被动使用
访问静态字段时，只有真正声明这个字段的类才会被初始化（当通过子类引用父类的静态变量，就不会导致子类的初始化）
public class PassiveUse {
public static void main(String[] args) {
System.out.println(Son3.num); // 通过子类访问父类静态非final字段，只会初始化父类
}
}
class Father3 {
public static int num = 1;
static {
System.out.println("Father has been intialized");
}
}
class Son3 extends Father3 {
static {
System.out.println("Son has been initialized");
}
}通过数组定义类引用，不会触发类的初始化
public class PassiveUse {
public static void main(String[] args) {
Father3[] fathers = new Father3[10]; // 数组不会触发元素类的初始化
}
}
class Father3 {
static {
System.out.println("Father has been intialized");
}
}引用常量不会触发类或接口的初始化，因为常量在准备阶段就已经被显式赋值了
public class PassiveUse {
public static void main(String[] args) {
System.out.println(Father3.s); // 字面量初始化的常量，不会导致类或接口的初始化
}
}
class Father3 {
public static final String s = "szc";
static {
System.out.println("Father has been intialized");
}
}下面也不会触发类或接口的初始化
public class PassiveUse {
public static void main(String[] args) {
System.out.println(Father3.s1); // 字面量常量不会引发类或接口相关的初始化
}
}
interface iF {
public static final String s1 = "s";
public static Object o = new Object() {
{
System.out.println("iF has been initialized");
}
};
}
class Father3 implements iF {
public static final String s = "szc";
static {
System.out.println("Father has been intialized");
}
}调用ClassLoader的loadClass()方法加载一个类，也不会导致类的初始化，略
使用
到了这一步，一个类经历了加载、链接和初始化阶段就可以等着开发者使用了
卸载
类、类加载器和类的实例之间的引用关系
在类加载器的内部实现中，用一个java集合来存放所加载的类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法就可以获得它的类加载器。由此可见，一个类的Class实例与其类加载器之间为双向绑定关系
一个类的实例总是引用代表这个类的Class对象，在Obejct类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的java类都一个静态属性class，它引用这个代表这个类的Class对象
类的生命周期
当某个类(Sample)被加载、链接和初始化后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载，从而其生命周期也随之终结
一个类何时结束生命周期，取决于代表它的Class对象生命周期何时结束
回顾一下方法区中的垃圾回收：
方法区的垃圾回收主要回收两部分内容：常量池中废弃的常量和不再使用的类型。
HotSpot虚拟机对常量池的回收策略很明确，只要常量池中的常量不在任何地方被引用，就可以被回收。
判断一个常量是否废弃还相对简单，而要判断一个类型是否属于不再被使用的类就有比较苛刻的条件，要同时满足三点：
a）、该类的所有实例都已经被回收，也就是堆中不存在该类及其任何派生子类的实例对象
b）、加载该类的类加载器已经被回收。这个条件除非是经过精心设计的可替换类加载器的场景，例如OSGi、JSP的重加载等，否则一般是很难达成的
c）、该类对应的Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法或字段
java虚拟机允许满足对以上三个条件的无用类进行回收，这里说允许，是因为类不是像对象一样，没有引用就会很快被回收
示例图如下所示，只有栈上的classLoader、sampleClasss和sample三个引用变量都被销毁，堆中的ClassLoader、Class和Sample对象才可能被回收，方法区中Sample类数据才可能被卸载
关于类的卸载
启动类加载器加载的类型在整个运行期间是不可能被卸载的（JVM和jls规范）
被系统类加载器和扩展类加载器加载的类在运行期间不太可能被回收，因为系统类加载器实例或者扩展类加载器实例基本在整个运行期总能被直接或间接访问到，其成为unreachable的可能性极小
被开发者自定义的类加载器实例加载的类只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能在可以做到。可以预想，在稍微复杂点儿的应用场景中(比如，很多时候程序员在开发自定义类加载器时采用缓存策略以提高系统性能)，被加载的类在运行期间也几乎不可能被卸载（至少卸载的时间不确定）
综上，一个已经加载的类被卸载的几率很小，至少被卸载的时间不确定。同时，我们在开发代码时，不应该在对虚拟机的类型卸载做任何假设的前提下，再去实现系统中的特定功能。
结语
下篇笔记将回顾类加载器