图片 5

深入理解Java虚拟机总结-虚拟机类加载机制

2.CONSTANT_Fieldref入口解析

由于一个类型不会含有其超类型所定义的字段,所以对目标字段的搜索将会从字段所
指向的类型开始,从该类型开始搜索,再递归搜索其所实现或扩展的接口,再递归搜索其超类,直至找到目标字段,并会将运行时常量池的该字段入口标记为已解
析,并在该常量池的数据上改为对这个字段的直接引用。

类加载的时机

类从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括:加载(Loading)、
验证(Verification)、 准备(Preparation)、 解析(Resolution)、
初始化(Initialization)、 使用(Using)和卸载(Unloading)7个阶段。
其中验证、 准备、 解析3个部分统称为连接(Linking)。其中,加载、 验证、
准备、 初始化和卸载这5个阶段的顺序是确定的。

图片 1

图1 类的生命周期

双亲委派模型

图片 2

上图中的展示的这种类加载器之间的这种层次关系,就被称为类加载器的双亲委派模型.双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器.这里类加载器之间的父子关系一般不会以继承的关系来实现,而是都采用组合关系来复用类加载器的代码.

我们下面详细介绍上面提到的三个主要的类加载器:启动类加载器(Bootstrap
ClassLoader), 扩展类加载器(Extension ClassLoader),
应用程序类加载器(Application ClassLoader)
.

  • 启动类加载器(Bootstrap
    ClassLoader):这个类加载器负责将存放在<JAVA_HOME>lib目录中的,或者被-Xbootclasspath参数所指定的路径中的,并且是虚拟机识别的(仅按照文件名识别,如rt.jar.名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中.启动类加载器无法被Java程序直接引用,用户在编写自定义类加载器时,如果需要把加载请求委派给引导类加载器,那直接使用null代替即可.

  • 扩展类加载器(Extension
    ClassLoader):这个加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载<JAVA_HOME>libext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器加载.

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

双亲委派模型的工作过程是:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当附加在其反馈自己无法完成这个加载请求(它的搜索范围没有找到搜索的类)时,子加载器才会尝试自己去加载.

使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种具有优先级的层次关系.例如类java.lang.Object,它存放在rt.jar中,无论哪一个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类.相反,如果没有使用双亲委派模型,由各个类加载器自行去加载的话,如果用户自己编写了一个成为java.lang.Object的话,并放在程序的ClassPath中,那系统将会出现多个不同的Object类,Java类型体系中最基础的行为也就无法保证,应用程序也将会变得一篇混乱.

双亲委派模型也只是JVM规范中推荐我们使用的方式,在必要的时候,我们完全可以打破这种规则.比如OSGI的实现.

3.CONSTANT_Methodref入口解析

与字段的搜索类似但有所不同,其搜索顺序将从该类型开始,再递归搜索其超类,在递归搜索其所实现或扩展的接口。

数组类的加载

数组类本身不通过类加载器创建,它是由Java虚拟机直接创建的。
但数组类的元素类型需要靠类加载器去创建。

  • 如果数组的组件类型(Component
    Type,指的是数组去掉一个维度的类型)是引用类型,那就递归去加载这个组件类型,数组C将在加载该组件类型的类加载器的类名称空间上被标识
  • 如果数组的组件类型不是引用类型(例如int[]数组),Java虚拟机将会把数组C标记为与引导类加载器关联。
  • Class对象虽然是对象,但是存放在方法区里面

初始化阶段

初始化阶段中,对象按照程序员的意愿进行初始化.在准备阶段,已经为类变量赋值过一个零值,这个阶段则是将类变量初始化为程序员指定的值.换句话说,初始化阶段是执行<clinit>方法的过程.

那么<clinit>方法是怎么生成的呢?它是由编译器自动收集类中的所有类变量赋值动作和静态代码块中的语句合并产生的.编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块中可以赋值,但是不能访问.

<clinit>方法与类的构造函数(或者说实例构造器<init>)不同,它不需要显式地调用父类构造器,虚拟机会保证在子类的<clinit>方法执行之前,父类的<clinit>方法已经执行完毕.因此在虚拟机中第一个被执行的<clinit>方法的类肯定是java.lang.Object.

<clinit>方法对于类或接口来说并不是必须的,如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成<clinit>方法.

接口中不能使用静态语句块,但仍然有变量初始化的赋值操作,因此接口与类一样都会生成<clinit>方法.但接口与类不同的是,执行接口的<clinit>方法不需要先执行父接口的<clinit>方法.只有当父接口中定位的变量使用时,父接口才会初始化.另外,接口的实现类在初始化时也一样不会执行接口的<clinit>方法.

虚拟机会保证一个类的<clinit>方法在多线程环境中能被正确的枷锁,同步,如果多个线程同时去初始化一个类,那么只会有一个线程
去执行这个类的<clinit>方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>方法完毕.需要注意的是,其他线程虽然会被阻塞,但如果执行<clinit>方法的那条线程退出<clinit>方法后,其他线程唤醒之后不会再次进入<clinit>方法.同一个类加载器下,一个类型只会初始化一次.

6.直接引用

常量池解析最终将符号引用替换成为直接引用。指向类型、类变量和类方法的直接引用可能为在方法区的指针。而指向实例变量和实例方法的直接引用是从对象映像的开始到该实例变量或方法表的偏移。

实例变量的组织方式为:从Object类开始到该实例的类型,将类中声明的实例变量按在class文件中出现的顺序依次放在对象映像中。
实例方法的组织方式较为类似:从Object类开始到该实例的类型,将类中声明的实例方法指针按在class文件中出现的顺序依次放在对象映像中。但对于重写的方法将出现在超类对应的位置(该方法第一次出现的位置)。

但是访问接口方法就不能简单地通过方法表的偏移量来进行访问,而必须搜索对象的类的方法表来找到该方法。

比如Factory接口分别由A和B来实现其produce()方法,但由于A和B不能保证由同一个实现了Factory接口的超类派生,即有着同样的produce()方法偏移,那么就无法通过方法表的偏移来访问Factory的produce()方法。

类的准备

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

  • 在“通常情况”下初始值是零值,那相对的会有一些“特殊情况”:如果类字段的字段属性表中存在ConstantValue属性,那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值

类加载过程

类加载分为下面的几个阶段:

  • 加载
  • 连接
    • 验证
    • 准备
    • 解析
  • 初始化

下面我们将会详细介绍每个阶段要做的事情.

需要注意的是,这几个阶段并不是严格按照的按照先后顺序来完成的,比如,验证阶段的最后一个验证过程就是穿插在解析阶段中进行的.

5.CONSTANT_String入口解析

Java虚拟机会将字符串处理为一个字符串对象加以维护,而虚拟机所维护的就是一张
字符串池,它包含所有被”拘留”的字符串对象的引用。对CONSTANT_String常量池的解析首先就要查看字符串池中该字符串对象的引用是否存在,
如果存在则直接把常量池数据解析为该字符串对象的引用,若不存在,那么就需要根据这个字符串序列创建一个字符串对象,并将其引用加入到字符串池中,并将常
量池数据解析为该引用。

也可以使用String对象的intern对象来拘留一个字符串(注意并非字符串对象),若该字符串池中存在对该字
符串序列的对象的引用,那么直接返回该引用即可,否则,将会拘留该字符串,但注意拘留返回的字符串对象引用将不会指向原String对象,因为原
String对象位于Java堆,而字符串池的对象是虚拟机所创建的,由虚拟机所维护。

package com.ice.intern;

public class InternTest {

    public static void main(String args[]){
        String a = new String("123");
        String b = a;
        String c = new String("123");;

        System.out.println("before intern:");
        System.out.println("a = b ? :" + (a == b));
        System.out.println("a = c ? :" + (a == c));

        a = a.intern();
        c = c.intern();

        System.out.println("after intern:");
        System.out.println("a = b ? :" + (a == b));
        System.out.println("a = c ? :" + (a == c));
    }

}

结果如下:

图片 3

(6).其他类型(数据基本类型)入口解析

直接使用常量池所包含的常量值即可

虚拟机类加载机制

注:此文是我在读完周志明老师的深入理解Java虚拟机之后总结的一篇文章,请阅读此书获取更加详细的信息.

1.CONSTANT_Class入口解析

数组类的符号解析较为特殊。若是基本类型数组,那么虚拟机将创建该基本类型的新数组类,并创建一个Class实例来代表该类型,数组类的定义类加载器为
启动类加载器。若是引用类型的数组,那么在此之前还会进行引用类型的解析,数组类的定义类加载器为引用类型的定义类加载器。

非数组类和接口的的解析将经历以下步骤:

(1).加载该类型和其所有的超类型

如果该类型在此之前已经装载到了虚拟机的当前命名空间,那么直接使用已经被装载的类型即可,否则由引用的发起类的初始类加载器进行加载。对目标类型的超类的加载必然是在对当前类型加载完的基础上进行的,因为只有加载完当前类型,才能从class文件的super_class域找到其直接超类的符号引用,再递归进行解析和加载,直至java.lang.Object类。而在递归返回的过程中,会检查interfaces域以查看实现或扩展了哪些接口,并再次递归遍历对接口的符号引用。

(2).检查访问权限

随后是对目标类型的连接和初始化,这样才可以正常使用该类型。前面提到,对目标类型的初始化需要其所有超类都必须进行初始化(超接口不是必须的),并且,由于已经对其超类进行了加载,所以不必再依赖于自该类向Object类的解析顺序,而是从Object类向该类进行初始化。类型的连接和初始化步骤如下:

(3).类型校验

(4).类型准备

(5).类型解析(可推迟)

注意该过程是对被引用类型及其超类的符号引用的解析,因为对于被引用类型的某些符号引用不会立刻用到,故该步骤之前是严格意义上属于发起引用的类型的符号
解析的过程。只有在主动使用被引用类型的这些符号引用所指向的类型时,才会对这些符号引用进行解析,对其所指向的类型进行装载、连接和初始化。

(6).类型初始化

类加载器

每一个类加载器,都拥有一个独立的类名称空间

类加载的时机

  • 遇到new, getstatic, putstatic,
    invokestatic
    四条字节码指令时,如果类没有进行过初始化,则需要先触发其初始化.生成这四条指令的最常见的Java代码场景是:使用new关键字实例化对象的时候,读取或设置一个类的静态字段(被final修饰,已在编译器把结果放入常量池的静态字段除外)的时候,以及调用一个类的静态方法的时候.

  • 使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发其初始化.

  • 当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化.

  • 当虚拟机启动时,用户需要指定一个要执行的主类(包括main()方法的那个类),虚拟机会先初始化这个主类

  • 当使用JDK1.7的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic,
    REF_putStatic,
    REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化.

接口的加载过程和类的加载过程有一些区别,主要体现在上面的第三点,当一个类在初始化时,要求其父类全部都已经初始化过了.而接口在初始化时,并不要求其父接口全部都完成了初始化,仅在使用的时候才会初始化.

在Java应用程序运行时,Java虚拟机会保存一份内部的运行时常量池,它区别于class文件的常量池,是class文件常量池映射到虚拟机中的数据结构。
关于class文件常量池的部分可以参考之前的博文实例探索Class文件。

接口的初始化

与类的初始化相同,除了第三点,一个接口在初始化时,并不要求其父接口全部都完成了初始化,只有在真正使用到父接口的时候(如引用接口中定义的常量)才会初始化。而且接口中,无法使用静态语句块。

解析阶段

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程.那么什么是符号引用,什么是直接引用呢?

  • 符号引用:符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可.符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中.各种虚拟机实现的内存布局可以各不相同,但是它们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中.

  • 直接引用:直接引用可以是直接指向目标的指针,相对偏移量或是一个能间接定位到目标的句柄.直接引用是和虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同.如果有了直接引用,那引用的目标必定已经在内存中存在.

简单来说,就是符号引用就是一个字符串,如类的全限定名.而直接引用就是一个reference类型.可以通过句柄或者直接引用的方式实现.

针对类,方法和字段,解析又分为好几种不同的类型:

  • 类或接口解析:假设当前代码所处的类为D,如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用

    • 如果C不是一个数组类型,那么虚拟机将会把代表N的全限定名传给D的类加载器去加载这个类C.在加载过程中,由于元数据验证,字节码验证的需要,又可能触发其他相关类的加载动作,例如加载这个类的父类或实现接口.一旦这个加载过程出现了任何异常,解析过程就宣告失败.
    • 如果C是一个数组类型,并且数组的元素类型为对象,那么先按照第一条规则加载数据的元素类型,接着由虚拟机生成一个代表次数组维度和元素的数组对象.
    • 如果上面的步骤没有出现任何异常,那么C在虚拟机中实际上已经成为一个有效的类或接口了,但在解析完成之前还要进行符号引用验证,确认D是否具备对C的访问权限.如果发现不具备访问权限,将抛出java.lang.IllegalAccessError.
  • 字段解析:要解析一个未被解析过的字段符号引用,首先将会对字段表内class_index项张索引的CONSTANT_Class_info符号引用进行解析,也就是字段所属的类或接口的符号引用.如果在解析这个类或接口符号引用的过程中出现了任何异常,都会导致字段符号引用解析失败.如果解析成功,那将这个字段所属的类或接口用C表示,虚拟机规范要求按照如下步骤对C进行后续字段的搜索

    • 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束
    • 否则,如果在C中实现了接口,将会按照继承关系从下往上递归搜索各个接口和它的父接口,如果接口中包含了简单名称和字段描述符斗鱼目标相匹配的字段,则返回这个字段的直接引用,查找结束
    • 否则,如果C不是java.lang.Object的话,将会按照继承关系从下往上递归搜索其父类,如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束.
    • 否则,查找失败,抛出java.lang.NoSuchFieldError异常
    • 如果查找过程成功返回了引用,将会对这个字段进行权限验证,如果发现不具备对字段的访问权限,将抛出java.lang.IllegalAccessError异常.
  • 类方法解析:类方法解析的第一个步骤与字段解析一样,也需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用,如果解析成功,我们依然用C表示这个类,接下来虚拟机将按照如下步骤进行后续的类方法搜索

    • 类方法和接口方法符号引用的常量类型定义是分开的,如果在类方法表中发现class_index中索引的C是个接口,那就直接抛出java.lang.IncompatibleClassChangeError异常.
    • 如果通过了第一步,在类C中查找是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束
    • 否则,在类C的父类中递归查找是否有简单名称和描述符都与目标匹配的方法,如果有则返回这个方法的直接引用,查找结束.
    • 否则,在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法,如果存在匹配的方法,说明类C是一个父类,这时查找结束,抛出java.lang.AbstractMethodError异常
    • 否则,宣告方法查找失败,抛出java.lang.NoSuchMethodError
  • 接口方法解析:先解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用,如果解析成功,依然用C表示这个接口,接下来虚拟机将会按照如下步骤进行后续的接口方法搜索

    • 与类方法解析不同,如果在接口方法表中发现class_index中的索引C是个类而不是接口,那就直接抛出java.lang.IncompatibleClassChangeError异常
    • 否则,在接口C中查找是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束
    • 否则,在接口C的父接口中递归查找,直到java.lang.Object为止,看是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束
    • 否则,宣告方法查找失败,抛出java.lang.NoSuchMethodError异常.

7.装载约束

对于一个类型指向另一个类型的符号引用,如果引用的类型和被引用类型并非由同一个初始加载器加载(可能通过用户自定
义ClassLoader来实现),那么虚拟机就必须确保被引用类型在不同的命名空间中保持一致。这样就通过自定义ClassLoader来加载不受信类
型后,就不会发生解析对被引用类型的符号引用时,把受信的类型当做已经被解析过的不受信类型(因为对方法的符号引用只有权限定名和描述符,并不会也无法得
知其初始类加载器),从而调用了不受信类型的方法访问受信类型的受保护成员。

图片 4

类的加载

需要做什么?

  • 1.通过一个类的全限定名来获取定义此类的二进制字节流。
  • 2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
  • 3.在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口。

加载阶段

在加载阶段,虚拟机需要完成下面的三件事:

  • 通过一个类的全限定名来获取定义此类的二进制字节流
  • 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
  • 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口

一个非数组类的加载阶段是我们开发人员可以操控的,因为加载阶段既可以使用系统提供的引导类加载器来完成,也可以由用户自定义的类加载器去完成,所以我们完全可以通过自定义类加载器来实现按照我们想要的方式加载,修改字节码等.

而对于数组类,情况就不是这样的.因为数组类本身不是通过类加载器创建的,它是由Java虚拟机直接创建的.但数组类与类加载器仍然有很密切的关系,因为数组类的元素类型最终还是要靠类加载器去创建,一个数组类(下面简称为C)的创建过程遵循下面的规则:

  • 如果数组的元素类型是引用类型,那么就递归的先加载这个引用类型,数组C将在加载该组件类型的类加载器的类名称空间上被标识.

  • 如果不是引用类型,而是基本数据类型,那么数组C就会与引导类加载器关联

  • 数组类的可见性与它的元素类型的可见性一致,如果是基本数据类型,那么默认的可见性为public

加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中,方法区中的数据存储格式由虚拟机实现自行定义,虚拟机规范未规定此区域的具体数据结构.然后在内存中实例化一个java.lang.Class类的对象,这个对象将作为程序访问方法区中的这些类型数据的外部接口.

加载阶段与连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的,加载阶段尚未完成,连接阶段可能已经开始,但这些夹在加载阶段之中进行的动作,仍然属于连接阶段的内容,这两个阶段的开始时间仍然保持着固定的先后顺序.

4.CONSTANT_InterfaceMethodRef入口解析

对接口方法的搜索就是从被解析的接口开始,向其超接口递归搜索。

类的初始化

什么时候开始?(对一个类进行主动引用。
除此以下5种情况之外,所有引用类的方式都不会触发初始化,称为被动引用。 )

  • 遇到new、 getstatic、
    putstatic或invokestatic这4条字节码指令时,如果类没有进行过初始化,则需要先触发其初始化。

    • 使用new关键字实例化对象的时候、
      读取或设置一个类的静态字段(被final修饰
      已在编译期把结果放入常量池的静态字段除外)的时候,以及调用一个类的静态方法的时候
  • 使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发其初始化。
  • 当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
  • 当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的那个类),虚拟机会先初始化这个主类。
  • 当使用JDK
    1.7的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、
    REF_putStatic、
    REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。

