。

Java虚拟机把class文件加载到内存#xff0c;并对数据进行校验、转换解析和初始化#…虚拟机类加载机制

文章目录

虚拟机类加载机制一、概述二、类加载的时机三、类加载的过程四、类加载器

一、概述

本章将要讲解class文件如何进入虚拟机以及虚拟机如何处理这些class文件。

Java虚拟机把class文件加载到内存并对数据进行校验、转换解析和初始化最终形成可以被虚拟机直接使用的Java类型这个过程被称为虚拟机的类加载机制。

这些过程都是在程序运行时发生的使Java拥有了极高的扩展性和灵活性。

一个类从被加载到虚拟机内存到卸载出内存它的生命周期会经历加载、验证、准备、解析、初始化、使用、卸载。

其中验证、准备、解析阶段统称为连接过程。

不过这些阶段也不一定是按照图中的顺序的比如解析阶段的开始可能在初始化之后这是为了支持Java的动态绑定。

这里说的开始而不是完成是因为各个阶段都在互相交叉的进行而不是等上一个阶段结束才进入下一阶段。

Java虚拟机规范并没有约束什么时候进行类的加载但是对于类的初始化有着严格的约束有且只有以下六种情况才会进行类的初始化

1遇到new、getstatic、putstatic或invokestatic这四条字节码指令时如果类型没有初始化则进行初始化。

具体场景是使用new关键字示例化对象读取或设置一个静态字段(被final修饰的除外它已经在编译期被放入常量池)调用一个类型的静态方法时

2使用java.lang.reflect包的方法对类型进行反射调用时若类型没初始化则进行初始化。

5如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄且方法句柄对应的类没有被初始化则先触发其初始化

8新加入的默认方法被default关键字修饰的接口方法时该接口要在接口的实现类之前被初始化。

对于第三种接口和类是不一样的接口并不要求其父接口全部都初始化只有真正使用到父接口才会初始化。

一加载

加载是整个类加载的一个阶段在加载阶段整个Java虚拟机需要完成以下三件事情

2、将这个字节流所代表的静态存储结果转换为方法区运行时的数据结构

3、在内存中生成一个代表此类的java.lang.class对象代表方法区此类的各种数据访问入口

这些定义并不是特别具体留给虚拟机和Java的空间很大。

例如获取此类的二进字节流并不是只能通过class文件来获取还可以从ZIP文件获取(JAR、WAR、EAR)、网络中获取(WEB

Applet)、数据库中获取、运行时计算生成(动态代理Proxy)、从其它文件中获取(JSP生成对应的class文件)

对于获取类的二进制字节流的过程非数组类型的加载阶段是可控性最强的阶段既可以使用虚拟机内置的引导类加载器来完成也可以定义自己的类加载器去完成二进制字节流的获取。

数组类本身不通过类加载器创建它是由Java虚拟机直接在内存动态创建的但是它的加载与类加载器仍有着密切关系因为数组内的元素类型还是要靠类加载器来加载。

若数组内的元素还是引用类型则再往里看并把数组标识在加载该组件类型的类加载器的命名空间上直到不是引用类型。

Java虚拟机会把数组标记为与引导类加载器关联。

加载阶段结束后Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中了类型数据妥善安置在方法区之后会在Java堆内存中实例化一个java.lang.Class类的对象这个对象将作为程序访问方法区中的类型数据的外部接口。

二验证

验证是连接阶段的第一步这一步是确保class文件的字节码都符合约束要求不会危害到JVM。

Java语言本身是相对安全的编程语言做一些访问数组边界外、跳转到不存在的代码行的事情编译器会拒绝编译抛出异常。

但是并不是所有class文件都是由Java编译而来class文件可以被编写成任何内容所以Java虚拟机需要检查输入的字节流。

验证大概有四个动作阶段文件格式验证、元数据验证、字节码验证和符号引用验证。

该阶段的验证点还有很多主要目的是确保输入的字节流能被正确的解析并存入方法区。

该阶段是基于二进制字节流的过了这个阶段字节流才允许进入虚拟机内存的方法区进行存储后面的验证都是基于方法区的存储结构上进行的不会在进行读取、操作字节流了。

这个类是否有父类(除了java.lang.object外都应该有父类)

若该类不是抽象类是否实现了其父类或者抽象类中的所有要求实现的方法

3、字节码验证这个阶段主要验证程序语义是否合法、是否符合逻辑。

主要对类的方法体(class文件的code属性)进行验证确保类的方法在运行时不会做出危害虚拟机安全的行为例如

保证类型转换是合法的例如可以把子类对象赋值给父类数据类型但把父类对象赋值给子类数据类型就是不安全的

若一个类型中有方法体的字节码没有通过字节码验证它一定是有问题的。

