类加载的过程

1、加载

Java需要完成这三个事情：

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

2、验证

验证是连接阶段的第一步，目的是保证Class文件的字节流信息符合规定，保证这些信息不会危害虚拟机安全。验证阶段大概会从完成下面四个阶段的检验动作：文件格式验证（格式）、元数据验证（描述信息）、字节码验证（方法）、符号引用验证（引用）。

2.1 文件格式验证

验证字节流是否符合Class文件格式规范。例如：

• 是否以魔数0xCAFEBABY开头；
• 主、次版本号是否在当前Java虚拟机的接受范围；
• 常量池中的常量是否有不支持的常量类型；
• .........

目的：保证输入的字节流能够正确地解析并存储到方法区之内，格式上符合Java类信息的要求。

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

2.2 元数据验证

验证字节码描述信息是否符合语义。例如：

• 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）
• 这个类是否继承了不允许被继承的类
• ......

目的：对类的元数据进行语义校验，保证不出现与《Java语言规范》定义相悖的元数据信息

2.3 字节码验证

目的：通过数据流分析和控制流分析，确定程序的语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型校验完毕之后，这阶段就要对类的方法体(class文件中的code属性)进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机的行为。

例如：

• 保证任何指令都不会跳转到方法体以外的字节码指令上
• 保证任何时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似于“在操作栈放置了一个int雷星星的数据，使用时却按照long类型的数据来加载入本地变量表中”这样的情况

由于数据流分析和控制流分析的高度复杂性，Java虚拟机的设计团队为了避免过多的执行时间消耗在字节码验证阶段中，在JDK 6之后的Javac编译器和Java虚拟机里进行了一项联合优化，把尽可能多的校验辅助措施挪到Javac编译器里进行。具体做法是给方法体Code属性的属性表中新增加了一项名 为“StackMapTable”的新属性，这项属性描述了方法体所有的基本块（Basic Block，指按照控制流拆分 的代码块）开始时本地变量表和操作栈应有的状态，在字节码验证期间，Java虚拟机就不需要根据程 序推导这些状态的合法性，只需要检查StackMapTable属性中的记录是否合法即可。这样就将字节码验 证的类型推导转变为类型检查，从而节省了大量校验时间。理论上StackMapTable属性也存在错误或被 篡改的可能，所以是否有可能在恶意篡改了Code属性的同时，也生成相应的StackMapTable属性来骗过 虚拟机的类型校验，则是虚拟机设计者们需要仔细思考的问题。

JDK 6的HotSpot虚拟机中提供了-XX：-UseSplitVerifier选项来关闭掉这项优化，或者使用参数XX：+FailOverToOldVerifier要求在类型校验失败的时候退回到旧的类型推导方式进行校验。而到了 JDK 7之后，尽管虚拟机中仍然保留着类型推导验证器的代码，但是对于主版本号大于50（对应JDK 6）的Class文件，使用类型检查来完成数据流分析校验则是唯一的选择，不允许再退回到原来的类型 推导的校验方式。

2.4 符号引用验证

目的：符号引用校验可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验。

最后一个阶段的校验行为发生在虚拟机将符号引用转化为直接引用的时候，这个转化的动作将在连接的第三个阶段--解析阶段中发生。符号引用校验可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验。例如：

• 符号引用中通过字符串描述的全限定名是否能找到对应的类
• 在指定类中是否存在符合方法的字段描述及简单名称所描述的方法和字段
• ......

如果程序运行的全部代码（包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码）都已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用-Xverify：none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3、准备

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

从概念上讲，这些变量所使用的内存都用该在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域，在JDK1.7之前，HotSpot使用永久代来实现方法区，实现是完全符合这种逻辑概念的；而JDK1.8及之后，类变量则会随着Class对象一起存放在Java堆中，这时候“类变量在方法区”就完全是一种对逻辑概念的表述了。

4、解析

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

• 符号引用（Sysmbolic References）：符号引用以一组符号来描述所引用的目标，符号可以使任何形式的字面量，只要使用时无歧义地定位到目标即可。
• 直接引用（Direct References）：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的。

触发时机：在执行ane-warray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invoke-special、invokestatic、invokevirtual、ldc、ldc_w、ldc2_w、multianewarray、new、putfield、和putstatic这17个用于操作符号引用的字节码指令之前，先对他们所使用的符号引用进行解析。对方法和字段访问，还会检查其可访问性。

解析对象：解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符，对应着常量池中的CONSTANT_Class_info、CON-STANT-Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethod_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_Dyna-mic_info和CONSTANT_InvokeDynamic_info8种常量类型。

5、初始化

初始化是类加载过程的最后一个步骤。这个阶段Java虚拟机才真正开始执行类中编写的Java程序代码，将主权移交给应用程序。

初始化阶段就是执行类构造器<clinit>()方法的过程。<clinit>()并不是程序员在代码中直接编写的方法，它是Javac编译器的自动生成物。

• <clinit>()方法时由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的。静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
• <clinit>()方法与类的构造函数不同，它不需要显示地调用父类构造器，Java虚拟机会保证在子类的<clinit>()方法执行前，父类的<clinit>()方法已经执行完毕。因此Java虚拟机中第一个被执行的<clinit>()方法肯定是java.lang.Object。
• <clinit>()方法对于类或接口来说不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
• 接口中不能使用静态代码块，但是会有变量初始化赋值操作。与类不同的是，执行接口的<clinit>()方法不需要先执行父类的<clinit>()方法，只要当父接口中定义的变量被使用时，父接口才会被初始化。接口实现类在初始化时，也不会执行接口的<clinit>()方法。
• Java虚拟机必须保证一个类的<clinit>()方法在多线程环境中被正确地加锁同步。如果多个线程同事初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程阻塞。