JVM 类加载机制

在 Java 语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略让 Java 语言进行提前编译会面临额外的困难，也会让类加载时稍微增加一些性能开销，但是却为 Java 应用提供了极高的扩展性和灵活性

类加载的时机

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)七个阶段，其中验证、准备、解析三个部分统称为连接(Linking)

加载、验证、准备、初始化和卸载这五个阶段的前后顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后再开始。这些阶段通常都是互相交叉地混合进行的，会在一个阶段执行的过程中调用、激活另一个阶段

类加载的过程

加载

需要完成三件事：

1. 通过一个类的全限定名来获取定义此类的二进制字节流
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3. 在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口

[scode type=“blue” size=“”]

全限定名 = 包名 + 类型名，例如 java.lang.String

非限定类名例如String

[/scode]

第一点中并没有指定二进制字节流要从哪里获取、如何获取。据此发展出了很多 Java 技术：

• 从 ZIP 压缩包中读取，最终成为日后 JAR、EAR、WAR 格式的基础
• 从网络中获取，这种场景最典型的应用就是 Web Applet（已经淘汰了）
• 运行时计算生成，这种场景使用得最多的就是动态代理技术
• 由其他文件生成，典型场景是 JSP应用
• 从数据库中读取，这种场景相对少见些，例如可以把程序安装到数据库中来完成程序代码在集群间的分发
• 可以从加密文件中获取，这是典型的防 Class 文件被反编译的保护措施

加载阶段与连接阶段的部分动作是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这两个阶段的开始时间仍然保持着固定的先后顺序

非数组类型的加载

加载阶段既可以使用 Java 虚拟机里内置的引导类加载器来完成，也可以由用户自定义的类加载器去完成，通过定义自己的类加载器去控制字节流的获取方式（重写一个类加载器的 findClass()或 loadClass()方法）

数组类型的加载

数组类本身不通过类加载器创建，它是由 Java 虚拟机直接在内存中动态构造出来的，但数组类的元素类型（Element Type，指的是数组去掉所有维度的类型。例如 int[][] 对应的 int）最终还是要靠类加载器来完成加载

如果数组的组件类型（Component Type，指的是数组去掉一个维度的类型，例如 int[][] 数组对应的 int[]）是引用类型，那就递归采用加载过程去加载这个组件类型，数组将被标识在加载该组件类型的类加载器的类名称空间上

如果数组的组件类型不是引用类型（例如 int[] 数组的组件类型为 int），Java 虚拟机将会把数组标记为与引导类加载器关联

数组类的可访问性与它的组件类型的可访问性一致，如果组件类型不是引用类型，它的数组类的可访问性将默认为 public，可被所有的类和接口访问到

加载结束

加载阶段结束后 Java 虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中，会在 Java 堆内存中实例化一个 java.lang.Class 类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口

验证

验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息符合《Java 虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全，原因是 Java 代码编译的时候会检查数组越界等异常，但 Class 文件并不一定只能由 Java 源码编译而来，上述 Java 代码无法做到的事情在字节码层面上都是可以实现的

验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证和符号引用验证

验证阶段对于虚拟机的类加载机制来说，是一个非常重要的、但却不是必须要执行的阶段，因为验证阶段只有通过或者不通过的差别，只要通过了验证，其后就对程序运行期没有任何影响了。被反复使用和验证过的代码可以关闭大部分的类验证措施，以缩短虚拟机类加载的时间

文件格式验证

第一阶段要验证字节流是否符合 Class 文件格式的规范，并且能被当前版本的虚拟机处理

这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证之后，这段字节流才被允许进入 Java 虚拟机内存的方法区中进行存储，所以后面的三个验证阶段全部是基于方法区的存储结构上进行的，不会再直接读取、操作字节流

元数据验证

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java 语言规范》的要求，这个阶段可能包括的验证点如下：

• 这个类是否有父类（除了 java.lang.Object 之外，所有的类都应当有父类）
• 这个类的父类是否继承了不允许被继承的类（被 final 修饰的类）
• 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法
• ……

字节码验证

整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的，对类的方法体（Class 文件中的 Code 属性）进行校验分析，保证被校验类的方法在运行时不 会做出危害虚拟机安全的行为

一个方法体通过了字节码验证，也仍然不能保证它一定就是安全的

由于数据流分析和控制流分析的高度复杂性，为了避免过多的执行时间消耗在字节码验证阶段中，在 Javac 编译器和 Java 虚拟机里进行了一项联合优化，把尽可能多的校验辅助措施挪到 Javac 编译器里进行。具体做法是给方法体 Code 属性的属性表中新增一项名为 StackMapTable 的新属性，这项属性描述了方法体所有的基本块（Basic Block，指按照控制流拆分的代码块）开始时本地变量表和操作栈应有的状态，在字节码验证期间，Java 虚拟机就不需要根据程序推导这些状态的合法性，只需要检查 StackMapTable 属性中的记录是否合法即可。这样就将字节码验证的类型推导转变为类型检查，从而节省了大量校验时间

符号引用验证

最后一个阶段的校验行为发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生

符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源

准备

准备阶段是正式为类中定义的变量（即类变量也叫静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段

