jvm系列前端
本文主要讲述Java类的加载机制,主要包括类加载器、加载过程、初始化时机。
类加载器的任务就是根据一个类的全限定名来读取此类的二进制字节流到JVM内部,而后转换为一个与目标类对应的java.lang.Class对象实例。
若是须要支持类的动态加载或须要对编译后的字节码文件进行解密操做等,就须要与类加载器打交道了。
BootstrapClassLoader,由C++编写嵌套在JVM内部,负责加载“JAVA_HOME/lib”目录中的全部类型,或者由“-Xbootclasspath”指定路径中的全部类型。
ExtClassLoader和AppClassLoader都继承至ClassLoader抽象类,由Java编写。
ExtClassLoader负责加载“JAVA_HOME/lib/ext”目录下的全部类型。
AppClassLoader负责加载ClassPath目录中的全部类型。
defineClass方法将字节码的byte数组转换为一个类的Class对象实例,若是但愿在类被加载到JVM内部时就被连接,那么能够调用resolveClass方法。
Parents Delegation Model,双亲委派模型,约定类加载器的加载机制。
当一个类加载器接收到一个类加载的任务时,不会当即展开加载,而是将加载任务委派给它的超类加载器去执行,每一层的类都采用相同的方式,直至委派给最顶层的启动类加载器为止。若是超类加载器没法加载委派给它的类,便将类的加载任务退回给下一级类加载器去执行加载。
双亲委派模型的工做过程是:若是一个类加载器收到了类加载的请求,它首先不会本身去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每个层次的类加载器都是如此,所以全部的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈本身没法完成这个加载请求(它的搜索范围中没有找到所需的类)时,子加载器才会尝试本身去加载。
使用这种方式的好处是:可以有效确保一个类的全局惟一性,当程序中出现多个全限定名相同的类时,类加载器在执行加载时,始终只会加载其中的某一个类。
使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是Java类随着它的类加载器一块儿具有了一种带有优先级的层次关系。例如类java.lang.Object,它存放在rt.jar之中,不管哪个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,所以Object类在程序的各类类加载器环境中都是同一个类。相反,若是没有使用双亲委派模型,由各个类加载器自行去加载的话,若是用户本身编写了一个称为java.lang.Object的类,并放在程序的Class-Path中,那系统中将会出现多个不一样的Object类,Java类型体系中最基础的行为也就没法保证,应用程序也将会变得一片混乱。若是本身去编写一个与rt.jar类库中已有类重名的Java类,将会发现能够正常编译,但永远没法被加载运行。
双亲委派模型对于保证Java程序的稳定运做很重要,但它的实现却很是简单,实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中,逻辑清晰易懂:先检查是否已经被加载过,若没有加载则调用父加载器的loadClass()方法,若父加载器为空则默认使用启动类加载器做为父加载器。若是父类加载失败,抛出ClassNotFoundException异常后,再调用本身的findClass()方法进行加载。
双亲委派机制只是Java虚拟机规范建议采用的加载机制,实际在tomcat中,类加载器所采用的加载机制与传统的双亲委派模型有必定的区别,当缺省的类加载器接收到一个类的加载任务时,首先会去由它自行加载,当它加载失败时,才会将类的加载任务委派给它的超类加载器去执行。
程序中若是没有显式指定类加载器的话,默认是AppClassLoader来加载,它负责加载ClassPath目录中的全部类型,若是被加载的类型并无在ClassPath目录中时,抛出java.lang.ClassNotFoundException异常。
通常是继承ClassLoader,若是要符合双亲委派规范,则重写findClass方法;要破坏的话,重写loadClass方法。
双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现以前——即JDK 1.2发布以前。因为双亲委派模型在JDK 1.2以后才被引入,而类加载器和抽象类java.lang.ClassLoader则在JDK1.0时代就已经存在,面对已经存在的用户自定义类加载器的实现代码,Java设计者引入双亲委派模型时不得不作出一些妥协。
为了向前兼容,JDK 1.2以后的java.lang.ClassLoader添加了一个新的protected方法findClass(),在此以前,用户去继承java.lang.ClassLoader的惟一目的就是为了重写loadClass()方法,由于虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal(),而这个方法的惟一逻辑就是去调用本身的load-Class()。
上一节咱们已经看过loadClass()方法的代码,双亲委派的具体逻辑就实如今这个方法之中,JDK1.2以后已不提倡用户再去覆盖loadClass()方法,而应当把本身的类加载逻辑写到findClass()方法中,在loadClass()方法的逻辑里若是父类加载失败,则会调用本身的findClass()方法来完成加载,这样就能够保证新写出来的类加载器是符合双亲委派规则的。
一个完整的类加载过程必须经历加载、链接、初始化这三个步骤:
简单的说,类加载阶段就是由类加载器负责根据一个类的全限定名来读取此类的二进制字节流到JVM内部,并存储在运行时内存区的方法区,而后将其转换为一个与目标类型对应的java.lang.Class对象实例(Java虚拟机规范并无明确要求必定要存储在堆区中,只是hotspot选择将Class对象存储在方法区中),这个Class对象在往后就会做为方法区中该类的各类数据的访问入口。
链接阶段要作的是将加载到JVM中的二进制字节流的类数据信息合并到JVM的运行时状态中,经由验证、准备、解析三个阶段。
(1)验证阶段
验证类数据信息是否符合JVM规范,是不是一个有效的字节码文件,验证内容涵盖了类数据信息的格式验证、语义分析、操做验证等
格式验证:验证是否符合class文件规范,好比以0xCAFEBABE开头,大小版本号等
语义验证:
a、检查一个被标记为final的类型是否包含派生类
b、检查一个类中的final方法是否被派生类进行重写
c、确保超类与派生类之间没有不兼容的一些方法声明(好比方法签名相同,但方法的返回值不一样)
操做验证:
在操做数栈中的数据必须进行正确的操做,对常量池中的各类符号引用执行验证(一般在解析阶段执行,检查是否能经过符号引用中描述的全限定名定位到指定类型上,以及类成员信息的访问修饰符是否容许访问等)。
(2)准备阶段
为类中的全部静态变量分配内存空间,并为其设置一个初始值(因为尚未产生对象,实例变量将再也不此操做范围内)
(3)解析阶段
将常量池中全部的符号引用转为直接引用(获得类或者字段、方法在内存中的指针或者偏移量,以便直接调用该方法)。这个阶段能够在初始化以后再执行。
将一个类中全部被static关键字标识的代码统一执行一遍,若是执行的是静态变量,那么就会使用用户指定的值覆盖以前在准备阶段设置的初始值;若是执行的是static代码块,那么在初始化阶段,JVM就会执行static代码块中定义的全部操做。
全部类变量初始化语句和静态代码块都会在编译时被前端编译器放在收集器里头,存放到一个特殊的方法中,这个方法就是<clinit>方法,即类/接口初始化方法。该方法的做用就是初始化一个类中的变量,使用用户指定的值覆盖以前在准备阶段设定的初始值。任何invoke之类的字节码都没法调用<clinit>方法,由于该方法只能在类加载的过程当中由JVM调用。
若是超类尚未被初始化,那么优先对超类初始化,但在<clinit>方法内部不会显示调用超类的<clinit>方法,由JVM负责保证一个类的<clinit>方法执行以前,它的超类<clinit>方法已经被执行。
JVM必须确保一个类在初始化的过程当中,若是是多线程须要同时初始化它,仅仅只能容许其中一个线程对其执行初始化操做,其他线程必须等待,只有在活动线程执行完对类的初始化操做以后,才会通知正在等待的其余线程。
只有那些须要执行java代码来为类变量执行赋值操做的类型在编译以后才会在字节码中存在生成的<clinit>方法。若是一个类并无声明任何的类变量,也没有静态代码块,那么这个类在编译为字节码后,字节码文件中将不会包含<clinit>方法;一样若是一个类声明类变量,但没有明确使用类变量的初始化语句以及静态代码块来执行初始化操做,编译后的字节码中也不会有<clinit>方法;只有final的静态变量也不会有该方法。
(1)为一个类型建立一个新的对象实例时(好比new、反射、序列化)
(2)调用一个类型的静态方法时(即在字节码中执行invokestatic指令)
(3)调用一个类型或接口的静态字段,或者对这些静态字段执行赋值操做时(即在字节码中,执行getstatic或者putstatic指令),不过用final修饰的静态字段除外,它被初始化为一个编译时常量表达式
(4)调用JavaAPI中的反射方法时(好比调用java.lang.Class中的方法,或者java.lang.reflect包中其余类的方法)
(5)初始化一个类的派生类时(Java虚拟机规范明确要求初始化一个类时,它的超类必须提早完成初始化操做,接口例外)
(6)JVM启动包含main方法的启动类时。
数组自己并非由类加载器负责建立,而是由JVM在运行时根据须要而直接建立的,但数组的元素类型仍然须要依靠类加载器去建立。