验证阶段

我们上面也提到了,可以通过自定义类加载器的方式,来改写字节码,那么万一有不怀好意的人在其中加入了攻击代码怎么办?

所以,我们需要这样一个验证阶段,保证字节码是没有问题的.

验证阶段又分为下面的几个阶段:

  • 文件格式验证
  • 元数据验证
  • 字节码验证
  • 符号引用验证

文件格式验证是验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理.

文件格式验证的部分内容是:

  • 是否以魔数0xCAFEBASE开头
  • 主次版本号是否在当前虚拟机处理范围之内
  • 常量池的常量中是否有不被支持的常量类型
  • 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
  • CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据
  • Class文件中各个部分及文件本身是否有被删除的或附加的其他信息

文件格式验证是基于二进制字节流进行的,只有通过了这个阶段的验证后,字节流才会进入内存的方法区进行存储.后面的三个验证阶段全部是基于方法区的存储结构进行的,不会再直接操作字节流.

元数据验证是对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求,这个阶段可能包括的验证点如下:

  • 这个类是否有父类(除了java.lang.Object之外,所有的类都应当有父类)
  • 这个类的父类是否继承了不允许被继承的类(被final修饰的类)
  • 如果这个类不是抽象类,是否实现了其父类或接口之后在那个要求实现的所有方法
  • 类中的字段,方法是否与父类产生矛盾(例如覆盖了弗雷德final字段,或者出现不符合规则的方法重载,例如方法参数都一致,但返回值参数却不等同)

