虚拟机执行子系统

虚拟机加载机制

类加载时机

一个类型从被加载到虚拟机中开始，到卸载出内存为止。它的生命周期将回经历加载、验证、准备、解析、初始化、使用、和卸载七个阶段。其中验证、准备、解析三个部分统称为连接。

1. 加载

   在加载阶段，虚拟机需要完成三个事情

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

   对于数组类来说，情况就有所不同了。数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构造出来的。但是数组类与类加载器还是由很密切的关系。因为数组类的元素类型最终更是要考类加载器来完成加载。

   加载阶段与连接阶段的部分动作是交叉进行的。加载阶段尚未完成，连接阶段可能就已经开始。

2. 验证

   验证的目的是确保Class文件的字节流中包含的信息符合虚拟机规范中的要求，确保这些代码运行之后不会危害虚拟机自身的安全。

   验证包括了：

   • 文件格式验证

     //.是否以魔数0xCAFEBABE开头。
     //·主、次版本号是否在当前Java虚拟机接受范围之内。 
     //·常量池的常量中是否有不被支持的常量类型（检查常量tag标志）。 
     //·指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。 
     //·CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。 
     //·Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。
     

   • 元数据验证

     第二阶段是堆字节码描述的信息进行语义分析，以保证其描述的信息符合要求。主要包括的验证点如下：

     #这个类是否由父类
     #这个类的父类是否继承了不允许被继承的类
     #如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所哟的方法
     

   • 字节码验证

     通过数据流分析和控制流分析确定程序语义是否是合法的符合逻辑的。

   • 符号引用验证

     最后一个阶段的校验行为发生在虚拟机将符号引用转换为直接引用的时候，这个转换动作将在连接的第三个阶段解析阶段中发生。符号引用验证可以看作是对类自生以外的各类信息进行匹配性校验，

     # 符号引用中通过字符串描述的全限定名是否能找到对应的类
     # 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
     # 符号引用中的类、字段、方法的可访问性是否可被当前类访问
     

3. 准备

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

   从概念上来讲，这些变量所使用的内存应该在方法区中进行分配。但必须注意到方法区只是一个逻辑上的区域，7以前使用永久代来实现方法区。8之后类变量会随着Class对象一起存放在Java堆中。

   😕在准备阶段进行内存分配的只是类变量，但是不包括实例变量。实例变量将会在对象实例化的时候随着对象一起分配在Java堆中。

   其次就是在赋值的时候全部是默认的初值 例如public static int value = 123 在准备阶段之后初始值是0而不是123 如果变量的值设置的是常量 也就是说被final修饰的 那么这时候就分配的是自己赋值的值 而不是默认的初始值。

4. 解析

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

   • 符号引用

     符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时可以无歧义的定位到目标即可。符号引用与虚拟机现实的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存中的内容。

   • 直接引用

     直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用时和虚拟机实现的内存布局直接相关的。

5. 初始化

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

   在准备阶段的时候变量已经赋值过，但是是赋值的是默认的初始值，在初始化阶段则会根据代码中指定的值来进行初始化。

类加载器

类加载器只用于实现类的加载动作，对于任何一个类，都必须由加载它的类加载器和这个类本身一起共同确定其在虚拟机中的唯一性。每一个类加载器都拥有一个独立的类名称空间。

双亲委派模型

站在虚拟的角度来看，只存在两种不同的类加载器：一种是启动类加载器（BootStrap ClassLoader），是虚拟机的一部分。另外一种就是其他所有类的类加载器，这些类加载器由Java语言实现，独立存在于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader

1. 启动类加载器

   这个类加载器主要负责加载<JAVA_HOME>\lib目录中的类库加载到虚拟机的内存中。

   启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可

2. 扩展类加载器

   负责加载<JAVA_HOME>\lib\ext目录中。由于扩展类加载器是Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件

3. 应用程序类加载器

   由于应用程序类加载器是ClassLoader类中getSystemClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库
   

   双亲委派模型要求除开顶层的启动类加载器之外，其余的类加载器都应该有自己的父类加载器。不过这里的类加载器之间的父子关系不是继承的关系来实现的，而通常使用组合关系来服用父类加载器的代码。

//双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加 载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的 加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请 求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

使用双亲委派模型来组织类加载器之间的关系，系，一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。