虚拟机类加载过程(二)
程序员文章站
2022-03-11 20:12:17
...
类加载过程
也就是加载、验证、准备、解析、初始化这5阶段的具体动作：
加载阶段
①通过一个类的全限定名来获取定义此类的二进制字节流
②将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构
③在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口.
虚拟机规范并没有详细说明从哪里获取一个二进制字节流，充满创造力的开发人员玩出了各种花样，例如从 zip 包中读取，最后从 jar、ear、war 中读取.从网络中读取，运行时计算生成.由其他文件生成，例如 jsp
相对于类加载过程的其他阶段，一个非数组类的加载阶段(准确的说是加载阶段中获取类的二进制字节流的动作)是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式(即重写一个类加载器的 loadClass 方法).
对于数组类而言，情况有所不同，数组类本身不是通过类加载器创建，它是由 java 虚拟机直接创建的. 但数组类和类加载器还是有很大联系的，数组类的元素类型最终还是要靠类加载器去创建，一个数组类创建过程遵循以下规则：
1.如果数组的组件类型(Component Type，指的是数组去掉一个维度的类型)是引用类型，那就递归采用本届中定义的加载过程去加载这个组件类型，数组C将在加载该组件类型的类加载器的类名称空间上被标识
2.如果数组的组件类型不是引用类型(例如 int[] 数组)，java虚拟机将会把数组C标记为与引导类加载器关联
3.数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那么数组类的可见性将默认为 public.
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中，方法区中的数据存储格式由虚拟机实现自行定义.然后在内存中实例化一个 java.lang.Class 类的对象(并没有明确规定是在 java 堆中，对于 Hotspot 虚拟机而言，Class 对象比较特殊，它虽是一个对象，但是存放在方法区里)，这个对象作为程序访问方法区中的这些类型数据的外部接口.
加载阶段与连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始.
验证阶段
这一阶段是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全.
这一阶段很重要，直接决定了 Java 虚拟机是否能承受恶意代码的攻击，但是虚拟机规范中没有给出具体检查哪些方面，如何检查，何时检查，都没有足够具体的要求和明确的说明. 直到2011年发布的 java SE 7. 从整体上看，验证阶段大致会完成下面4个阶段的检查动作：文件格式验证、元数据验证、字节码验证、符号引用验证.
1.文件格式验证：验证字节流是否符合 Class 文件格式的规范，并且能被当前版本的虚拟机处理.
①是否以魔数 0xCAFEBABE 开头
②主、次版本号是否在当前虚拟机处理范围内
③常量池中的常量是否有不被支持的常量类型
④指向常量池的各种索引值中是否有指向不存在的常量或不符合类型的常量
⑤Constant_Utf8_info 型的常量中是否有不符合 UTF8 编码的数据
⑥Class文件中各个部分及文件本身是否有被删除的或附加的其他信息
该验证阶段的主要目的是要保证输入的字节流能正确的被解析并存储在方法区之内，格式上符合描述一个 java 类型信息的要求. 后面 3 个验证阶段全部是基于方法区的存储结构进行，不会再直接操作字节流.
2.元数据验证
第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合 java 语言规范的要求，这一阶段可能包括的验证点如下：
①这个类是否有父类(除了 Object 外，其他所有的类都有父类)
②这个类的父类是否继承了不允许被继承的类(被 final 修饰的类)
③如果这个类不是抽象类，是否实现了其父类或接口中要求的所有方法
④类中的字段、方法是否与父类产生矛盾(例如覆盖了父类的 final 字段)
第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合 java 语言规范的元数据信息。
3.字节码验证
主要目的是通过数据流和控制流分析，确保程序语义是合法的、符合逻辑的, 这个阶段对类的方法体进行校验分析，确保被校验类的方法在运行时不会做出危害虚拟机安全的事件，例如：
①保证任何时刻操作数栈的数据类型与指令代码序列都能配合工作
②保证跳转指令不会跳转到方法体以外的字节码指令上
③保证方法体中的类型转换是有效的
4.符号引用验证
最后一个阶段的校验发生在虚拟机将符号引用转换为直接引用的时候，这个转换动作将在了解的第三阶段——解析阶段中发生. 符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验，通常需要校验下列内容：
①符号引用中通过字符串描述的全限定名是否能找到对应的类
②在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
③符号引用中的类、字段、方法的访问性是否可被当前类访问.
符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么将会抛出 java.lang.IncompatibleClassChangeError 异常的子类.
验证阶段并不是一定需要的，如果所有运行的全部代码都已被反复使用和验证过，那么在实施阶段就可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间.
准备阶段
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配. 值得注意的是，这里只是为类变量分配内存，而不包括实例变量，实例变量在堆中分配内存. 再者，这里说的初始值通常情况下是该数据类型的零值，假设：
public static int value = 123;
那么变量 value 在准备阶段过后的初始值是 0 而不是 123.
需要注意的是，如果类字段的字段属性表中存在 ConstantValue 属性，那么在准备阶段变量 value 就会被初始化为 ConstantValue 属性所指定的值.
public static final int value = 123;
也就是加载、验证、准备、解析、初始化这5阶段的具体动作：
加载阶段
①通过一个类的全限定名来获取定义此类的二进制字节流
②将这个字节流所代表的静态存储结构转换为方法区的运行时数据结构
③在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口.
虚拟机规范并没有详细说明从哪里获取一个二进制字节流，充满创造力的开发人员玩出了各种花样，例如从 zip 包中读取，最后从 jar、ear、war 中读取.从网络中读取，运行时计算生成.由其他文件生成，例如 jsp
相对于类加载过程的其他阶段，一个非数组类的加载阶段(准确的说是加载阶段中获取类的二进制字节流的动作)是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式(即重写一个类加载器的 loadClass 方法).
对于数组类而言，情况有所不同，数组类本身不是通过类加载器创建，它是由 java 虚拟机直接创建的. 但数组类和类加载器还是有很大联系的，数组类的元素类型最终还是要靠类加载器去创建，一个数组类创建过程遵循以下规则：
1.如果数组的组件类型(Component Type，指的是数组去掉一个维度的类型)是引用类型，那就递归采用本届中定义的加载过程去加载这个组件类型，数组C将在加载该组件类型的类加载器的类名称空间上被标识
2.如果数组的组件类型不是引用类型(例如 int[] 数组)，java虚拟机将会把数组C标记为与引导类加载器关联
3.数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那么数组类的可见性将默认为 public.
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中，方法区中的数据存储格式由虚拟机实现自行定义.然后在内存中实例化一个 java.lang.Class 类的对象(并没有明确规定是在 java 堆中，对于 Hotspot 虚拟机而言，Class 对象比较特殊，它虽是一个对象，但是存放在方法区里)，这个对象作为程序访问方法区中的这些类型数据的外部接口.
加载阶段与连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始.
验证阶段
这一阶段是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全.
这一阶段很重要，直接决定了 Java 虚拟机是否能承受恶意代码的攻击，但是虚拟机规范中没有给出具体检查哪些方面，如何检查，何时检查，都没有足够具体的要求和明确的说明. 直到2011年发布的 java SE 7. 从整体上看，验证阶段大致会完成下面4个阶段的检查动作：文件格式验证、元数据验证、字节码验证、符号引用验证.
1.文件格式验证：验证字节流是否符合 Class 文件格式的规范，并且能被当前版本的虚拟机处理.
①是否以魔数 0xCAFEBABE 开头
②主、次版本号是否在当前虚拟机处理范围内
③常量池中的常量是否有不被支持的常量类型
④指向常量池的各种索引值中是否有指向不存在的常量或不符合类型的常量
⑤Constant_Utf8_info 型的常量中是否有不符合 UTF8 编码的数据
⑥Class文件中各个部分及文件本身是否有被删除的或附加的其他信息
该验证阶段的主要目的是要保证输入的字节流能正确的被解析并存储在方法区之内，格式上符合描述一个 java 类型信息的要求. 后面 3 个验证阶段全部是基于方法区的存储结构进行，不会再直接操作字节流.
2.元数据验证
第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合 java 语言规范的要求，这一阶段可能包括的验证点如下：
①这个类是否有父类(除了 Object 外，其他所有的类都有父类)
②这个类的父类是否继承了不允许被继承的类(被 final 修饰的类)
③如果这个类不是抽象类，是否实现了其父类或接口中要求的所有方法
④类中的字段、方法是否与父类产生矛盾(例如覆盖了父类的 final 字段)
第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合 java 语言规范的元数据信息。
3.字节码验证
主要目的是通过数据流和控制流分析，确保程序语义是合法的、符合逻辑的, 这个阶段对类的方法体进行校验分析，确保被校验类的方法在运行时不会做出危害虚拟机安全的事件，例如：
①保证任何时刻操作数栈的数据类型与指令代码序列都能配合工作
②保证跳转指令不会跳转到方法体以外的字节码指令上
③保证方法体中的类型转换是有效的
4.符号引用验证
最后一个阶段的校验发生在虚拟机将符号引用转换为直接引用的时候，这个转换动作将在了解的第三阶段——解析阶段中发生. 符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验，通常需要校验下列内容：
①符号引用中通过字符串描述的全限定名是否能找到对应的类
②在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
③符号引用中的类、字段、方法的访问性是否可被当前类访问.
符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么将会抛出 java.lang.IncompatibleClassChangeError 异常的子类.
验证阶段并不是一定需要的，如果所有运行的全部代码都已被反复使用和验证过，那么在实施阶段就可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间.
准备阶段
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配. 值得注意的是，这里只是为类变量分配内存，而不包括实例变量，实例变量在堆中分配内存. 再者，这里说的初始值通常情况下是该数据类型的零值，假设：
public static int value = 123;
那么变量 value 在准备阶段过后的初始值是 0 而不是 123.
需要注意的是，如果类字段的字段属性表中存在 ConstantValue 属性，那么在准备阶段变量 value 就会被初始化为 ConstantValue 属性所指定的值.
public static final int value = 123;