第二阶段的主要目的是对类的元数据信息进行语义校验,保证不存在不符合Java语言规范的元数据信息.

字节码验证将对类的方法体进行校验分析,保证被校验类的方法在运行时不会做出危害虚拟机安全的事件,例如:

  • 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作,例如不会出现类似这种情况:在操作数栈中放置了一个int类型的数据,使用时却按long类型来加载入本地变量表中.
  • 保证方法跳转指令不会跳转到方法体以外的字节码指令上
  • 保证方法体中的类型转换是有效的,例如可以把一个子类对象赋值给父类数据类型,这是安全的,但是不能把父类对象赋值给子类数据类型,甚至把对象赋值给与它毫无继承关系,完全不相干的一个数据类型,则是危险和不合法的.

但是,即使一个方法通过了字节码验证,也不能百分百保证这个方法就是安全的.

符号引用验证发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接的第三阶段-解析阶段中发生.符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性验证,通常需要校验下列内容:

  • 符号引用中通过字符串描述的全限定名是否能找到对应的类
  • 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
  • 符号引用中的类,字段,方法的访问性是否可被当前类访问

符号引用验证的目的是确保解析动作能正常执行,如果无法通过符号引用验证,那么将会抛出一个java.lang.IncompatibleClassChangeError异常的子类,如java.lang.IllegalAccessError,
java.lang.NoSuchFieldError, java.lang.NoSuchMethodError
等.

