类加载机制

1.什么是类加载

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

      与那些在编译时需要进行连接工作的语言不同,在 java 语言中,类型的加载,连接和初始化过程都是在程序运行期间完成的,这种策 略虽然会令类加载时稍微增加一些性能开销,但是会为 java 应用程序提供高度的灵活性,java 里,天生可以动态扩展的语言特性就是依赖 运行时期动态加载和动态连接的这个特点实现的.

       类从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括:加载(loading),验证(verification),准备(preparation), 解析(resolution),初始化(initialization),使用(using),卸载(unloading)七个阶段.其中,验证,准备,解析三个部分统称为连接(linking).

注意:加载,验证,准备,初始化和卸载这五个阶段的顺序是确定的,但是解析阶段则不一定.它在某些情况下可以在初始化阶段之后再 开始.主要是为了支持 java 语言的运行时绑定.

2.初始化时机

       什么情况下开始类加载过程的第一个阶段:加载?

        java 虚拟机规范中并没有进行强制约束.这点可以交给虚拟机的具体实现来自有 把握.但是对于初始化阶段,虚拟机规范则严格规定了有且只有五种情况必须立即对类进行"初始化"(加载,验证,准备自然需要在初始化 之前开始).

        1.遇到 new 指令(使用关键字 new 来实例化对象),getstatic,putstatic(读取或设置一个类的静态字段的时候,除了 final 修饰,在编 译时期就已经把结果放在常量池的静态字段)或 invokestatic(调用类的静态方法)这 4 条字节码指令时,如果类没有进行初始化,则需要先 触发其初始化.

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

         3.当初始化一个类的时候,如果发现其父类还没有进行初始化,则需要先触发其父类的初始化(接口初始化例外,不要求所有父接口 全部都初始化,只有在真正调用到父接口的时候才会初始化).

         4.当启动虚拟机时,用户需要指定一个需要执行的主类,虚拟机先初始化这个主类.

         5.当使用 java7 的动态语言支持时,如果一个 MethodHandle 实例在解析时,该方法对应的类没有进行初始化,则需要先触发其初始 化.

         这五种场景中的行为称之为对一个类进行主动引用.除此之外,所有引用类型的方式都不会触发初始化,叫做被动引用.
被动引用,如:
1.通过子类引用父类的静态字段,不会导致子类初始化(此时的静态资源不是属于子类父类的,底层还是使用的是 SuperClass.value

去访问的,所以只初始化 SuperClass,而不初始化 SubClass).

 2.通过数组定义来引用类,不会触发此类的初始化.

3.常量在编译阶段会存入调用类的常量池中,本质上并没有直接引用到定义常量的类,因此不会触发定义常量的类的初始化. 

 

3.类加载过程 

1 加载

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

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

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

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

注:

      虚拟机规范的这三点要求其实并不算具体,因此虚拟机实现与具体应用的灵活度都是相当大的.比如从哪里获取,如何获取二 进制字节码流,都没有严格限定.虚拟机设计团队搭建了一个相当开放的舞台.许多举足轻重的 java 技术都建立在这一基础之上.

1.从 ZIP 包中读取.(ZIP, JAR, EAR, WAR) 2.从网络中获取 3.运行时计算生成(动态代理技术) 4.由其他文件生成(JSP 应用)

...... 加载和连接的部分内容是交叉进行的.加载尚未完成,连接阶段可能已经开始,比如部分字节码文件格式的验证.

