JVM基础(四):类加载机制与类加载器

什么是类的加载机制?

虚拟机把描述类的数据从Class文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机的类加载机制。

类加载的过程:

    包括加载、链接(含验证、准备、解析)、初始化


JVM基础(四):类加载机制与类加载器_第1张图片


1.加载

什么情况下需要开始类加载过程第一阶段:加载?Java虚拟机规范中并没有进行强制约束,这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段,虚拟机规范则是严格规定了有且只有5中情况必须对类进行“初始化”。

在加载阶段,虚拟机需要完成一下3件事情:

1)通过一个类的全限定名来获取定义此类的二进制字节流。

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

3)在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口。

虚拟机规范的这3点要求其实并不算具体,因此虚拟机实现与具体应用的灵活度都是相当大的。例如第一条“通过一个类的全限定名来获取定义此类的二进制字节流。”,并没有指明二进制字节流要从要给Class文件中获取,准确的说是根本没有指明要从哪里获取、怎么获取。

2.验证

验证是连接阶段的第一步,这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全

虚拟机如果不检查输入的字节流,并对其完全信任的话,很可能会因为载入了有害的字节流而导致系统崩溃,所以验证是虚拟机对自身保护的一项重要工作。这个阶段是否严谨,直接决定了java虚拟机是否能承受恶意代码的攻击。

从整体上看,验证阶段大致上会完成4个阶段的校验工作

  1. 文件格式验证
  2. 元数据验证
  3. 字节码验证
  4. 符号引用验证

2.1文件格式验证

验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。这个阶段验证是基于二进制字节流进行的,只有通过这个阶段的验证后,字节流才会进入内存的方法区进行存储,所以后面的3个阶段的全部是基于方法区的存储结构进行的,不会再直接操作字节流。

2.1.1元数据验证

该阶段对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求,目的是保证不存在不符合Java语言规范的元数据信息

2.1.2字节码验证

该阶段主要工作时进行数据流和控制流分析,保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。 例如,保证跳转指令不会跳转到方法体以外的字节码指令上、保证方法体中的类型转换是有效的等等。

由于数据流校验的高复杂性,耗时较大,所以JDK1.6之后,在Javac中引入一项优化方法(可以通过参数关闭):在方法体的Code属性的属性表中增加一项“StackMapTable”属性,该属性描述了方法体中所有基本块开始时本地变量表和操作栈应有的状态,从而将字节码验证的类型推导转变为类型检查从而节省一些时间。

注意: 如果一个方法体通过了字节码验证,也不能说明其一定是安全的,因为校验程序逻辑无法做到绝对精确。

2.1.3符号引用验证

最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接的第三个阶段——解析阶段中发生。符号引用验证的目的是确保解析动作能正常执行。

验证的内容主要有:

  • 符号引用中通过字符串描述的全限定名是否能找到对应的类;
  • 在指定类中是否存在符号方法的字段描述及简单名称所描述的方法和字段;
  • 符号引用中的类、字段和方法的访问性(private、protected、public、default)是否可被当前类访问。

3.准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配。(备注:这时候进行内存分配的仅包括类变量(被static修饰的变量),而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在Java堆中)。

初始值通常是数据类型的零值:

对于:public static int value = 123;,那么变量value在准备阶段过后的初始值为0而不是123,因为这时候尚未开始执行任何java方法,把value赋值为123的动作将在后面的【初始化阶段】才会被执行。

一些特殊情况:

对于:public static final int value = 123;编译时Javac将会为value生成ConstantValue属性,在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。

基本数据类型的零值:

JVM基础(四):类加载机制与类加载器_第2张图片


4.解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

那么符号引用与直接引用有什么关联呢?

4.1 看两者的概念。

  • 符号引用(Symbolic References): 符号引用以一组符号来描述所引用的目标,符号可以是符合约定的任何形式的字面量,符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中。
  • 直接引用(Direct References): 直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用与虚拟机实现的内存布局相关,引用的目标必定已经在内存中存在。

虚拟机规范没有规定解析阶段发生的具体时间,虚拟机实现可以根据需要来判断到底是在类被加载时解析还是等到一个符号引用将要被使用前才去解析。

5.初始化

类初始化阶段是类加载的最后一步,前面的类加载过程中,除了在加载阶段用户应用程序可以通过自定义类加载器参与之外,其余动作完全由虚拟机主导和控制。到了初始化阶段,才真正开始执行类中定义的java程序代码(或者说是字节码)。

------------------------分隔符。。-------------------------------------------------------------

类加载器

主要讲两点

  1. 什么是类加载器
  2. 双亲委派模型

1.什么是类加载器?

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为【类加载器】。

从Java开发人员的角度来看,绝大部分Java程序都会使用到以下3种系统提供的类加载器。

启动类加载器(Bootstrap ClassLoader):

这个类加载器负责将存放在\lib目录中的,或者被-Xbootclasspath参数所指定的路径中的,并且是虚拟机识别的(仅按照文件名识别,如rt.jar,名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中。

扩展类加载器(Extension ClassLoader):

这个加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。

应用程序类加载器(Application ClassLoader):

这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也称它为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

双亲委派模型

双亲委派模型(Pattern Delegation Model),要求除了顶层的启动类加载器外,其余的类加载器都应该有自己的父类加载器。这里父子关系通常是子类通过组合关系而不是继承关系来复用父加载器的代码。

JVM基础(四):类加载机制与类加载器_第3张图片

双亲委派模型的工作过程: 如果一个类加载器收到了类加载的请求,先把这个请求委派给父类加载器去完成(所以所有的加载请求最终都应该传送到顶层的启动类加载器中),只有当父加载器反馈自己无法完成加载请求时,子加载器才会尝试自己去加载。

使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是java类随着它的类加载器一起具备了一种带有优先级的层次关系

注意:双亲委派模型是Java设计者们推荐给开发者们的一种类加载器实现方式,并不是一个强制性 的约束模型。在java的世界中大部分的类加载器都遵循这个模型,但也有例外。

你可能感兴趣的:(Java基础,JVM基础)