主要做的事儿
虚拟机把描述的数据从class文件加载到内存,并对数据进行校验,转换解析和初始化,最终形成可以被虚拟机直接使用的java类型,这就是虚拟机直接使用的java类型,这就是虚拟机的类加载机制。
类加载的时机
-
类从被加载到虚拟机内存开始到卸载出内存为止,它的整个生命周期包括:加载、验证、准备、解析、初始化、使用、卸载7个阶段。
-
验证、准备、解析3个部分称为连接。
-
解析阶段的顺序并不是确定的。
-
有且仅有5种情况必须立即对类进行初始化。
i.遇到new、getSatic、putStatic、或者invokeStatic这4条字节码指令时,如果类没有进行过初始化,则需要先触发其初始化,生成这4条指令最常见的java代码的场景是:使用new关键字实例化对象的时候、读取或者设置一个类的静态字段的时候、以及调用一个类的静态方法的时候。
ii.使用java.lang.reflect包的方法对类进行反射调用的时候,如果类不进行初始化,则先对类进行初始化。
iii.当初始化一个类的时候,发现其父类没进行初始化,则需要先触发其父类的初始化。
iiii.当虚拟机启动时,用户需要指定一个要执行的主类,虚拟机会先初始化这个主类。
v.当使用动态语言时,如果一个就java.lang.invoke.methodHandle实现最后的解析结果,ref_getStatic、ref_putStatic、ref_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则触发其初始化。
-
这5种场景中的行为称为对一个类进行主动引用,除此之外的所有引用类的方式都不会触发初始化,称为被动引用。
-
不会对类进行初始化的情况。
i.通过子类引用父类静态字段,不会导致子类的初始化。
ii.通过数据定义来引用类,不会触发此类的初始化。
iii.常量在编译阶段会存入类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的初始化。
-
接口的加载过程与类加载过程稍有不同,接口也有初始化过程,这一点与类是一致的,接口与类真正有区别的前面讲的5种“有且仅有”需要初始化场景的第3类:当一个类在初始化时,要求其父类全部都已经初始化过了,但是一个接口在初始化时,并不要求其父接口全部都完成了初始化,只有在真正使用到父接口的时候才会初始。
类加载的过程
一、加载
-
在类加载阶段,虚拟机需要完成3件事:
i.通过一个类的全限定名来获取定义此类的二进制字节流。
ii.将这个字节流所代表的静态存储结构转化为方法取得运行时数据结构。
iii.在内存中生成一个代表这个类的java.lang.class对象作为这个类的各种数据的访问入口。
-
对于数组类而言,情况有所不同,数组类不通过类加载器创建,它是由Java虚拟机直接创建的,但是数组类加载仍然有很密切的关系,因为数组类的元素类型最终是要靠类加载器去创建,一个数组类创建过程遵循以下规则:
i.如果数组的组件类型是引用型,那就递归采用本节中定义的加载过程去加载这个组件类型,数组C将在加载该组件类型的类加载器的类名称空间上被标识。
ii.如果数组的组件不是引用类型,java虚拟机将会把数组C标记为与引导类加载器关联。
iii.数组类的可见性与他的组件类型一致,如果组件类型不是引用类类型,那数组类的可见性为public。
-
加载的阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式的存储在方法区之中,方法区中的数据存储格式由虚拟机实现自行定义,然后在内存中实例化一个java.lang.class类的对象。对于hotSpot虚拟机而言,class对象比较特殊,它虽然是对象,但是存在方法区里面。
二、验证
-
验证是连接阶段的第一步,这一阶段的目的是为了确保class文件的字节流中包含的信息,符合当前虚拟机的要求。并且不会危害虚拟机自身的安全。
-
文件格式的验证
i.第一阶段要验证字节流是否符合class文件格式的规范,并且能被当前版本的虚拟机处理。
1).是否以模式0XCAFEBABE开头。 2).主次版本号是否在当前虚拟机处理范围内。ii.这一阶段验证是基于二进制字节流进行的,只有通过这个阶段的验证后,字节流才会进入内存的方法区中存储,所以后面的3个验证阶段全部是基于方法区的存储结果进行,不会直接操作字节流。
-
元数据验证
i.这个阶段对字节码描述的信息进行语义分析。
1).这个类是否有父类,除了java.lang.object之外,所有类都应有父类。 2).这个类是否继承了不允许被继承的类。 -
字节码验证
i.第三个阶段是整个验证过程中最复杂的一个阶段,主要目的是通过数据流和控制流分析,确定程序语义是合法的,这个阶段将对类的方法进行校验分析。
1).保证任意时刻操作数栈的数据类型字节码与指令代码能配合工作。 2).保证跳转指令不会跳转到方法体以外的字节码指令上。ii.JavaC编译器和java虚拟机中进行了一项优化给方法的code属性属性表中增加了一项名为stackMapTable的属性,这项属性描述了方法体中所有的基本块,开始时本地变量表和操作数栈应有的状态,在字节码验证期间,就不需要根据程序推导这些状态的合法性,只需要检查stackMapTable属性中的记录是否合法即可。
-
符合引用验证
i.最后一个阶段的检验发生在虚拟机将符号引用转化为直接引用。
1).符号引用中通过字符串描述的全限定名是否能找到对应的类。 2).在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。ii.对于虚拟机的类加载机制来说,验证是一个非常重要的,但是不是必要的阶段,如果运行的全部代码都被反复的执行过,可以通使用-Xverify:none参数来关闭验证。
三、准备
-
准备阶段是为类变量分配内存并设置类变量初始化的阶段,这些变量所使用的内存都在方法区中进行分配。
1).这时候进行内存分配的仅包括类变量,不包括实例变量。 2).public static int value=123 那value在准备阶被初始化为0,而不是123. -
特殊情况,如果类字段的字段属性表中存在ConstantValue属性,那么准备阶段被初始为ConstantValue属性所指定的值。
四、解析
-
解析阶段是虚拟机将常量池内的符号引用转为直接引用的过程。
i.符号引用:符号应用以一组符号来描述所引用的目标,符号可以是任何形式的字面量。
ii.直接引用: 直接引用可以是直接目标的指针、相对偏移量或是一个能间接定位到目标的句柄。
iii.虚拟机实现可以对第一次解析的结果进行缓存,对于invokeDynamic指令,必须等到程序实际运行受到字体指令的时候,才进行解析的。
-
类或接口的解析
-
需要经过一些3个步骤,N-符号引用/c类接口,代码所处类D。
i.如果C不是一个数组类型,那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类的C。
ii.如果是一个数组类型,并且数组的元素类型为对象,那将会按照i点的规则加载数组元素类型,接着由虚拟机生成哥代表次数组维度和元素的数组对象。
iii.如果上面的步骤,那么C在虚拟机中实际上成为一个有效的类或者接口了,在解析完成之前还要进行符号引用验证,确认D是否具备C的访问权限。
-
字段解析
-
字段的解析步骤如下:所属的类或接口用C表示。
i. 如果C本身就是包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
ii.如果在C中实现了接口,将会按照基础关系从下往上搜索各个接口和他的父接口,如果接口中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
iii.否则,如果C不是java.lang.object的话,将会按照继承关系从下往上递归搜索其父类,如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段则但会这个字段的直接引用,查找结束。
iiii.否则,查找失败,抛出java.lang.NosuchaFieldErrr异常,如果查找过程返回了引用,会对这个字段进行权限验证。
-
类方法解析
i. 类方法解析的步骤,依然用C表示这个类
1).类方法和接口方法符号引用的常量类型定义是分开的,入股在类方法表示中发现class_index中索引的c是一个接口,那就直接抛出java.lang.IncompatibleClassChangeError异常。 2).如果通过第一步,在类C中查找是否有简单名称和描述符都与目标匹配的方法,如果有则返回这个方法的直接引用。 3).否则,在类C的父类中递归查找是否有简单名称和描述都与目标相匹配的方法,如果有则返回这个方法的直接引用。 4).否则在类C的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标匹配的方法,如果存在,说明C是个抽象类,查找结束,抛出异常。 5).否则查找失败,抛出异常,如果查找成功,返回了直接引用,将对这个方法进行验证。 -
接口方法解析
i. 接口方法解析的步骤,C表示这个接口。
1).与类方法解析不同,如果在接口方法表中发现class_index中的索引C是个类而不是一个接口,那直接抛出异常。 2).否则,在接口C中查找是否有简单名称和描述符与目标相匹配的方法,如果有则返回这个方法的直接引用。 3).否则,在接口C的父接口,递归查找,直到java.lang.object类为止,看是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用。 4).否则,宣告方法查找失败,抛出异常,由于接口的所有方法默认是public的问题,所以不存在权限的问题。 -
初始化
i.到了初始化阶段,才是真正执行类中定义的java代码。
ii.在准备阶段,变量已经赋过一次系统要求的初始值,而在初始胡阶段,则根据程序制定的主观计划去初始化类和其他资源。
iii.初始化是执行类构造器方法的过程。
iiii.方法执行过程
1).<clinit>方法是由编译器自动收集类中的所有变量的赋值语句和静态语句块中的语句合并产生的。编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块只能访问到定在静态语句块之前的变量,定义在它之后的变量,在前面静态语句块可以赋值,但是不能访问。 2).<clinit>方法与类的构造函数,或者说实例构造器<init>方法不同,它不需要显示的调用父类的构造器,虚拟机会保证在子类的<clinit>方法执行之前,父类的<clinit>方法已经执行完毕,因此在虚拟机中第一个被执行的<clinit>方法的类肯定是java.lang.object. 3).由于父类的<clinit>方法先执行,也就意味着父类中定义的静态语句块要优于子类的变量赋值操作。 4).<clinit>方法对于类或接口来说并不是必须的,如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成<clinit>方法。 5).接口中不能使用静态语句块,但是仍然有变量初始化的赋值操作,因此接口与类一样都生成<clinit>方法。但是接口与类不同的是,执行接口的<clinit> 方法不需要先执行父类的<clinit> 方法,只有父类接口中定义的变量使用时,父接口才会初始化,另外接口的实现类在初始化时也一样不会执行接口的<clinit> 方法。 6).虚拟机会保证一个类的<clinit>方法在多线程环境中被正确的加锁同步,如果多线程同时去初始化一个类,那么只会有一个线程去执行这类的<clinit>方法,其他线程都需要阻塞等待,直到活动线程执行<clinit> 方法完毕。
五、类加载器
- 虚拟机设计团队,吧类加载阶段中通过该一个类的全限定名来获取描述此类的二进制字节流,这个动作放到java虚拟机外部去实现,以便让应用程序自己觉得如何获取所需要的的类,实现这个动作的代码模块称为类加载器。
一、类与类加载器
- 对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立奇再java虚拟机的唯一性,比较两个类是否相等,只要在这个两个类由同一个类加载器加载的前提下才有意义。
二、双亲委派模型
-
从java虚拟机的角度来说,只存在两种不同类加载器,一种是启动类架子器,是虚拟机自身的一部分,另一种就是其他的类加载器,这些类架子啊奇都由java语言实现,独立于虚拟机外部,并且都继承抽象类java.lang.classloader.
-
从java开发人员的角度来说,类加载器还得分的更细致一下,绝大部分都会使用以下3中系统提供的类加载器。
i.启动类加载器,前面已经介绍过,这个类加载器负责将存放在java_home\lib 目录中的,或者被-XbootClassPath参数所指定的路径中的,并且是虚拟机识别的类,加载到虚拟机内存中,启动类加载器无法被java程序直接引用,用户在编写自定义类加载器是,如果需要吧加载请求委派给引导类的加载器,那么直接使用null代替即可。
ii.扩展类加载器,这个加载器由sun.misc.launder$ExtclassLoader实现,他负责加载java_hoem\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。
iii.应用程序加载器:这个类加载器由sun.misc。lander$appcalssloader实现,由于这个类加载器是classloader中的getSysytemClassloader方法返回值,所以一般称他为系统类加载器,它负责加载用户类路径上的所指定的类,开发者可以直接使用这个类加载器,如果应用程序中没有定义过自己的类加载,一般情况下是程序中默认的类加载器。
-
类加载器之间的这种层次关系,称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器,这里类加载期间的父子管子一般不会以基层的关系来实现,而是都使用自核关系来复用父加载器。
-
双亲韦帕模型的工作过程是:如果一个类加载器收到了类加载的请求,他收下不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次额类的加载器都是如此,因此所有的加载请求最终都应该传递到了顶层的启动类加载其中,只有当父类加载器反馈自己无法完成这个加载请求时,子类加载器才会尝试自己去加载。
-
双亲委派的优点:以Object为例,无论哪一个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器,因为object类在程序的各种类加载中都是同一个类。
我是菜鸟,希望大家多多留言讨论~谢谢!
我的笔记是看完深入理解java虚拟机的体会,是本好书,推荐给大家.