JVM-类加载机制

Posted 小凉

tags:

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

虚拟机类加载机制 

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

 类加载的时机

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

  虚拟机规范严格规定了有且仅有5种情况必须立即对类进行“初始化”:

  1. 遇到new , getstatic , putstatic 或involvestatic这4条字节码指令时,如果类没有进行过初始化,则需要先触发其初始化。
  2. 使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发其初始化。
  3. 当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
  4. 当虚拟机启动时,用户需要指定一个要执行的主类(包含main方法的类),虚拟机会先初始化这个类。
  5. 当使用JDK1.7的动态语言支持时,如果java.lang.invoke.MethodHeadle实例,最后的解析结果REF_getstatic , REF_putstatic , REF_invokestatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。

 类加载的过程

  一、加载

  (1)在加载阶段,虚拟机需要完成以下3件事:

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

  (2)数组类本身不通过类加载器创建,他是由Java虚拟机直接创建的。

    一个数组类创建过程遵循以下规则:

  1. 如果数组的组件类型(Component Type , 指的是数组去掉一个维度的类型)是引用类型,那就递归采用上面介绍的加载过程去加载这个组件类型,数组将在加载该数组组件类型的类加载器的类名称空间上呗标识。
  2. 如果数组的组件类型不是7引用类型,Java虚拟机将会把数组标记为与引导类加载器关联。
  3. 数组类的可见性与它的组件类型的可见性一致,如果组件类型不是引用类型,需要数组类的可见性将 默认为public

 

  二、验证

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

  验证阶段大致上会完成以下4个阶段的检验动作:文件格式验证、元数据验证、字节码验证、符号引用验证

  (1 ) 文件格式验证

  1. 第一阶段要验证字节流是否符合class文件格式的规范,并且能被当前版本的虚拟机处理。
  2. 中油通过了这个阶段的验证后,字节流才会进入内存的方法区中进行存储,所以后面的3个验证阶段全部是基于方法区的存储结构进行的,不会直接操作字节码。

 (2 ) 元数据验证

  1. 第二阶段是对字节码描述的信息进行语义分析,以确保其描述的信息符合Java语言规范的要求。
  2. 第二阶段的主要目的是对类的元数据信息进行语义化验,保证不存在不符合Java语言规范的元数据信息

  (3 ) 字节码验证

  1. 督三阶段是整个验证过程中最复杂的一个阶段,主要目的是通过数据流和控制流分析,确定程序语义是合法的,符合逻辑的。这个阶段将对类的方法体进行校验分析。保证被校验类的方法运行时不会做出危害虚拟机安全的时间。
  2. 例如:保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。保证跳转到方法体以外的字节码指令上。

  (4 ) 符号引用验证

  1. 最后一个验证阶段的检验发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在连接阶段的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外的信息进行匹配性校验。
  2. 例如:符号引用中通过字符串描述中的全限定名是否能找到对应的类。在特定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
  3. 符号引用验证的目的是确定解析动作能正常执行,如果无法通过符号引用验证,那么将会抛出java.lang.IncompatibleClassChangeError异常的子类

  

 三、准备

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

 

  四、解析

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

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

  (2)虚拟机规范中并未规定解析阶段发生的具体时间,只要求了执行anewarray,checkcast,getfield,getstatic,instanceof,invokedynamic,invokeinterface,invokespecial,invokestatic,invokevirtual,ldc,ldc_w,multianewarray,new,putField和putstatic这16个用于操作符号引用的字节码指令之前,先过它们所使用的符号引用进行解析。

  (3)解析动作主要针对类或接口,字段,类方法,接口方法,方法类型,方法句柄和调用点限定符7类符号引用进行。

  (4)类或接口的解析

    虚拟机完成整个解析的过程需要以下3个步骤

    1)如果c不是一个数组类型,那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中,由于元数据验证,字节码验证的需要,又可能触发其他相关的类的加载动作。

    2)如果C是一个数组类型,并且数组的元素类型为对象,那将会按以上的规则加载数组类型。如果N的描述符如前面所假设的形式,需要加载元素的类型,接着由虚拟机生成一个代表此数组维度和元素的数组对象。

    3)如果上面的步骤没有出现任何异常,那么C在虚拟机中实际上已经成为一个有效的类或接口了,但在解析完成之后还要进行符号引用验证,确认D是否是具备对C的访问权限。

  (5)字段解析

  (6)类方法解析

  (7)接口方法解析

 

  五、初始化

  1. 类初始化阶段是类加载过程的最后一步
  2. 在准备阶段,变量已经赋过一次系统要过的初始值,而在初始化阶段,则根据程序员制定的主观去初始化变量和其他资源,或者可以从另外一个角度来表达:初始化阶段是执行类构造器<cninit>()方法的过程。
  3. <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块可以赋值,但是不能访问。
  4. <clinit>()方法与类的构造函数不同,它不需要显式地调用父类构造器,虚拟机会保证在子类的<clinit>()方法执行之前,父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定有java.lang.object。
  5. 由父类的<clinit>()方法先执行,也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
  6. <clinit>()方法对于类或接口来说并不是必须的,如果一个类中没有静态语句块,也没有对变量的赋值操作,那么编译器可以不为这个类生成<clinit>()方法
  7. 虚拟机会保证一个类的<clinit>()方法在多个线程环境中正确地加锁,同步。

  

 类加载器

  一、类与类加载器

  对于任意一个类,需要由加载它的加载器和这个类本身一同确立其在Java虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间。

  二、双亲委派模型

  (1)从Java虚拟机的角度来讲,只存在两种不同的类加载器:一种是启动类加载器(Bootstrap Class ClassLoader),这个类加载器使用C++语言实现是Java虚拟机自动的一部分;另一种就是所有其他的类加载器,这些类加载器都由Java语言实现,独立于虚拟机外部,并且全都是继承自抽象类java.lang.classLoader.

  (2)细分:启动类加载器(Bootstrap ClassLoader)

        扩展类加载器(Extension ClassLoadert

           应用程序类加载器(Application ClassLoader)[系统类加载器]

  (3)双亲委派模型工作过程:

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

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

JVM类加载机制讲解

JVM第六卷---类加载机制

双亲委派机制JVM:类加载机制深度剖析 - 第7篇

java类加载机制简介---JVM

JVM类加载机制

深入JVM类加载机制