对于虚拟机的类加载机制来说,验证阶段是一个非常重要的,但不是一定必要的阶段.如果所运行的全部代码都已经被反复使用和验证过,那么实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施,以缩短虚拟机类加载的时间.

解析

将常量池内的符号引用替换为直接引用的过程

  • 符号引用(Symbolic
    References):符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。**
    符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中**。
    各种虚拟机实现的内存布局可以各不相同,但是它们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。

    • 方法区中存放字面量和符号引用。符号引用包括类和接口的全限定名、字段的名称和描述符,方法的名称和描述符
  • 直接引用(Direct References):直接引用可以是直接指向目标的指针、
    相对偏移量或是一个能间接定位到目标的句柄。
    直接引用是和虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。
    如果有了直接引用,那引用的目标必定已经在内存中存在
  • 除invokedynamic指令以外,虚拟机实现可以对第一次解析的结果进行缓存(在运行时常量池中记录直接引用,并把常量标识为已解析状态)从而避免解析动作重复进行。
  • 解析包括以下几种:
    • 1.类或接口的解析
      • 1)如果C(类或接口)不是一个数组类型,那虚拟机将会把代表N(未解析过的符号引用)的全限定名传递给D(当前代码所处的类)的类加载器去加载这个类C。
        在加载过程中,由于元数据验证、
        字节码验证的需要,又可能触发其他相关类的加载动作,例如加载这个类的父类或实现的接口。
        一旦这个加载过程出现了任何异常,解析过程就宣告失败。
      • 2)如果C是一个数组类型,并且数组的元素类型为对象,也就是N的描述符会是类似“[Ljava/lang/Integer”的形式,那将会按照第1点的规则加载数组元素类型。
        如果N的描述符如前面所假设的形式,需要加载的元素类型就是“java.lang.Integer”,接着由虚拟机生成一个代表此数组维度和元素的数组对象
      • 3)如果上面的步骤没有出现任何异常,那么C在虚拟机中实际上已经成为一个有效的类或接口了,但在解析完成之前还要进行符号引用验证,确认D是否具备对C的访问权限。
        如果发现不具备访问权限,将抛出java.lang.IllegalAccessError异常。
    • 2.字段解析
      要解析一个未被解析过的字段符号引用,首先将会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析,也就是字段所属的类或接口的符号引用。如果解析成功完成,那将这个字段所属的类或接口用C表示,虚拟机规范要求按照如下步骤对C进行后续字段的搜索

      • 1)如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束
      • 2)否则,如果在C中实现了接口,将会按照继承关系从下往上递归搜索各个接口和它的父接口,如果接口中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
      • 3)否则,如果C不是java.lang.Object的话,将会按照继承关系从下往上递归搜索其父类,如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段,则返回这个字段的直接引用,查找结束。
      • 4)否则,查找失败,抛出java.lang.NoSuchFieldError异常。

