【深入理解Java虚拟机】第七章 虚拟机类加载机制

7.2 类加载时机

类在JVM中的生命周期：

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类加载过程必须按照这种顺序开始。但解析则不一定：某些情况下可在初始化阶段之后再开始（java的运行时绑定）。

对于加载阶段，由JVM具体实现来自由把握。

对于初始化阶段，以下情况必须立即进行初始化：

1. 遇到new、getstatic、putstatic或invokestatic字节码指令时

   生成这4条指令最常见场景：new对象、读取或设置类的静态字段（final修饰、已在编译期把结果放入常量池的静态字段除外），和调用类的静态方法

2. 对类进行反射调用时

3. 初始化类时，先触发父类初始化

4. JVM启动时，用户需要指定一个要执行的主类（包含main()的类）,JVM会先初始化该类

5. 使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且该方法句柄对应的类没有进行过初始化，则需要先触发其初始化

接口的特别说明：

1. 接口中不能使用“static{ }”语句块，但编译器会为接口生成“<clinit>()”类构造器，用于初始化接口中所定义的成员变量；
2. 接口与类的区别在上文的场景3中：接口初始化时，并不要求其父接口全部都完成初始化，只有在真正使用到了父接口的时候（如引用接口中定义的常量）才会初始化。

7.3 类加载过程

7.3.1 加载

在加载阶段，JVM需要完成：

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

数组类由JVM直接创建，本身不通过类加载器创建，但是，数组类的元素是通过类加载器创建

加载阶段完成后虚拟机外部的二进制字节流就按照JVM所需的格式存储在方法区中，然后在内存中实例化一个Class对象，这个对象将作为程序访问方法区中的这些类型数据的外部接口。

7.3.2 验证

目的：确保Class文件的字节流中包含的信息符合当前JVM的要求，并且不会危害JVM自身的安全

大致包含下面四个阶段：

1. 文件格式验证：验证字节流是否符合Class文件格式规范，并能被当前版本的JVM处理。该阶段的主要目的：保证输入的字节流能正确地解析并存储于方法区内，格式上符合描述一个Java类型信息的要求
2. 元数据验证：对字节码描述的信息进行语义分析，保证其描述的信息符合Java语言规范的要求。该阶段主要目的：对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息
3. 字节码验证：主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。对类的方法体进行校验分析
4. 符合引用验证：该阶段发生在JVM将符号引用转化为直接引用的时候，这个转化动作在解析阶段中发生。符号引用验证可以看做是类对自身以外（常量池中的各种符号引用）的信息进行匹配性校验。目的是确保解析动作能正常执行

7.3.3 准备

此阶段正式为类变量（static修饰的变量）分配内存并设置类变量初始值。

这里的初始值“通常情况”下是数据类型的零值；在“特殊情况”下，类字段的字段属性表中存在ConstantValue属性，则在准备阶段变量就会被初始化为所指定的值

//通常情况
//准备阶段后初始值为 0，而不是 123
public static int value = 123;

//特殊情况
//准备阶段后就被赋值为123
public static final int value = 123;

7.3.4 解析

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

• 符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可
• 直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。

1） 类或接口的解析

假设当前代码所处的类为D，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，整个解析过程：

1. 如果C不是一个数组类型，那JVM会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中，由于元数据验证、字节码验证的需要，有可能触发其他相关类的加载动作
2. 如果C是一个数组类型，并且数组的元素类型为对象，那将会按照第一点的规则加载数组元素类型，接着由JVM生产一个代表此数组维度和元素的数组对象
3. 通过以上步骤，C在JVM中实际上已经成为一个有效的类或接口。但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。

2）字段解析

在解析一个未被解析的字段符号引用时，会先解析字段所属的类或接口（用C表示）的符号引用。

然后通过以下步骤进行字段搜索：

1. 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束；
2. 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和它的父接口，如果接口中有匹配的，则返回字段直接引用，查找结束；
3. 否则，如果C不是Object的话，按照继承关系从下往上递归搜索其父类，如果在父类中有匹配的，则返回字段直接引用，查找结束
4. 否则，查找失败

成功返回引用后，会对该字段进行权限验证。

3）类方法解析

先解析其所属类或接口（用C表示）符号引用，然后按照以下步骤搜索：

1. 类方法和接口方法符号引用的常量 类型定义是分开的，如果在类方法表中发现此项不匹配，直接抛异常；
2. 在C中检查是否有简单名称和描述符都与目标相匹配的方法，有则返回方法的直接引用，查找结束；
3. 否则，在C的父类中递归查找相匹配的
4. 否则，在C实现的接口列表及它们的父接口中递归查找，如果存在匹配方法，说明C是一个抽象类；
5. 否则，查找失败

查找成功之后，进行权限验证

4）接口方法解析

解析所属的类或接口==>在接口方法表中是否相符==>在接口C中查找==>在C的父接口中递归查找，直到Object为止==>否则，查找失败

接口中方法默认都是public，不存在访问权限问题

7.3.5 初始化

执行类构造器<clinit>()方法的过程。

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

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

• <clinit>()与类的构造函数不同，它不需要显式地调用父类构造器，JVM会保证在子类的<clinit>()方法执行前，父类的已经执行。

• 由于父类的<clinit>()方法先执行，就意味着父类中定义的静态语句块要优先于子类的变量赋值操作

• <clinit>()对于类或接口来说不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，则编译器可以不为这个类生成<clinit>()

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

• JVM会保证一个类的<clinit>()的方法在多线程环境中被正确的加锁、同步。如果在一个类的<clinit>()中有耗时很长的操作，就可能造成多个进程阻塞

7.4 类加载器

类加载器：实现“通过一个类的全限定名来获取此类的二进制字节流”的动作的代码模块

7.4.1 类与类加载器

比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义。

这里的“相等”，包括代表类的Class对象的equals()、isAssignFrom()、isInstance()方法返回的结果，也包括使用instanceof关键字做对象所属关系判定等情况。

7.4.2 双亲委派模型

绝大部分Java程序都会使用到以下3种系统提供的类加载器：

• 启动类加载器（引导类加载器， Bootstrap ClassLoader）：
  • 使用C/C++语言实现，嵌套在JVM内部
  • 加载Java的核心库，用于提供JVM自身需要的类
  • 并不继承自java.lang.ClassLoader，没有父加载器
  • 加载扩展类和应用程序类加载器，并指定为他们的父类加载器
  • 处于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
• 扩展类加载器（Extension ClassLoader）：
  • 加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量索指定的路径中的所有类库。开发者可直接使用
  • java语言编写
  • 派生于ClassLoader类
  • 父类加载器为启动类加载器
• 引用程序类加载器（系统类加载器，AppClassLoader）：
  • 一般也称系统类加载器。负责加载用户类路径上所指定的类库。开发者可直接使用。如果程序中没有自定义过自己的类加载器，一般情况下该加载器就是程序中默认的
  • java语言编写
  • 派生于ClassLoader类
  • 通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器

类加载器之间的关系如下图：

双亲委派模型工作过程：

如果一个类加载器收到了类加载的请求，首先是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个请求时，子加载器才会尝试自己去加载

双亲委派模型优势：

1. 避免类的重复加载
2. 保护程序安全，防止核心API被随意篡改

双亲委派模型并不强制使用，只是java设计者推荐给开发者的类加载器实现方式。