链接（验证 ，准备，解析）及初始化

链接（Linking）验证（Verification）

当类加载到系统后，就开始链接操作，验证是链接操作的第一步
它的目的是保证加载的字节码是合法、合理并符合规范的
验证的步骤比较复杂，实际要验证的项目也很繁多，大体上 Java 虚拟机需要做以下检查，如图所示

整体的介绍

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

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

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

具体说明

1. 格式验证：是否以魔数 0xCAFEBABE 开头，主版本和副版本号是否在当前 Java 虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等
2. Java 虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给予验证通过。比如：
3. 是否所有的类都有父类的存在(在 Java 里，除了 Object 外，其他类都应该有父类)
4. 是否一些被定义为 final 的方法或者类被重写或继承了
5. 非抽象类是否实现了所有抽象方法或者接口方法
6. 是否存在不兼容的方法(比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度；absract 情况下的方法，就不能是final 的了)
7. ava 虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：
8. 在字节码的执行过程中，是否会跳转到一条不存在的指令
9. 函数的调用是否传递了正确类型的参数
10. 变量的赋值是不是给了正确的数据类型等

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

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

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

此阶段在解析环节才会执行

环节2（准备）Preparation

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

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

Java 虚拟机为各类型变量默认的初始值如表所示：

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

/**
 * <p>
 * 基本数据类型：非 final 修饰的变量，在准备环节进行默认初始化赋值
 * final 修饰以后，在准备环节直接进行显式赋值
 * <p>
 * 拓展：如果使用字面量的方式定义一个字符串的常量的话，也是在准备环节直接进行显式赋值
 */
public class LinkingTest {
    private static long id;
    private static final int num = 1;

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

Resolution（解析）

在准备阶段(Resolution)，简言之，将类、接口、字段和方法的符号引用转为直接引用

具体描述：

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

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

invokevirtual #24

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

小杰

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

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

字符串的复习

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

Initialization(初始化)阶段

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

具体描述

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

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

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

注

1. 在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的 总是在子类 之前被调用，也就是说，父类的 static 块优先级高于子类
2. Java 编译器并不会为所有的类都产生 () 初始化方法。

哪些不会出现clinit方法

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

static 与 final 的搭配问题

/**
 *
 * 哪些场景下，Java 编译器就不会生成<clinit>()方法
 */
public class InitializationTest1 {
  //场景1:对应非静态的字段，不管是否进行了显式赋值，都不会生成<clinit>()方法
  public int num = 1;
  //场景2：静态的字段，没有显式的赋值，不会生成<clinit>()方法
  public static int num1;
  //场景3：比如对于声明为 static final 的基本数据类型的字段，不管是否进行了显式赋值，都不会生成<clinit>()方法
  public static final int num2 = 1;
}
/**
 *
 * 说明：使用 static + final 修饰的字段的显式赋值的操作，到底是在哪个阶段进行的赋值？
 * 情况1：在链接阶段的准备环节赋值
 * 情况2：在初始化阶段<clinit>()中赋值
 *
 * 结论：
 * 在链接阶段的准备环节赋值的情况：
 * 1. 对于基本数据类型的字段来说，如果使用 static final 修饰，则显式赋值(直接赋值常量，而非调用方法)通常是在链接阶段的准备环节进行
 * 2. 对于 String 来说，如果使用字面量的方式赋值，使用 static final 修饰的话，则显式赋值通常是在链接阶段的准备环节进行
 *
 * 在初始化阶段<clinit>()中赋值的情况
 * 排除上述的在准备环节赋值的情况之外的情况
 *
 * 最终结论：使用 static + final 修饰，且显示赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值，是在链接阶段的准备环节进行
 */
public class InitializationTest2 {
    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>()中赋值

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

}

clinit() 的线程安全性

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

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

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

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

借鉴于https://zhuanlan.zhihu.com/p/268637051