类加载
2019-06-29 21:04:09 13 举报
jvm如何类加载
作者其他创作
大纲/内容
\"解析\"阶段是虚拟机将常量池内的符号引用替换为直接引用的过程,符号引用以 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Mehodref_info 等类型的常量出现(即 类名称,变量名称,方法名称等信息)。那么符号引用与直接引用有什么关联呢?》符号引用(Symbolic References):即用一组符号来描述所引用的目标。它与虚拟机的内存布局无关,引用的目标不一定已经加载到内存中。》直接引用(Direct References):直接引用可以是指向目标的指针、相对偏移量或是一个能简介定位到目标的句柄。它是和虚拟机内存布局相关的。解析动作主要针对 类或接口、字段、类方法、接口方法、方法类型、方法句柄 和 调用限定符 7类符号引用进行。
验证
这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的需求,并且不会危害到虚拟机自身的安全。验证大致会完成下面4个阶段的校验动作:1)文件格式验证: 这阶段的验证是基于二进制字节流进行的,只有通过了这个阶段的验证后,字节流才会进入内存的方法区中进行存储,所以后面3个验证阶段都是基于方法区的存储结构进行的,不会再直接操作字节流。其中有个验证点为:CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据。这里可以明确的推论出,class文件是UTF8编码的。 2)元数据验证: 对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求。 3)字节码验证: 通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验后,这个阶段将对类的方法体进行校验,保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。 4)符号引用验证: 发生在虚拟机将符号引用转化为直接引用的时候,这个动作将在连接的第三阶段---解析阶段中发生。该过程可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验,目的是确保解析动作能正常执行。
初始化
类或接口的解析假如类D 要把一个从未解析过的符号引用N 解析为一个类或接口C 的直接引用,那虚拟机解析过程需要3个过程:1>如果C不是一个数组类型,虚拟机会把 N 的全限定名传递给 D 的类加载器去加载这个类C 。由于元数据验证 和 字节码验证 的过程, 可能会触发其它相关类的加载动作。2>如果C是一个数组类型,并且数组元素类型为对象,那将会按照第一点规则加载数组元素类型。3>如果上面步骤没有任何异常, 那么 C 已经成为了一个有效的类和接口了,但在解析完成之前还要进行符号引用验证,确认D是否具备对C的访问权限。否则会抛出java.lang.IllegalAccessError 异常。
准备
(5)当使用jdk1.7的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果是REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。
生命周期
调用父类的static字段只会输出\"SuperClass init!\",而不会输出\"SubClass init!\
类从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括:加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接(Linking)。其中类加载过程中的加载、验证、准备、解析、初始化五个阶段的顺序是确定的,而解析阶段则不一定,它在某些情况下可以在初始化阶段之后开始,这是为了支持Java语言的运行时绑定(也成为动态绑定或晚期绑定)。另外注意这里的几个阶段是按顺序开始,而不是按顺序进行或完成,因为这些阶段通常都是互相交叉地混合进行的,通常在一个阶段执行的过程中调用或激活另一个阶段。
栗子1
参考<<深入理解Java虚拟机>>
Java虚拟机规范中并没有规定类加载的第一个阶段(加载)在什么时候进行,但虚拟机却严格规定了\"有且只有\"5种情况必须立即对类进行\"初始化\",当然其他阶段也要在\"初始化\"阶段之前完成。
解析
连接(linking)
这5种场景中的行为称为对一个类进行主动引用,其他引用类的方式都不会触发初始化,称为被动引用。
(1)遇到new、getstatic、putstatic或者invokestatic这4条字节码指令时,如果类还没有进行过\"初始化\
字段解析首先对字段的位于class_index 项中索引的 CONSTANT_Class_info 符号引用,也就是字段所属的类或接口的符号引用进行解析,如果解析顺利的话,虚拟机将按照下列步骤进行字段搜索。1>如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。2>否则,如果C 中实现了接口,会按继承关系从下往上递归搜索其父接口,如果在父接口中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。3>否则,如果C 不是 java.lang.Object 的话,将会按继承关系从下往上递归搜索其父类,如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。4>否则,查找失败,抛出 java.lang.NoSuchFieldError 异常。如果查找过程成功返回了引用,将会对这个字段进行权限验证,如果发现不具备对字段的访问权限,将抛出 java.lang.IllegalAccessError 异常。
栗子2
最初以为,这里new 出来10个SupperClass对象,最后通过字节码的anewarray了解到这里是创建了一个可以存放10个SupperClass对象的容器,这里的SupperClass其实还没用new出来;通过字节码中的局部变量表可以看到,这里的sca的类型为: [Lcom/zzc/load/SupperClass;该类直接由虚拟机自动生成的。
初始化
解析
卸载
父类public class SupperClass { static { System.out.println(\"SupperClass init!\"); } public static int value = 123; public final static int finalVal = 123;}子类public class SubClass extends SupperClass { static { System.out.println(\"SubClass init!\"); }}》调用父类的static字段public class LoadMain { public static void main(String[] args) { System.out.println(SubClass.value);//字节码: getstatic #3 // Field com/zzc/load/SubClass.value:I }}运行结果SupperClass init!123》调用父类的final static字段public class LoadMain { public static void main(String[] args) { System.out.println(SubClass.finalVal);//字节码: bipush 123 }}运行结果123
准备阶段是正式为类变量分配内存并设置类变量的初始值的阶段,这些变量所使用的内存都是在方法区中进行分配。这个阶段中有两个容易产生混淆的概念:1.这个是否被分配内存的只有类变量(被static修饰的变量),而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在Java堆中。2.这里所说的初始值“通常情况”下是数据类型的零值,假设一个类变量的定义如下: public static int value = 123;那变量value在准备阶段过后的零值为0而不是123,因为这时候并未执行任何Java方法,把value赋值为123的动作是在初始化阶段才会进行。对于“非通常情况”,是指定义为常量的那些变量(即final修饰的),会在这一阶段就被赋值,如: public static final int value = 123;此时在准备阶段过后,value的值将会被赋值为123。
虚拟机类加载:把描述类的数据加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类。特点:与那些在编译时需要进行连接工作的语言不同,在java中,类型的加载、连接和初始化过程都是在程序运行期间完成的。
加载
类方法解析类方法解析第一步和字段解析是一样的,都是先解析出类方法表的 class_index 项中索引的方法所属的类或接口的符号引用,如果顺利的话,虚拟机将按下列步骤进行字段搜索。1>如果发现class_index 索引的C是个接口,那就抛出 java.lang.IncompatibleClassChangeError 异常。2>如果通过了第一步,在类C中查找是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束。3>否则,在类C的父类中递归查找,如果有就直接返回方法的直接引用,查找结束。4>否则,在类C 实现的接口列表以及他们的父接口中递归查找,如果存在,则说明C是一个抽象类,查找结束并抛出 java.lang.AbstractMehodError 的异常。5>否则,查找失败,抛出 java.lang.NoSuchMethodError 异常.最后如果查找成功,会进行权限验证。失败会抛出 java.lang.IllegalAccessError
(2)使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行初始化,则需要先触发其初始化。
接口方法解析接口方法解析第一步和字段解析是一样的,都是先解析出类方法表的 class_index 项中索引的方法所属的类或接口的符号引用,如果顺利的话,虚拟机将按下列步骤进行字段搜索。1>如果接口方法表中发现 class_index 中的索引C是个类而不是接口,就直接抛出 java.lang.IncompatibleClassChangeError 异常。2>否则,在接口C中查找是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束3>否则,在几口C 的父接口中递归查找,直到 java.lang.Object 类位置,看是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束。4>否则,查找失败,抛出 java.lang.NoSuchMethodError 异常。由于接口方法都是public的,所以不存在访问权限的问题,因此接口方法的符号解析应当不会抛出 java.lang.IllegalAccessError 异常。
接口的加载与类加载的过程的有些差异,具体来说是第3种的初始化场景有所不同,当一个类在初始化时,要求其父类全部都要完成了初始化,但对于接口来说,只有真正使用到父接口时候才会初始化。
虚拟机规范:1.通过一个类的全限定名来获取定义此类的二进制文件。2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。3.在内存中生成一个代表这个类的java.lang.Class文件,作为方法区这个类的各种数据的访问接口。相对于类加载过程的其他阶段,一个非数组类的加载阶段是开发人员可控性最强的,因为加载阶段既可以使用系统提供的引导类加载器来完成,也可以由用户自定义的类加载器去完成,开发人员可以通过重写一个类加载器的loadClass()方法来实现。 对于数组类而言,情况有所不同,数组类本身不通过类加载器创建,它是由java虚拟机直接创建,但最终还是要靠类加载器去创建,数组类的创建遵循以下规则: 1)如数组的组件类型是引用类型,就递归采用加载过程去加载这个组件类型; 2)如数组的组件类型不是引用类型,java虚拟机将会把数组标记为与引导类加载器关联; 3)数组类的可见性与它的组件的可见性一致,如果组件类型不是引用类型,那么数组类可见性默认为public加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中,方法区中的数据存储格式由虚拟机实现自行定义,虚拟机规范未规定此区域的具体数据结构。然后在内存中实例化一个java.lang.Class类的对象(并没有明确规定是在java堆中,对于HotSpot虚拟机而言,Class对象比较特殊,它虽然是对象,但是存放在方法区里面。)这个对象将作为程序访问方法区中的这些类型数据的外部接口。
(3)当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
类加载相关行为
使用
\"初始化\"是类加载的最后一步,到了这一步,才是真正开始执行类中定义的Java 程序代码。1>类构造器<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static块)中的语句合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句快可以赋值,但是不能访问。2>类构造器<clinit>()方法与类的构造函数(实例构造函数<init>()方法)不同,它不需要显式调用父类构造,虚拟机会保证在子类<clinit>()方法执行之前,父类的<clinit>()方法已经执行完毕。因此在虚拟机中的第一个执行的<clinit>()方法的类肯定是java.lang.Object。3>由于父类的<clinit>()方法先执行,也就意味着父类中定义的静态语句快要优先于子类的变量赋值操作。4><clinit>()方法对于类或接口来说并不是必须的,如果一个类中没有静态语句,也没有变量赋值的操作,那么编译器可以不为这个类生成<clinit>()方法。5>接口中不能使用静态语句块,但任然有变量的初始化的赋值动作,因此接口与类一样都会生成<clinit>()方法。但接口与类不同是,执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用时,父接口才会被初始化。另外,接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。6>虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确加锁和同步,如果多个线程同时去初始化一个类,那么只会有一个线程执行这个类的<clinit>()方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>()方法完毕。如果一个类的<clinit>()方法中有耗时很长的操作,那就可能造成多个进程阻塞。7>同一个类加载器下,一个类型只会初始化一次。
0 条评论
下一页