2 连接-验证

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

      如果使用纯粹的 java 代码,做到诸如将一个对象转型为它并未实现的类型,编译器将拒绝编译(编译报错).但是在前文中提到,Class 文件并不一定要求是 Java 源码编译而来的.虚拟机如果不检查输入的字节码流,对其完全信任的话,很可能会因为载入了有害的字节码 流而导致系统崩溃.

       验证阶段是非常重要的,这个阶段是否严谨,直接决定了 java 虚拟机是否能够承受恶意代码的攻击,从执行性能的角度上讲,验证阶 段的工作量在虚拟机的类加载子系统中又占了相当大的一部分.

       根据 2011 年发布的<Java 虚拟机规范(Java SE 7 版)>的要求,验证阶段大致需要下面四个阶段来验证.

 1.文件格式验证.

        验证字节流是否符合 Class 文件格式的规范,并且能被当前版本的虚拟机处理.比如,是否以魔数 0xCAFEBABE 开头(字节码头四个字节,用来表示一个可以接受的字节码文件). 主要目的是保证输入的字节流能正确的解析并存储于方法区之内,格式上符合描述一个 java 类型信息的要求.

 2.元数据验证.
        对字节码描述的信息进行语义分析,以保证其描述的信息符合 Java 语言规范的要求. 比如,是否有父类,是否继承了不允许被继承的类等等. 主要目的是对类的元数据信息进行语义校验,保证不存在不符合 java 语言规范的元数据信息.

3.字节码验证.

      在元数据验证之后,这个阶段将对类的方法体进行校验分析,保证被校验的类的方法在运行时不会做出危害虚拟机安全的事

件.目的是通过数据流和控制流分析,确定程序语义是合法的,符合逻辑的.

4.符号引用验证.

     该校验是发生在虚拟机将符号引用转化为直接引用的时候,这个转化动作将在解析阶段中发生. 比如校验符号引用中的全限定名是否能找到对应的类,是否具备访问权限等等. 目的是确保解析动作能正常执行.

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

3 连接-准备

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

      这时候进行内存分配的仅包括类变量(被 static 修饰的变量)，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分 配在 Java 堆中;并且这里所说的初始值“通常情况”是数据类型的零值，例如:public static int value = 123;value 在准备阶段过后的初始值为 0 而不是 123，而给 value 赋值的指令将在初始化阶段才会被执行."特殊情况":类字段的字段属性表中存在常量属性.那么在准备阶段就会被初始化为指定的值.例如: public static final int value = 123; 在准备阶段虚拟机就会将 value 赋值为 123.

4 连接-解析

 

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

     符号引用(Symbolic References):以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义 的定位到目标即可.符号引用与虚拟机的内存布局无关，引用的目标并不一定加载到内存中。在 Java 中，一个 java 类将会编译成一个 class 文件。在编译时，java 类并不知道所引用的类的实际地址，因此只能使用符号引用来代替.

      直接引用是和虚拟机的布局相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引 用，那引用的目标必定已经被加载入内存中了。

       虚拟机规范之中并未规定解析阶段发生的具体时间,只要求了在执行 anewarray(创建数组),checkcast(检查类型),getfield(获取字 段),getstatic(获取类变量),instanceof(检查类型),invokedynamic(动态解析方法),invokeinterface(调用接口方法),invokespecial(调 用特殊方法,比如构造方法,初始化方法),invokestatic(调用 static 方法),invokevirtual(调用实例方法),ldc/ldc_w(将 int,float,String 常 量推至栈顶),multianewarray(创建数组),new(创建对象),putfield(设置字段),putstatic(设置类变量)这 16 个用于操作符号引用的字节 码指令之前,先对它们所使用的符号引用进行解析.

5 初始化

      初始化阶段,才真正开始执行类中定义的 java 程序代码.
      初始化阶段是执行类构造器<clinit>()方法的过程.

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

2.类构造器<clinit>()方法与类的构造器<init>()方法不同,虚拟机会保证在子类的<clinit>()方法之前执行,因此,在虚拟机中第一 个被执行的<clinit>()方法的类肯定是 Object.

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

4.类构造器<clinit>()方法对于类或者接口来说并不是必需的,如果一个类中没有静态语句块,编译器就不会为这个类生成 <clinit>()方法.

5.接口中也可以定义 static 变量,生成的<clinit>()方法不需要先执行父接口中的<clinit>()方法,同理,接口的实现类在初始化的时 候也一样不会执行接口中的<clinit>()方法.

6.虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁,同步,如果多线程同时去初始化一个类,只会有一个线程去 初始化,其他线程都阻塞.

