深入理解Java虚拟机第3版（虚拟机执行子系统）

一、类文件结构（暂无）

二、虚拟机类加载机制

2.1 类加载的时机（什么时候加载类）

这些阶段通常都是相互交叉地混合进行，会在一个阶段执行的过程种调用、激活另一个阶段。

《Java虚拟机规范》约定了有且只有六种情况必须对类进行初始化（而加载、验证、准备自然需要在此之前开始）：

1. 遇到 new 、getstatic 、putstatic 、invokestatic 这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。
   • 使用 new 关键字时候
   • 读取或设置一个类型的静态字段（被 final 修饰、已在编译器把结果放入常量池的静态字段除外）的时候
   • 调用一个类型的静态方法的时候
2. 使用 java.lang.reflect 包的方法对类型进行反射调用的时候。
3. 当初始化类的时候，如果发现其父类还没有进行初始化，则需要先触发其父类的初始化。
4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含 main() 方法的那个类）。虚拟机会先初始化这个主类。
5. 当使用 JDK7 新加入的动态语言支持时。
6. 当一个接口种定义了 JDK8 新加入的默认方法（被 default 关键字修斯的接口方法）时，如果这个接口的实现类发生了初始化，那么该接口要在其之前被初始化。

2.2 类加载的过程

2.2.1 加载

在加载阶段，Java虚拟机需要完成三件事：

1. 通过一个类的全限定名来获取定义此类的二进制字节流

   可以在本地磁盘的 .class 文件获取，也可以从ZIP压缩包中读取，也可以从网络等地方获取，没有规定。

2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

   在加载阶段结束后，Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区中，方法区中的数据存储格式完全由虚拟机自行实现。（即，把二进制字节流以指定格式保存在方法区中）

3. 在内存种生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

   类型数据妥善安置在方法区后，会在Java堆内存中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口。

2.2.2 验证

确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全（Class文件不一定由Java源码编译来的，也可能是01编辑器上敲出来的！）。

检验动作4个阶段

1. 文件格式验证

   检验字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这个阶段的验证是基于二进制字节流进行的，只有通过这个阶段的验证后，这段字节流才被允许进入Java虚拟机内存的方法区中进行存储，所以后面三个检验阶段全部是基于方法区的存储结构上进行的，不会再直接读取、操作字节流了。

2. 元数据验证

   对字节码描述进行语义分析，保证其符合《Java语言规范》。比如：这个内是否能被继承。【数据类型校验】

3. 字节码验证

   最复杂的一个阶段！主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。这阶段就要对类的方法体进行检验分析，确保不会出现什么跳转错误等行为，int用long来载入等。

4. 符号引用验证

   检测该类是否缺少或者被进制访问它依赖的某些外部类、方法、字段等资源。

2.2.3 准备

该阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段（这里的初始值一般是指零值）。

一般情况下初始值是零值。如果，有 final 关键字的话，javac将会给变量生成ConstantValue属性，这时候就会设置value的值为123。

public static final int value = 123;

这些变量所使用的内存都应当再方法区中进行分配，但是方法区毕竟只是个逻辑上的区域。JDK7及之前由永久代实现方法区，符合这种逻辑。但JDK8及之后，类变量会随着Class对象一起存放在Java堆中。

注意这里内存分配的仅包括类变量，而不包括实例变量。

2.2.4 解析

Java虚拟机将常量池内的符号引用替换为直接引用的过程。

2.2.5 初始化

直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权交给应用程序。在准备阶段，变量已经赋值过一次零值，而在初始化阶段，则会根据代码主观计划区初始化类变量和其他资源。

2.3 类加载器

”通过一个类的全限定名来获取描述该类的二进制字节流“这个动作放到Java虚拟机外部区实现，以便让应用程序自己决定如何区获取所需的类。这个动作的代码被称为”类加载器“。

2.3.1 类与类加载器

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。（即，判断两个类是否”相等“，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使两个Class类来源于同一个Class文件，被同一个Java虚拟机加载，只有加载他们的加载器不一样，这两个类就不相等）

2.3.2 双亲委派模型

在Java虚拟机角度看，只有两种类加载器：

1. 启动类加载器（是虚拟机的一部分）
2. 其他所有的类加载器（由Java语言实现，独立存在于虚拟机外，且都继承自抽象类java.lang.ClassLoader）

在Java开发人员角度看，就划分的细致了：

1. 启动类加载器（负责加载\lib 或被 -XbootclassPath 参数指定的路径）

   需要把加载请求委派给引导类加载器处理，直接用null代替即可

2. 扩展类加载器（负责加载\lib\ext 或者被 java.ext.dirs系统变量指定的路径）

3. 应用程序类加载器（负责加载用户类路径（ClassPath）上所有的类库，如果应用程序种没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器）

JDK9之前的Java应用都是由这三种类加载器互相配合完成加载的，用户还可以自定义类加载来进行扩展。这些类加载器之间的协作关系”通常“会下所示：

双亲委派模型工作过程：

如果一个类加载器收到了类的加载的请求，它首先不会自己区尝试加载这个类，而是把这个请求委派给父类去加载器去完成，每一个层次的类加载器都是如此，因此所有的类加载器最终都应该传送到最顶层的启动类加载器中，只有父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需要的类）时，子加载器才会尝试自己去完成加载。（因此Object类在程序各种加载器环境中都能够保证是同一个类）