JVM学习笔记——虚拟机类加载机制

Posted ty_laurel

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JVM学习笔记——虚拟机类加载机制相关的知识,希望对你有一定的参考价值。

概述

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

类的生命周期

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


类加载的时机(什么时候开始类加载?)

Java虚拟机规范中并没有进行强制约束,这点可以可以交给虚拟机的具体实现来自由把握。初始化阶段虚拟机规范严格规定有且只有5中情况必须立即对类进行“初始化”(而加载、验证、准备自然需要在此之前开始):

  • 1.遇到new、getstatic、putstatic和invokestatic这4条字节码指令时,若类没有进行过初始化,则需要先触发其初始化。生成这4条指令最常见的Java代码场景是:使用new关键字实例化对象的时候、读取或设置一个类的静态字段(被final修饰、已在编译期把结果放入常量池的静态字段除外)的时候,以及调用一个类的静态方法的时候;
  • 2.使用java.lang.reflect包的方法对类进行反射调用的时候,若类没有进行初始化,则需要先触发其初始化;
  • 3.当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化;
  • 4.当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的那个类),虚拟机会先初始化这个主类;
  • 5.当使用JDK1.7的动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果是REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。

以上五种是会触发初始化的场景,这几种场景称为对一个类进行主动引用。有主动必然有被动,那什么情况下称为被动引用呢?除了以上五种场景以外的其他所有引用类的方式都不会触发初始化,就是被动引用。接下来看几个程序类理解下被动引用。

 
  
   package javaclass.loading;
  
  
   class SuperClass 
  
  
       static 
  
  
           System.out.println("SuperClass init!");
  
  
       
  
  
       public static int value = 369;
  
  
   
  
  
   class SubClass extends SuperClass 
  
  
       static 
  
  
           System.out.println("SubClass init!");
  
  
       
  
  
   
  
  
   class ConstClass 
  
  
       static 
  
  
           System.out.println("ConstClass init!");
  
  
       
  
  
       public static final String HELLOWORLD="hello world";
  
  
   
  
  
    
  
  
   public class NotInitialization 
  
  
       public static void main(String[] args) 
  
  
           System.out.println(SubClass.value);
  
  
         
  
 

程序运行后输出:

 
  
   SuperClass init!
  
  
   369  
  
 

只会输出“SuperClass init!”,而不会输出“SubClass init!”。对于静态字段,只有直接定义这个字段的类才会被初始化,因此通过其子类来引用父类中定义的静态字段,只会触发父类的初始化而不会触发子类的初始化。至于是否触发子类的加载和验证,在虚拟机规范中并未明确规定,这点取决于虚拟机的具体实现。对于HotSpot虚拟机,可以使用-XX:+TraceClassLoading参数来观察程序类加载情况。

修改类NotInitialization的main方法,如下

 
  
   //通过数组定义来引用类,不会触发此类的初始化
  
  
   public static void main(String[] args) 
  
  
           SuperClass[] sca = new SuperClass[10];
  
  
   
  
 

此时运行程序,没有任何输出(未输出”SuperClass init!”)。Java中对数组的访问比C/C++相对安全是因为这个类封装了数组元素的访问方法(准确的说,越界检查不是封装在数组元素访问的类中,而是封装在数组访问的xaload、xastore字节码指令中),Java数组越界会抛出java.lang.ArrayIndexOutOfBoundsException异常。

继续修改main方法如下:

 
  
   //常量在编译阶段会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的初始化
  
  
   public static void main(String[] args) 
  
  
           System.out.println(ConstClass.HELLOWORLD);
  
  
     
  
 

输出:

 
  
   hello world 
  
 

代码运行没有输出“ConstClass init!”,只是输出了“hello world”,这是因为虽然在Java源码中引用了ConstClass类中的常量HELLOWORLD,但其实在编译阶段通过常量传播优化,已经将此常量的值“hello world”存储到了常量池中,以后对ConstClass.HELLOWORLD的引用实际都被转化为了对常量池的引用。

类加载过程

Java虚拟机中磊加载的全过程,就是加载、验证、准备、解析和初始化5个阶段所执行的具体动作。

加载过程