5 类加载器

       虚拟机设计团队把类加载阶段中的"通过一个类的全限定名来获取描述此类的二进制字节流"这个动作放到了 java 虚拟机外部去 实现(意思就是说,如何把字节码文件变成流的过程,不仅仅属于虚拟机中的功能).以便让应用程序自己决定如何去获取所需要的类.这个 动作的代码模块成为"类加载器".

       类加载器可以说是 java 语言的一项创新.也是 java 语言流行的重要原因之一.它在类层次划分,OSGi,热部署,代码加密等领域大放 异彩.成为 java 体系中一块重要的基石.

        类加载器虽然只用于一个类的加载动作,但是它在 java 程序中起到的作用却远远不限于类加载阶段.对于任意一个类,都需要由加 载它的类加载器和这个类本身一同确立其在 java 虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间.

5.1 类加载器分类

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

        从 java 开发人员的角度来看,类加载器还可以划分得更细致一些.

        启动类加载器(Bootstrap ClassLoader):负责将存在于<JAVA_HOME>\lib 目录中,或者配置参数-Xbootclasspath 参数指定的 路径中,并且能够被虚拟机识别(名字不符合的,就算放在了 lib 中也不会被夹在)的类库加载到虚拟机内存中.该类加载器无法被 java 程序 直接引用.

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

       应用程序类加载器(Application ClassLoader):这个加载器由 sun.misc.Launcher$AppClassLoader 实现.也称之为系统类加载 器.它负责加载用户类路径(classpath)上所指定的类库,开发者可以直接使用.一般情况下,这个就是程序中默认的类加载器.

我们程序都是由这三种类加载器互相配合进行加载的,如果有必要,还可以加入自定义的类加载器.

5.2 双亲委派模型

        对于类的加载,只需要加载进内存一次就足够了.为了避免重复加载，当父 ClassLoader 已经加载了该类的时候，就没有必要子 ClassLoader 再加载一次。这种加载器之间的层次关系,就叫做双亲委派模型(Parents Delegation Model).

        双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应该有自己的父(没有继承关系,而是使用组合关系来组织他们 的层级关系)类加载器.如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去 完成.每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,当父类加载器反馈自己不能完成 这个加载请求(自己负责的范围内没有这个类),子类加载器才会尝试自己去加载.

       双亲委派模型有一个显而易见的好处就是 java 类随着它的类加载器一起具备了一种带有优先级的层次关系.比如 java.lang.Object 类,无论是哪个类加载器接收到加载的请求,都会委派给启动类加载器去加载.因此 Object 类在程序中都是同一个类. 相反,如果没有双亲委派,任何一个类加载器收到请求都自己去加载,那么系统中将会出现多个不同的 Object 类,java 类型体系的最基本 的行为就无法保证了.

     大家可以去尝试,定义一个 java.lang.Object 类,可以正常编译,但是永远无法被加载运行.即使自定义了自己的类加载器.强行用 defineClass()方法去加载一个以”java.lang”开头的类也不会成功

5.3 破坏双亲委派模型

     双亲委派模型,并不是一个强制性的约束模型,而是 java 设计者推荐给开发者的类加载实现方式.在 java 的世界中大部分的类加载 器都遵循这个模型.但是,在一些应用场景下,由于直接或间接的原因,双亲委派模型被破坏.

1.在我们自定义类加载器的时候,可以复写父类 ClassLoader 的 loadClass 方法,这样就直接破坏了双亲委派模型.到后面 JDK1.2 之后,为了解决这个问题以及兼容问题,提供了一个 findClass()方法.

2.如果 API 中的基础类想要调用用户的代码(JNDI/JDBC 等),此时双亲委派模型就不能完成.为了解决这个问题,java 设计团队只好 使用一个不优雅的设计方案:Thread 的上下文类加载器,默认就是应用程序的类加载器.

3.由于程序动态性的发展,希望应用程序不用重启就可以加载最新的字节码文件.此时就需要破坏双亲委派模型.

双亲委派模型被破坏,并不包含贬义,只要有足够意义和理由就可以认为这是一种创新,什么方式会打破双亲委派模型呢?

1.自定义类加载器,复写 loadClass 方法.
2.使用线程的上下文类加载器对象.