如果查找过程成功返回了引用,将会对这个字段进行权限验证,如果发现不具备对字段的访问权限,将抛出java.lang.IllegalAccessError异常。

  • 3.类方法解析
    需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用,如果解析成功,我们依然用C表示这个类,接下来虚拟机将会按照如下步骤进行后续的类方法搜索

    • 1)类方法和接口方法符号引用的常量类型定义是分开的,如果在类方法表中发现class_index中索引的C是个接口,那就直接抛java.lang.IncompatibleClassChangeError异常。
    • 2)如果通过了第1步,在类C中查找是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束。
    • 3)否则,在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束。
    • 4)否则,在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法,如果存在匹配的方法,说明类C是一个抽象类,这时查找结束,抛出java.lang.AbstractMethodError异常。
    • 5)否则,宣告方法查找失败,抛出java.lang.NoSuchMethodError。

最后,如果查找过程成功返回了直接引用,将会对这个方法进行权限验证,如果发现不
具备对此方法的访问权限,将抛出java.lang.IllegalAccessError异常。

  • 4.接口方法解析
    接口方法也需要先解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用,如果解析成功,依然用C表示这个接口,接下来虚拟机将会按照如下步骤进行后续的接口方法搜索。

    • 1)与类方法解析不同,如果在接口方法表中发现class_index中的索引C是个类而不是接口,那就直接抛出java.lang.IncompatibleClassChangeError异常。
    • 2)否则,在接口C中查找是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束。
    • 3)否则,在接口C的父接口中递归查找,直到java.lang.Object类(查找范围会包括Object类)为止,看是否有简单名称和描述符都与目标相匹配的方法,如果有则返回这个方法的直接引用,查找结束。
    • 4)否则,宣告方法查找失败,抛出java.lang.NoSuchMethodError异常。

