JVM类加载机制
来源:互联网 发布:淘宝不计入销量规则 编辑:程序博客网 时间:2024/05/16 10:12
从类被加载到虚拟机内存中开始,到卸载出内存为止,类的生命周期包括
加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段
其中验证、准备和解析三部分称为连接,在Java语言中,类型的加载和连接过程都是在程序运行期间完成的(Java可以动态扩展的语言特性就是依赖运行期动态加载、动态连接这个特点实现的),这样会在类加载时稍微增加一些性能开销,但是却为Java应用程序提供高度的灵活性
加载、验证、准备、初始化和卸载这5个阶段的顺序是固定的(即:加载阶段必须在验证阶段开始之前开始,验证阶段必须在准备阶段开始之前开始等。这些阶段都是互相交叉地混合式进行的,通常会在一个阶段的执行过程中调用或激活另一个阶段),解析阶段则不一定,在某些情况下,解析阶段有可能在初始化阶段结束后开始,以支持Java的动态绑定
加载(Loading)
start time:
“加载”阶段是“类加载过程”的一个阶段,虚拟机规范并没有强制约束什么时候开始类加载过程的第一个阶段:加载,而是交由虚拟机的具体实现自由把握,但是虚拟机规范严格规定有且只有4种情况(这4种情况将在后面初始化部分进行介绍)必须立即对类进行初始化,相应的加载、验证和准备阶段自然要在初始化阶段开始之前开始
task:
在加载阶段,虚拟机需要完成以下三件事(虚拟机规范对这三件事的要求并不具体,因此虚拟机实现与具体应用的灵活度相当大):
1,通过一个类的全限定名获取定义这个类的二进制流
可以从jar包、ear包、war包中获取,可以从网络中获取(Applet),可以运行时生成(动态代理),可以通过其它文件生成(Jsp)等
虚拟机规范并没有指明二进制流要从从一个Class文件中获取,准确的说是没有指明从哪里获取及如何获取(完全可以通过使用自己实现的类加载器读入一二进制流来完成加载阶段,但是一般情况下二进制流的来源还是Class文件,jar中保存的是Class文件,Jsp也是首先被编译成Class文件)
2,将这个字节流代表的静态存储结构转化为方法区的运行时数据结构
虚拟机规范并未规定方法区存储数据的具体数据结构,数据存储格式由虚拟机实现自行定义
3,在Java堆中生成一个代表这个类的java.lang.Class对象,作为方法区这些数据的访问入口
ClassLoader
首先检查应用程序类中有没有class,如果没有,检查扩展类库中有没有,然后检查启动类库中有没有
如果没有,首先在启动类加载器中加载,然后在扩展类加载器中加载,然后在应用程序类加载器中加载
启动类加载器
C++编写,无法被Java程序直接引用,是虚拟机一部分
扩展类加载器
ExtClassLoader实现,负责加载<JAVA_HOME>\lib\ext
中的,开发者可以直接使用这个类加载器
应用程序类加载器
AppClassLoader实现,加载classpath类路径上指定的类库
验证(Verification)
start time:
加载阶段与连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的,加载阶段还未结束,连接阶段可能已经开始,这部分夹杂在加载阶段进行的动作,依然属于连接阶段的内容,并且加载阶段必定早于连接阶段开始
task:
连接阶段的第一步,确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全
Java语言本身是相对安全的语言(相对于C/C++),使用纯粹的Java代码无法做到诸如访问数组边界之外的数据、将一个对象转型为它未实现的数据类型、跳转到不存在的代码行等,如果这样做了,编译器将拒绝编译,但是Class文件不一定由Java源码编译而来,完全可以使用任何途径,如:用十六进制编辑器直接编写来产生Class文件,在字节码层面上,上述Java代码无法做到的事情都是可以实现的,此时虚拟机如果不检查输入的字节流,很有可能因为载入了有害的字节流而导致系统崩溃,所以验证时虚拟机对自身保护的一项重要工作
虚拟机规范对该阶段的规定非常笼统,仅要求如果验证到输入的字节流不符合Class文件的存储格式,就抛出一个java.lang.VerifyError异常(JDK1.6的API文档对该异常类的描述为:当“校验器”检测到一个类文件虽然格式正确,但包含着一些内部不一致问题或安全性问题时,抛出该错误)或其子类异常,具体检查哪些方面、如何检查、何时检查,都未做强制要求或明确说明,故不同的虚拟机对验证的实现有所不同,但大致都会完成如下4个阶段的检查过程:
1,文件格式验证
验证字节流是否符合Class文件格式的规范,是否能被当前版本的虚拟机处理(如:是否以魔数0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内等)
该阶段的主要目的是保证输入的字节流能被正确的解析并存储于方法区内,格式上符合描述一个Java类型信息的要求
该阶段的验证是基于字节流的,经过这个阶段的验证后,字节流才会进入内存的方法区中进行存储,故后面的三个验证阶段是基于方法区的存储结构进行的
2,元数据验证
对字节码描述的信息(即类的元数据信息)进行语义分析,以保证其描述的信息符合Java语言规范的要求(如:该类是否有父类、是否继承了不允许被继承的类等)
3,字节码验证
进行数据流和控制流分析,即对类的方法体进行校验分析以保证被校验类的方法在运行时不会做出危害虚拟机安全的行为(如:保证跳转指令不会跳转到方法体以外的字节码指令上等)
即使一个方法通过了字节码验证,也不能说明其一定是安全的(通过程序去校验程序逻辑是无法做到绝对准确的)
JDK1.6之后的Javac编译器进行了一项优化,给方法体的Code属性的属性表中增加了一项新属性:StackMapTable,该属性保存了方法体中的类型信息,可以使字节码验证时的类型推导变为类型检查从而节省时间。在JDK1.6的HotSpot虚拟机中提供了-XX:-UseSplitVerifier选项来关闭这项优化,或者使用-XX:+FailOverToOldVerifier选项在类型检查失败时退回到使用类型推导方式进行校验
4,符号引用验证
对类自身以外的信息进行匹配性校验(如:符号引用中通过字符串描述的全限定名是否能找到对应的类、指定的类中是否存在符合描述符与简单名称描述的方法与字段)
该校验发生于虚拟机将符号引用转化为直接引用的时候,该转化动作发生于连接的第三个阶段:解析阶段,确保解析动作能够正常执行,如果无法通过符号引用验证,将会抛出一个java.lang.IncompatibleClassChangeError异常(特别要注意其继承自java.lang.Error而不是java.lang.Exception)的子类,其子类均为通常由编译器捕获的错误
如果运行的全部代码都已经被反复使用和验证过,在实施阶段可以使用-Xverify:none参数来关闭大部分的类验证措施以缩短虚拟机类加载的时间
准备(Preparation)
task:
虚拟机在准备阶段为类变量(static修饰的变量)分配内存,并设置类变量初始值。这些内存都将在方法区分配
有2个方面需要特别强调:
1,该阶段进行内存分配的仅包括类变量,不包括实例变量,实例变量将在对象初始化时随对象一起分配在堆内存中
2,这里所说的初始值“通常情况下”是指数据类型的零值,如一个类变量定义为:public static int a =1;,变量a在准备阶段之后的值为0而不是1
程序编译后产生将a赋值为1的putstatic指令,并将该条指令存放在类构造器<clinit>()
中,故a赋值为1的动作将在初始化阶段完成
如果类字段的字段属性表中包含ConstantValue属性,那在准备阶段变量就会被初始化为ConstantValue属性所指定的值,即如果a变量定义变为public final static int a = 1;,编译时javac会为a生成ConstantValue属性,准备阶段虚拟机就会根据ConstantValue的设置将a的值置为1
解析(Resolution)
start time:
虚拟机规范并未规定解析动作发生的具体时间,仅要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前,先对它们所使用的符号引用进行解析
task:
解析阶段是虚拟机将常量池中的符号引用(见备注一)替换为直接引用(见备注二)的过程
对同一个符号引用进行多次解析请求是很常见的,虚拟机实现可能会对第一次解析的结果进行缓存(将直接引用保存在运行时常量池中),无论是否真正执行了多次解析动作,虚拟机实现必须保证在同一个实体中,如果一个符号引用之前已经被成功解析过,后续的引用解析请求就应当一直成功,反之亦然
解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行,分别对应于常量池中CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTAN_Methodref_info、CONSTANT_InterfaceMethodref_info四种类型常量
对字段、类方法、接口方法符号引用解析前,首选会对其所在类的符号引用进行解析(详见常量池常量结构,CONSTANT_Fieldref_info、CONSTAN_Methodref_info、CONSTANT_InterfaceMethodref_info
类型常量中均保存了声明该字段、类方法、接口方法的类或接口的描述符的索引:一个CONSTANT_Class_info
类型常量的索引)
初始化(Initialization)
start time:
有且只有4种情况必须立即对类进行初始化:
1,遇到new(使用new关键字实例化对象)、getstatic(获取一个类的静态字段,final修饰符修饰的静态字段除外)、putstatic(设置一个类的静态字段,final修饰符修饰的静态字段除外)和invokestatic(调用一个类的静态方法)这4条字节码指令时,如果类还没有初始化,则必须首先对其初始化
2,使用java.lang.reflect包中的方法对类进行反射调用时,如果类还没有初始化,则必须首先对其初始化
3,当初始化一个类时,如果其父类还没有初始化,则必须首先初始化其父类
4,当虚拟机启动时,需要指定一个主类(main方法所在的类),虚拟机会首选初始化这个主类
这4种行为称为对一个类进行主动引用,除此之外所有引用类的方式,都不会触发初始化,称为被动引用
备注
1,符号引用:以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时可以无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用目标并不一定已经加载到内存中
2,直接引用:直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄,直接引用与虚拟机实现的内存布局相关,如果有了直接引用,引用目标必定已经加载到内存中
- 【JVM】JVM类加载机制
- jvm类加载机制
- JVM类加载机制
- JVM-类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM--类加载机制
- jvm类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- JVM类加载机制
- Python Tricks(三)—— 计算误分率
- Objective-C类成员变量深度剖析
- Oracle自定义函数
- POJ 1502 MPI Maelstrom(Dijkstra)
- GCD倒计时
- JVM类加载机制
- linux初始化init系统:systemd
- 【POJ 2318】TOYS(计算几何)
- 关于JavaScript中RegExp的总结
- Azkaban——使用指南
- NYOJ 题目715 Adjacent Bit Counts
- 人工智能之动物识别系统
- 【CodeForces】Toy Army(数学)
- javaee中的session的理解,你是怎么用session的