但是如果通过了字节码验证也不一定就没有问题。

因为无法使用程序去检验一个程序逻辑是否是正确的。

为了避免过多时间消耗在字节码验证JDK6之后给方法体Code属性的属性表添加了一项”StackMapTable”的新属性在javac编译器编译时就对这些方法进行验证然后标识StackMapTable但是这样也仍然会存在安全隐患StackMapTable在进入虚拟机之前也是可能被修改的。

4、符号引用验证这一阶段发生在虚拟机将符号引用转换为直接引用这个转换动作在解析阶段发生。

符号引用验证可以看作是对类自身以外的各类信息进行匹配性校验。

通常需要校验

在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段

符号引用验证主要是确保解析阶段可以正常运行如果不通过会抛出异常典型的有java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError

验证阶段是很重要的但并不是必须的如果一段程序是反复使用和验证过的也可以使用-Xverifynone来关闭验证以缩短虚拟机加载类的时间。

三准备

准备阶段是为类中的变量(static修饰的变量)分配内存并赋初始值的过程。

按照概念这些变量分配的空间都应该在方法区但是方法区只是一个概念在JDK8之后类变量则会随着Class对象一起存放在Java堆中。

这一阶段内存分配的仅包括类变量静态变量而不包括实例变量实例变量会随着对象实例化时和对象一起分配在Java堆中。

为类变量赋的初始值一般都是0值。

如图在准备阶段为value赋的值为0因为此时还没执行任何Java方法为value赋值123是的putstatic指令是编译后放在类构造器()方法的要到类的初始化阶段才会进行赋值。

但是如果像上图这样final修饰的变量(常量)就会在准备阶段被赋值为123。

编译时Javac将会为value生成ConstantValue属性在准备阶段就会根据ConstantValue的值为value赋值。

四解析

符号引用以一组符号描述所引用的目标符号可以是任何字面量只要能定位到目标即可。

引用的目标不一定已经加载到虚拟机中。

直接引用直接或者间接定位到目标的句柄。

引用的目标必定在虚拟机内存中存在。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这7

1、类或接口的解析假设我们当前所处的为类D要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用那么包含下面三个步骤

(1)如果C不是一个数组类型那么虚拟机会把代表N的全限定名传递给D的类加载器去加载类C。

在加载过程中可能还会进行其它类的加载由于元数据验证、字节码验证等任何地方失败即代表着解析失败。

(2)如果C是一个数组类型就要看它的元素类型。

若元素类型是一个对象就按照(1)进行加载数组元素类型普通类型就直接加载

(3)完成加载还需要验证D是否有权限访问C如果没有则抛出出java.lang.IllegalAccessError异常

2、字段解析要对一个字段解析就要先对该字段所属的类或接口的符号引用进行解析。

若是解析成功则进行接下来的步骤(该字段所属的类或接口用c表示)

(1)如果c本身就包含了简单名称和字段描述符都与目标相匹配的字段则解析结束。

(2)如果c实现了接口则会按照继承关系递归搜索各个接口和它的父接口如果有接口中包含了相匹配的字段则解析结束

(3)如果c不是java.lang.object的话则会按照继承关系递归搜索c的父类若有相匹配的字段则解析结束

(4)否则查找失败返回java.lang.NoSuchFieldError异常

如果查找到了则会对字段进行权限验证若没有权限则返回java.lang.IllegalAccessError异常。

若是一个同名字段同时出现在某类的父类和实现的接口中按照解析规则仍是可以确定唯一的访问字段但是javac编译器可能拒绝将其解析为class文件。

2、方法解析方法解析的第一步和字段解析一样也是需要先解析出方法表的class_index项中索引的方法所属的类或接口的符号引用。

方法所属的类或接口用c表示。

接下来会按照以下步骤进行解析

(1)class文件中类的方法和接口的方法的符号引用的常量类型定义是分开的如果在类的方法表中发现class_index中索引的c是个接口则抛出java.lang.IncompatibleClassChangeError

(2)在类c中若是发现简单名称和描述符都与方法相匹配的目标则直接引用

(4)否则在类c实现的接口和父接口中寻找若存在匹配的方法则说明c是一个抽象类抛出java.lang.AbstractMethodError异常

(5)否则宣告查找失败抛出java.lang.NoSuchMethodError异常

3、接口方法解析接口方法解析也是需要先解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用用c表示这个接口。

解析过程如下:

(1)与类的解析方法相反若是发现c是一个类则抛出java.lang.IncompatibleClassChangeError异常

(3)在c的父接口中查找直到java.lang.Object类查找到则直接引用

(4)由于java接口运行多继承若c的不同父类接口中查找到多个对应的方法则返回其中一个

(5)否则查找失败抛出java.lang.NoSuchMethodError异常

五初始化