由于接口中的所有方法默认都是public的,所以不存在访问权限的问题,因此接口方法的符号解析应当不会抛出java.lang.IllegalAccessError异常。

准备阶段

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中分配.

注意这个阶段分配的变量仅是类变量,不包括实例变量.实例变量会在对象实例化时随着对象一起在堆中分配.

另外,这里说的初始值,一般是对应的数据类型的零值.假设一个类变量的定义为:

public static int value = 123;

准备阶段value将会被初始化为int对应的零值0.而把value赋值为123的动作将在初始化阶段才会执行.

在通常情况下会被初始化为零值,当然也有特殊情况:如果类字段的字段属性表中存在ConstantValue属性,那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值,假设上面类变量value的定义为:

public static final int value = 123;

编译时Javac将会为value生成ConstantValue属性值,在准备阶段虚拟机就会根据ConstantValue的设置将value赋值给123.

双亲委派模型机制

双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器。
这里类加载器之间的父子关系一般不会以继(Inheritance)的关系来实现,而是都使用组合(Composition)关系来复用父加载器的代码。

如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。

类加载器

对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立骑在Java虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间.比较两个类是否相等,只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类来源于同一个Class文件,被同一个虚拟机加载,只要加载它们的类加载器不同,那这两个类就必定不相等.