在“类加载”(Class Loading)过程中的“加载”阶段,虚拟机需要完成以下3件事情:

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

         数组类本身不通过类加载器创建,而是由Java虚拟机直接创建的。但数组类与类加载器仍然有着很密切的关系,因为数组类的元素类型(Element Type,指的是数组去掉所有维度的类型)最终是要靠类加载器去创建。加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中,方法区中的数据存储格式由虚拟机自行定义。然后在内存中实例化一个java.lang.Class类的对象(并没有明确规定在Java堆中,对于HotSpot虚拟机而言,Class对象比较特殊,虽然是对象,但是存放在方法区里面),该对象将作为程序访问方法区中的这些类型数据的外部接口。

验证阶段

       验证是连接阶段的第一步,目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。Class文件并不要求用Java源码编译而来,可使用任何途径产生;在字节码语言层面上,Java代码无法做到的事情都是可以通过其他途径表达出来的。虚拟机若不检查输入的字节流,对齐完全信任,可能会因为载入了有害的字节流而导致系统崩溃,导致Java虚拟机受到恶意代码的攻击,所以验证是虚拟机对自身保护的一项重要工作。 
从整体看,验证阶段大致有4个阶段的检验动作:

  • 文件格式验证:验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理(如:是否以魔数0xCAFEBABE开头);
  • 元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求,可能的验证点有: 
    该类是否有父类(除了java.lang.Object之外,所有类都应当有父类)、该类的父类是否继承了不允许被继承的类(被final修饰的类)、若该类不是抽象类是否实现了其父类或接口之中要求实现的所有方法等;
  • 字节码验证:验证过程中最复杂的一个阶段,主要目的是通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验后,这个阶段将对类的方法体进行校验,保证被校验类的方法在运行时不会做出危害虚拟机安全的事件,如:保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作,不会出现:在操作栈放置了一个int类型的数据,使用时却按long类型来加载入本地变量表中。
  • 符号引用验证:该阶段发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验,通常需要校验内容有: 
    在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段;符号引用中的类、字段、方法的访问性(private、protected、public、default)是否可被当前类访问。

准备阶段

       准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配。需要强调的是此时内存分配仅包括类变量(被static修饰的变量),而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在Java堆中,并且此时的初始值“通常情况”是数据类型的零值,如: 
   public static int value = 369;

则变量value在准备阶段过后的初始值为0而不是369,因为这时候尚未开始执行任何Java方法,而把value赋值为369的putstatic指令是程序被编译后,存放于类构造器()方法之中,所以把value赋值为369的动作是在初始化阶段才会执行的。 
 
上边刚说的“通常情况”下初始值是零值,那么“特殊情况”又是怎么样的呢?若类字段属性表中存在ConstantValue属性(详见我的另一篇博客),则在准备阶段变量value就会被初始化为ConstantValue属性所指值,如: 


   public static final int value = 369; 
编译时Javac将会为value生成ConstantValue属性,在准备阶段就会根据ConstantValue属性将value直接赋值为369.

解析阶段

        解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程,符号引用在Class文件中以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现,那解析阶段中所说的符号引用与直接引用又有什么关联呢?

  • 符号引用(Symbolic References): 符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同,但是他们能接受的符号引用必须都是一致的,因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
  • 直接引用(Direct References):直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在内存中存在。

初始化阶段

      类初始化阶段是类加载过程的最后一步,前边的类加载过程中,除了在加载阶段用户应用程序可以通过自定义类加载器参与之外,其余动作完全有虚拟机主导和控制。到了初始化阶段,才真正开始执行类中定义的Java程序代码(或者说是字节码)。 
       在准备阶段,变量已经赋过一次系统要求的初始值,而在初始化阶端,则根据程序员通过程序制定的主观计划去初始化类变量和其他资源,或者可以从另外一个角度来表达:初始化阶段是执行类构造器()方法的过程。


以上是关于JVM学习笔记——虚拟机类加载机制的主要内容,如果未能解决你的问题,请参考以下文章

深入理解JVM学习笔记——-7虚拟机类加载机制★

jvm笔记5--虚拟机类加载机制

深入理解JVM读书笔记三: 虚拟机类加载机制

Jvm(56),虚拟机类加载机制----类加载的过程----初始化

Jvm(54),虚拟机类加载机制----类加载的过程----准备

深入理解Java虚拟机- 学习笔记 - 虚拟机类加载机制