类的初始化是类加载过程的最后一个步骤。

直到初始化阶段Java虚拟机才开始真正执行类中编写的Java程序代码。

在初始化阶段就是根据程序员通过程序编码制定的计划去初始化变量和其它资源。

初始化阶段就是执行类构造器()方法的过程这个方法是Javac编译器的自动生成物。

()方法是由编译器自动收集类中变量的赋值动作和静态代码块合并而成的。

编译器收集顺序是按照语句在源文件中的顺序静态语句块中只能访问定义在它之前的语句块不能访问定义在它之后的语句块但是可以给它之后的语句块赋值。

Java虚拟机会保证在子类的()方法执行前父类的已经执行所以最先执行的一定是java.lang.object的()方法。

由于先执行父类的()方法所以父类中定义静态语句块会优先于子类的变量赋值操作。

如果类或者接口中没有静态语句块和对变量对赋值语句那么编译器也可以不为这个类生成()方法

与类不同的是执行接口的()方法不需要先执行父接口的()方法只有当父接口定义的变量被使用时父接口才会被初始化。

四、类加载器

JAVA虚拟机设计团队有意把类加载过程中”根据类的全限定名加载该类的二进制字节流”这个动作放到Java虚拟机外部去实现以便让应用程序自己决定如何去获取所需的类实现这个动作的代码被称为”类加载器”。

类和类的加载器共同确定该类在Java虚拟机的唯一性。

即使两个类来源于同一个class文件被同一个Java虚拟机加载只要加载它们的类加载器不同这两个类就肯定不相等。

这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()

图中构造了一个简单的类加载器加载了一个类并实例化了这个类的对象。

通过第一行输出结果可以看出此对象确实是该类实例化出来的但通过第二行发现这个对象与类进行所属类型检查返回了false这是因为有两个classloadertest一个是虚拟机的应用程序类加载的一个是我们自定义的类加载器加载的这两个在Java虚拟机中是两个不同的类。

二双亲委派模型

站在Java虚拟机的角度来看只有两种类加载器一种是启动类加载器一种是其它所有的类加载器。

但是站在Java开发人员的角度来看类加载器应该划分的更细致一点。

Java一直保持着三层类加载器双亲委派的类加载架构。

绝大多数Java程序都会使用到以下3个系统提供的类加载器来进行加载

启动类加载器负责加载JAVA_HOME\lib中或者被java.ext.dirs系统变量所

应用程序类加载器负责加载用户类路径

ClassPath上所有的类库开发者同样可以直接在代码中使用这个类加载器。

如果程序中没有定义自己的类加载器一般情况下这个就是程序中默认的类加载器。

图7-2中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型”。

这并不是一个具有强制性约束力的模型而是Java设计者推荐给开发者的一种类加载器的最佳实现。

双亲委派模型的工作流程是当类加载器收到了加载类的请求它会先把请求委派给父类加载器去完成只有当最终父类加载器无法完成才会由子类加载器完成。

使用双亲委派模型的一个明显的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。

例如类java.lang.Object根据双亲委派模型最终一定会被最顶端的父类加载器(启动类加载器)加载。

即使用户自己写了一个java.lang.obejct类也只是可以正常编译无法被加载运行。

这段代码的逻辑是先检查该类是否被加载若没有则调用父加载器的loadClass()方法若父类为空则使用默认的启动类加载器进行加载若父类加载失败则使用自己的findClass()进行加载。

三破坏双亲委派模型

模块化出现为止双亲委派模型主要出现过3次较大规模“被破坏”的情况。

第一次被破坏发生在双亲委派模型出现之前即JDK1.2之前。

在双亲委派模型出现之前类加载器的概念和java.lang.ClassLoader在Java的第一个版本中就已经存在。

面对已经存在的用户自定义的类加载器代码在引用双亲委派模型时就不得不做一些妥协。

只能尽量引导用户在findClass方法中重写加载方法而不是在loadClass方法中。

第二次被破坏在双亲委派模型中越基础的类就由越上层的类加载器加载。

但是如果基础类型调用用户代码(如JNDI服务)启动类加载器是不会认识用户代码的。

为了解决这个困境只好引用了只好引入了一个不太优雅的设计线程上下文类加载器

Thread

ClassLoader。

使用线程上下文类加载器就可以去加载服务提供者接口相关的代码实际上也就是父类加载器去请求子类加载器完成类加载的行为这种行为违背了双亲委派模型的一般原则。

第三次被破坏是由于用户对于程序的动态性的追求导致的如模块热部署、代码热替换。

热部署的规范提案之一就是OSGiOSGi实现模块化热部署的关键是它自定义的类加载器机制的实现。

在OSGi环境下类加载器不再按照双亲委派模型而是按照网状模型进行进行搜索。