初始化

初始化阶段是执行类构造器<clinit>()方法的过程。

  • <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作静态语句块(static{}块)中的语句****合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块可以赋值,但是不能访问

不需要显式地调用父类构造器,虚拟机会保证在子类的<clinit>()方法执行之前,父类的<clinit>()方法已经执行完毕
因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。

由于父类的<clinit>()方法先执行,也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作

如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成<clinit>()方法。

执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法
只有当父接口中定义的变量使用时,父接口才会初始化。

如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的<clinit>()方法

双亲委派模型

从Java虚拟机的角度来讲,只存在两种不同的类加载器:启动类加载器和所有其他类的加载器

  • 启动类加载器:使用C++语言实现,是虚拟机自身的一部分
  • 所有其他类的加载器:由Java语言实现,独立于虚拟机外部,并且全都继承自抽象类java.lang.ClassLoader。
    • 扩展类加载器:由sun.misc.Launcher$ExtClassLoader实现,它负责加载<JAVA_HOME>libext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。
    • 应用程序类加载器:由sun.misc.Launcher $AppClassLoader实现。
      由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也称它为系统类加载器。
      它负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

图片 5

图2 类加载器双亲委派模型

类的验证

目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。包括四种:

  • 文件格式验证:验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。

    • 是否以魔数0xCAFEBABE开头。
    • 主、 次版本号是否在当前虚拟机处理范围之内。
    • 常量池的常量中是否有不被支持的常量类型(检查常量tag标志)。
    • 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
    • CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据。
    • Class文件中各个部分及文件本身是否有被删除的或附加的其他信息
    • ……
  • 该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内,格式上符合描述一个Java类型信息的要求。
    这阶段的验证是基于二进制字节流进行的,只有通过了这个阶段的验证后,字节流才会进入内存的方法区中进行存储,所以后面的3个验证阶段全部是基于方法区的存储结构进行的,不会再直接操作字节流

  • 元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求

    • 这个类是否有父类(除了java.lang.Object之外,所有的类都应当有父类)。
    • 这个类的父类是否继承了不允许被继承的类(被final修饰的类)。
    • 如果这个类不是抽象类,是否实现了其父类或接口之中要求实现的所有方法。
    • 类中的字段、
      方法是否与父类产生矛盾(例如覆盖了父类的final字段,或者出现不符合规则的方法重载,例如方法参数都一致,但返回值类型却不同等)。
    • ……
  • 字节码验证:通过数据流和控制流分析,确定程序语义是合法的、
    符合逻辑的。

  • 符号引用验证:确保解析动作能正常执行,如果无法通过符号引用验证,那么将会抛出一个java.lang.IncompatibleClassChangeError异常的子类

发表评论

电子邮件地址不会被公开。 必填项已用*标注