这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在 Java 堆中

局部变量不存在准备阶段，因此如果一个局部变量定义了但没有赋初始值是不能使用的。而类变量因为在准备阶段赋予了系统初始值，在初始化阶段即使没有赋值也能正常使用

初始值

初始值通常情况下是数据类型的零值，假设一个类变量的定义为：

public static int value = 123;

变量 value 在准备阶段过后的初始值为0而不是123，把 value赋值为123的动作要到类的初始化阶段才会被执行

如果类字段的字段属性表中存在 ConstantValue 属性，那在准备阶段变量值就会被初始化为 ConstantValue 属性所指定的初始值。只有同时被 final 和 static 修饰的字段才有 ConstantValue 属性，且限于基本类型和 String。例如下面的类变量在准备阶段会直接初始化为123

public static final int value = 123;

类变量究竟存储在哪儿？

方法区是一个逻辑上的区域，JDK 8 之前用永久代实现方法区，JDK 8 开始将其一分为二，一部分放到元空间，一部分放到堆中，类变量随着 Class 对象一起存放在 Java 堆中。元空间是使用本地内存(Native Memory)实现的，本地内存、元空间和直接内存之间的关系如下：

解析

解析阶段是 Java 虚拟机将常量池内的符号引用替换为直接引用的过程

初始化

除去加载阶段自定义类加载器，从初始化阶段开始 Java 虚拟机才真正开始执行类中编写的 Java 程序代码，将主导权移交给应用程序

准备阶段时，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源。换一种说法，初始化阶段就是执行类构造器clinit()方法的过程

六种必须初始化类的情况（其他情况不会触发初始化）

1. 遇到 new、getstatic、putstatic 或 invokestatic 这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。能够生成这四条指令的典型 Java 代码场景有：
   1. 使用 new 关键字实例化对象
   2. 读取或设置一个类型的静态字段（被 final 修饰、已在编译期把结果放入常量池的静态字段除外）
   3. 调用一个类型的静态方法
2. 使用 java.lang.reflect 包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化
3. 当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化
4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含 main()方法的那个类），虚拟机会先初始化这个主类
5. 当使用 JDK 7 新加入的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial 四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化
6. 当一个接口中定义了 JDK 8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化

这六种场景中的行为称为对一个类型进行主动引用。除此之外所有引用类型的方式都不会触发初始化，称为被动引用

被动引用的例子

/*非主动使用类字段*/
/*例一*/
public class SuperClass {
    static {
        System.out.println("SuperClass init!");
    }
    public static int value = 123;
}
public class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init!");
    }
}
public class NotInitialization {
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

上述代码运行只会输出“SuperClass init！”，而不会输出“SubClass init！”。对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。是否要触发子类的加载和验证阶段，取决于虚拟机的具体实现

/*例二*/
public class NotInitialization {
    public static void main(String[] args) {
        SuperClass[] sca = new SuperClass[10];
    }
}

代码运行没有输出“SuperClass init！”，说明并没有触发类 org.fenixsoft.classloading.SuperClass 的初始化阶段。但是这段代码里面触发了另一个名为“[Lorg.fenixsoft.classloading.SuperClass”的类的初始化阶段，我认为这个就是数组的组件类型

/*例三*/
public class ConstClass {
    static {
        System.out.println("ConstClass init!");
    }
    public static final String HELLOWORLD = "hello world";
}
public class NotInitialization {
    public static void main(String[] args) {
        System.out.println(ConstClass.HELLOWORLD);
    }
}

代码运行没有输出“ConstClass init！”，是因为在编译阶段通过常量传播优化已经将此常量的值“hello world”直接存储在 NotInitialization 类的常量池中，以后 NotInitialization 对常量 ConstClass.HELLOWORLD 的引用，实际都被转化为NotInitialization 类对自身常量池的引用了

clinit()方法

clinit()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问

public class Test {
    static {
        i = 0;  //给变量赋值可以正常编译通过
        System.out.print(i);  //这句编译器会提示“非法向前引用”
    }
    static int i = 1;
}

clinit()方法与类的构造函数（即在虚拟机视角中的实例构造器init()方法）不同，它不需要显式地调用父类构造器，Java 虚拟机会保证在子类的clinit()方法执行前，父类的clinit()方法已经执行完毕。因此在Java虚拟机中第一个被执行的clinit()方法的类型肯定是 java.lang.Object。由于父类的clinit()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作

clinit()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块和对变量的赋值操作，那么编译器可以不为这个类生成clinit()方法

接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成clinit()方法。但接口与类不同的是，执行接口的clinit()方法不需要先执行父接口的clinit()方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。接口的实现类在初始化时也一样不会执行接口的clinit()方法

Java 虚拟机必须保证一个类的clinit()方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的clinit()方法，其他线程都需要阻塞等待，直到活动线程执行完毕clinit()方法。如果在一个类的clinit()方法中有耗时很长的操作，那就可能造成多个进程阻塞，但如果执行clinit()方法的那条线程退出clinit()方法后，其他线程唤醒后则不会再次进入clinit()方法。同一个类加载器下，一个类型只会被初始化一次