文章收录在网站：http://hardyfish.top/
文章收录在网站：http://hardyfish.top/
文章收录在网站：http://hardyfish.top/
文章收录在网站：http://hardyfish.top/
类加载机制
类加载机制的过程是什么呢？
JVM把描述类的数据从Class文件中 加载到内存中，并对其进行 校验， 解析， 初始化
- 最终就会形成能被JVM直接使用的Java类型，这个过程就是虚拟机的 类加载机制
这样的类加载机制有什么优缺点呢？
与其他语言在编译期间就需要连接不同，在Java中 类型的加载、连接和初始化都是在程序运行期间完成的
虽然这样为Java应用 提高了极大的扩展性和灵活性，但是 提前编译(
AOT)技术就有了困难(因为需要是在运行前编译)
- 以及在 类加载时会稍微增加一些性能开销
Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的
类加载的时机
- 一个类的生命周期：加载到内存开始，移出内存结束
- 类的整个生命周期会经历七个阶段：
- 加载(loading)，验证(verification)，准备、解析(Resolution)、初始化、使用、卸载
- 我们通过一个图来理解：
加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的
- 而解析阶段则不一定（因为有时可以在初始化阶段之后再进行）
【注】：这五个阶段的顺序是确定的，指的是开始顺序是确定的
- 而执行过程其实是相互交叉混合进行的，
验证,准备,解析＝＝连接过程什么时候进入第一个阶段加载并没有什么强制约定，这可以由JVM自由把控
但是对于初始化阶段，《Java虚拟机规范》则是严格规定 有且只有六种情况可以对类进行初始化,俗称主动引用
- 初始化之前，加载、验证、准备阶段已经完成
遇到 new、 getstatic、 putstatic或 invokestatic这四条字节码指令时
- 如果该类没有进行过初始化，则需要先对其进行初始化
相对应于Java代码场景就是：
使用 new关键字创建实例化对象的时候
读取或设置一个类的 静态字段(如果该字段被final关键字修饰，则会在编译器iu放入到了常量池中，不算)
调用一个类的 静态方法
通过用
java.lang.reflect包对类进行 反射调用的时候初始化该类时，如果有父类且没有初始化，则 先触发父类的初始化
VM启动时，会首先对 主类(包含main()方法的类)进行初始化
JDK7以后，通过 动态语言支持，如果一个
java.lang.invoke.MethodHandle实例最后的解析结果为：
- REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类的 方法句柄
- 且对应的类没有初始化，则需要先触发其初始化
被 default关键字修饰的接口，如果该接口的实现类发生了初始化，那在这之前要先初始化该接口
除了上面6种，其他引用类的方式都不会触发初始化，俗称被动引用
我们分析几种被动引用的情况
通过子类引用父类的静态字段，不会导致子类初始化
public class SuperClass {
static {
System.out.println("SuperClass init!");
}
public static int value = 123;
}
public class SubClass extends SuperClass {
static {
System.out.println("SubClass init!");
}
}
public class NotInitialization {
public static void main(String[] args) {
System.out.println(SubClass.value);
}
}
- 结果分析：对于静态字段，只有直接定义这个字段的类才会被初始化
- 因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化
- 至于是否要触发子类的加载和验证阶段，在《Java虚拟机规范》中并未明确规定，所以这点取决于虚拟机的具体实现
通过数组定义来引用类，不会触发此类的初始化
package org.fenixsoft.classloading;
public class NotInitialization {
public static void main(String[] args) {
SuperClass[] sca = new SuperClass[10]; //SuperClass 在上面代码中提到
}
}
结果分析：
这段代码没有输出"SuperClass init！"，说明并没有触发类
org.fenixsoft.classloading.SuperClass的初始化阶段其实它初始化了名为
[Lorg.fenixsoft.classloading.SuperClass的类的初始化阶段它对于用户代码来说并不是合法的类名，因为它是由虚拟机自动生成的，直接继承于
java.lang.Object的子类，创建动作由字节码指令newarray触发这个类代表了一个元素类型为
org.fenixsoft.classloading.SuperClass的一维数组数组中应有的属性和方法（用户可直接使用的只有被修饰为public的length属性和clone()方法）都实现在这个类里
正是这个类包装了数组元素的访问，所以当检查到发生数组越界时，会抛
java.lang.ArrayIndexOutOfBoundsException异常【注】：越界检查不是封装在数组元素访问的类中，而是封装在数组访问的xaload、xastore字节码指令中
常量（final修饰）在编译阶段会存入调用类的常量池中
- 本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化
package org.fenixsoft.classloading;
public class ConstClass {
static {
System.out.println("ConstClass init!");
}
public static final String HELLOWORLD = "hello world";
}
public class NotInitialization {
public static void main(String[] args) {
System.out.println(ConstClass.HELLOWORLD);
}
}
结果分析：
在编译阶段通过常量传播优化，已经将此常量的值“hello world”直接存储在NotInitialization类的常量池中
- 以后NotInitialization对常量ConstClass.HELLOWORLD的引用，实际都被转化为NotInitialization类对自身常量池的引用了
说白了，NotInitialization的Class文件之中并没有ConstClass类的符号引用入口，当它们编译成Class文件之后就不存在什么联系了
接口的加载过程与类加载过程稍有不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的
上面的代码都是用静态语句块
static{}来输出初始化信息的，而接口中不能使用static{}语句块
- 但编译器仍然会为接口生成
< clinit >()类构造器，用于初始化接口中所定义的成员变量接口与类真正有所区别的是前面讲述的六种“有且仅有”需要触发初始化场景中的第三种：
- 当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化
- 只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化
类加载的过程
类加载分为5个阶段：加载、验证、准备、解析和初始化
加载
加载阶段是整个 “类加载” 过程中的一个阶段
在加载阶段我们要完成三项工作：
通过一个类的全限定名获取定义此类的二进制流
将这个字节流所代表的 静态存储结构转化为 方法区的运行时数据结构
在内存中生成一个代表这个类的
java.lang.Class对象，作为方法区的这个类的各种数据的访问入口【注】：《Java虚拟机规范》对这三点要求其实并不是特别具体，留给VM实现与Java应用的灵活度都是相当大的
尤其是第1条，它并没有规定这个二进制流必须从哪里(比如
Class文件)获取，以及如何获取比如：可以从ZIP压缩包中获取，从网络中获取，可以运行时计算生成(动态代理技术)，从加密文件获取等，因此也对生生成了不同的Java技术
相对于类加载过程的其他阶段，非数组类型的加载阶段（准确地说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的阶段
因为在加载阶段，我们可以通过JVM内置的引导类加载器完成，也可以通过自定义的类加载器去控制二进制流的获取方式来完成
- 这样我们就可以根据自己的想法来赋予程序获取运行代码的动态性
【注】：对于数组类而言，加载阶段略有不同
- 因为数组类本身不通过类加载器创建，而是由JVM直接在内存中动态构建出来的
但是数组类中的元素类最终还要靠类加载器去完成。 数组类的创建规则如下：
如果数组的组件类型（Component Type，指的是数组去掉一个维度的类型，注意和前面的元素类型区分开来）是引用类型
- 那就递归采用本节中定义的加载过程去加载这个组件类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上
如果数组的组件类型不是引用类型（例如
int[]数组的组件类型为int），JVM将会把数组C标记为与引导类加载器关联数组类与它的组件类型的的可访问性一致，如果组件类型不是引用类型，那么数组类的可访问性默认为public
获取二进制流后，VM外部的二进制字节流就按照VM所需的格式存储在方法区之中
- 之后在Java堆中实例化一个
java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据加载阶段与连接阶段的部分动作是交叉进行了，加载阶段尚未完成，连接阶段可能已经开始
验证
验证是连接的第一步
目的：
- 确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，并且运行后不会危害VM自身的安全
意义：
- Java虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有错误或有恶意企图的字节码流而导致整个系统受攻击甚至崩溃
- 所以验证字节码是Java虚拟机保护自身的一项必要措施
不同的虚拟机对类验证的实现可能会有所不同，但 大致都会完成以下四个阶段的验证：
- 文件格式的验证
- 元数据的验证
- 字节码验证
- 符号引用验证
文件格式的验证：
验证字节流是否符合Class文件格式的规范，并能被当前VM处理
比如：是否以魔数0xCAFEBABE开头
主、次版本号是否在接受范围内、常量池的常量是否支持等；
主要目的是保证输入的字节流能正确地解析并存储于方法区之内(这也说明了不同的阶段是混合交叉运行)
经过该阶段的验证后，这段字节流才会进入内存的方法区中进行存储
- 所以 后面的三个验证都是基于方法区的存储结构进行的
元数据的验证：
对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在与《Java语言规范》定义相悖的元数据信息
- 比如：这个类是否有父类、如果有父类那该类是否能被继承(final修饰的类不能作父类)
- 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法等等。
字节码验证：
该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析
- 以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为
符号引用验证：
最后一个阶段的校验行为发生在VM将 符号引用转化为直接引用的时候，也就是在 解析阶段中发生
符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验
- 通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。
如果无法通过符号验证，JVM将会抛出一个
java.lang.IncompatibleClassChangeError的子类异常验证阶段对于虚拟机的类加载机制来说，是一个非常重要的、但却不是必须要执行的阶段，因为验证阶段只有通过或者不通过的差别
- 只要通过了验证，其后就对程序运行期没有任何影响了
准备
准备阶段是正式为静态变量分配内存并设置初始值的阶段
这个阶段进行内存分配的 仅仅是静态变量，没有实例变量
- 实例变量将会在对象实例化的时候随着对象一起分配在Java堆中
这是所说的初始值，指的是数据类型的零值，而不是被在Java代码中被显式赋予的值
- 初始化Java代码中被显示赋予的值是用putstatic指令，存放于类构造器
< clinit >()方法之中，也就是在初始化阶段才被执行如果类字段的字段属性表中存在 ConstantValue属性(final和static同时修饰)
- 那在准备阶段变量值就会被初始化为ConstantValue属性所指定的初始值
- 我们通过被动引用的第三个例子也可以知道，被final和static同时修饰的变量(常量)在编译时期就被放入到了常量池中
解析
解析阶段是JVM将常量池内的符号引用替换为直接引用的过程；(符号引用–>直接引用)
符号引用：
以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可
- (符号引用与虚拟机实现的内存布局 无关)（各种JVM实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的）
直接引用：
可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄
- (直接引用是和虚拟机实现的内存布局 直接相关的)
初始化
类的初始化阶段是类加载过程的最后一个步骤，直到初始化阶段，JVM才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序
在准备阶段，变量已经赋过一次系统要求的初始零值，而在初始化阶段
- 则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源
初始化阶段就是执行类构造器
< clinit >()方法的过程
- 该方法并不是程序员在Java代码中直接编写的，而是Javac编译器的自动生成物
988
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
