JVM的故事——虚拟机类加载机制
虚拟机类加载机制
文章目录
- 虚拟机类加载机制
- 一、概述
- 二、类加载的时机
- 三、类加载的过程
- 四、类加载器
一、概述
本章将要讲解class文件如何进入虚拟机以及虚拟机如何处理这些class文件。Java虚拟机把class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称为虚拟机的类加载机制。这些过程都是在程序运行时发生的，使Java拥有了极高的扩展性和灵活性。
二、类加载的时机
一个类从被加载到虚拟机内存到卸载出内存，它的生命周期会经历加载、验证、准备、解析、初始化、使用、卸载。其中验证、准备、解析阶段统称为连接过程。
不过这些阶段也不一定是按照图中的顺序的，比如解析阶段的开始可能在初始化之后，这是为了支持Java的动态绑定。这里说的开始，而不是完成，是因为各个阶段都在互相交叉的进行，而不是等上一个阶段结束才进入下一阶段。
Java虚拟机规范并没有约束什么时候进行类的加载，但是对于类的初始化有着严格的约束，有且只有以下六种情况才会进行类的初始化：
（1）遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有初始化，则进行初始化。具体场景是：使用new关键字示例化对象；读取或设置一个静态字段(被final修饰的除外，它已经在编译期被放入常量池)；调用一个类型的静态方法时
（2）使用java.lang.reflect包的方法对类型进行反射调用时，若类型没初始化，则进行初始化。
（3）当初始化类时，若其父类没有初始化，则先初始化其父类
（4）当虚拟机启动时，虚拟机会先初始化用户指定的要执行的主类
（5）如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，且方法句柄对应的类没有被初始化，则先触发其初始化
（6）定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，该接口要在接口的实现类之前被初始化。
对于第三种，接口和类是不一样的，接口并不要求其父接口全部都初始化，只有真正使用到父接口才会初始化。
三、类加载的过程
（一）加载
加载是整个类加载的一个阶段，在加载阶段，整个Java虚拟机需要完成以下三件事情：
1、通过一个类的全限定名来获取定义此类的二进制字节流
2、将这个字节流所代表的静态存储结果转换为方法区运行时的数据结构
3、在内存中生成一个代表此类的java.lang.class对象，代表方法区此类的各种数据访问入口
这些定义并不是特别具体，留给虚拟机和Java的空间很大。例如获取此类的二进字节流，并不是只能通过class文件来获取，还可以从ZIP文件获取(JAR、WAR、EAR)、网络中获取(WEB Applet)、数据库中获取、运行时计算生成(动态代理Proxy)、从其它文件中获取(JSP生成对应的class文件)
对于获取类的二进制字节流的过程，非数组类型的加载阶段是可控性最强的阶段，既可以使用虚拟机内置的引导类加载器来完成，也可以定义自己的类加载器去完成二进制字节流的获取。
数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存动态创建的，但是它的加载与类加载器仍有着密切关系，因为数组内的元素类型还是要靠类加载器来加载。
若数组内的元素还是引用类型，则再往里看，并把数组标识在加载该组件类型的类加载器的命名空间上，直到不是引用类型。Java虚拟机会把数组标记为与引导类加载器关联。
加载阶段结束后，Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中了，类型数据妥善安置在方法区之后，会在Java堆内存中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口。
（二）验证
验证是连接阶段的第一步，这一步是确保class文件的字节码都符合约束要求，不会危害到JVM。Java语言本身是相对安全的编程语言，做一些访问数组边界外、跳转到不存在的代码行的事情，编译器会拒绝编译，抛出异常。但是并不是所有class文件都是由Java编译而来，class文件可以被编写成任何内容，所以Java虚拟机需要检查输入的字节流。验证大概有四个动作阶段：文件格式验证、元数据验证、字节码验证和符号引用验证。
1、文件格式验证：就是检验字节码文件的文件格式是否符合标准：
是否以魔数0XCAFEBABE开头
主次版本号是否在虚拟机接受范围内
常量池中的常量类型是否正确
指向常量的各种索引值是否指向不存在的常量或者不合理类型的常量
该阶段的验证点还有很多，主要目的是确保输入的字节流能被正确的解析并存入方法区。该阶段是基于二进制字节流的，过了这个阶段字节流才允许进入虚拟机内存的方法区进行存储，后面的验证都是基于方法区的存储结构上进行的，不会在进行读取、操作字节流了。
2、元数据验证：主要是对字节码描述信息进行语义分析。主要验证：
这个类是否有父类(除了java.lang.object外都应该有父类)
这个类的父类是否继承了不允许被继承的类(final修饰的类)
若该类不是抽象类，是否实现了其父类或者抽象类中的所有要求实现的方法
3、字节码验证：这个阶段主要验证程序语义是否合法、是否符合逻辑。主要对类的方法体(class文件的code属性)进行验证，确保类的方法在运行时不会做出危害虚拟机安全的行为，例如：
保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作
保证任何指令都不会跳转到方法区外的指令上去
保证类型转换是合法的，例如可以把子类对象赋值给父类数据类型，但把父类对象赋值给子类数据类型就是不安全的
若一个类型中有方法体的字节码没有通过字节码验证，它一定是有问题的。但是如果通过了字节码验证，也不一定就没有问题。因为无法使用程序去检验一个程序逻辑是否是正确的。
为了避免过多时间消耗在字节码验证，JDK6之后给方法体Code属性的属性表添加了一项”StackMapTable”的新属性，在javac编译器编译时就对这些方法进行验证，然后标识StackMapTable，但是这样也仍然会存在安全隐患，StackMapTable在进入虚拟机之前也是可能被修改的。
4、符号引用验证：这一阶段发生在虚拟机将符号引用转换为直接引用，这个转换动作在解析阶段发生。符号引用验证可以看作是对类自身以外的各类信息进行匹配性校验。通常需要校验：
通过全限定名能否找到对应的类
在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段
符号引用验证主要是确保解析阶段可以正常运行，如果不通过会抛出异常，典型的有java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError
验证阶段是很重要的，但并不是必须的，如果一段程序是反复使用和验证过的，也可以使用-Xverify：none来关闭验证，以缩短虚拟机加载类的时间。
（三）准备
准备阶段是为类中的变量(static修饰的变量)分配内存并赋初始值的过程。按照概念，这些变量分配的空间都应该在方法区，但是方法区只是一个概念，在JDK8之后，类变量则会随着Class对象一起存放在Java堆中。
这一阶段内存分配的仅包括类变量（静态变量），而不包括实例变量，实例变量会随着对象实例化时和对象一起分配在Java堆中。为类变量赋的初始值一般都是0值。
如图，在准备阶段为value赋的值为0，因为此时还没执行任何Java方法，为value赋值123是的putstatic指令是编译后放在类构造器()方法的，要到类的初始化阶段才会进行赋值。
但是如果像上图这样final修饰的变量(常量)，就会在准备阶段被赋值为123。编译时Javac将会为value生成ConstantValue属性，在准备阶段就会根据ConstantValue的值为value赋值。
（四）解析
解析阶段就是Java虚拟机把符号引用替换为直接引用的过程。
符号引用：以一组符号描述所引用的目标，符号可以是任何字面量，只要能定位到目标即可。引用的目标不一定已经加载到虚拟机中。
直接引用：直接或者间接定位到目标的句柄。引用的目标必定在虚拟机内存中存在。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符这7 类符号引用进行。
1、类或接口的解析：假设我们当前所处的为类D，要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那么包含下面三个步骤：
(1)如果C不是一个数组类型，那么虚拟机会把代表N的全限定名传递给D的类加载器去加载类C。在加载过程中，可能还会进行其它类的加载，由于元数据验证、字节码验证等，任何地方失败即代表着解析失败。
(2)如果C是一个数组类型，就要看它的元素类型。若元素类型是一个对象，就按照(1)进行加载数组元素类型，普通类型就直接加载
(3)完成加载，还需要验证D是否有权限访问C，如果没有则抛出出java.lang.IllegalAccessError异常
2、字段解析：要对一个字段解析，就要先对该字段所属的类或接口的符号引用进行解析。若是解析成功则进行接下来的步骤(该字段所属的类或接口用c表示)：
(1)如果c本身就包含了简单名称和字段描述符都与目标相匹配的字段，则解析结束。
(2)如果c实现了接口，则会按照继承关系递归搜索各个接口和它的父接口，如果有接口中包含了相匹配的字段，则解析结束
(3)如果c不是java.lang.object的话，则会按照继承关系递归搜索c的父类，若有相匹配的字段，则解析结束
(4)否则查找失败，返回java.lang.NoSuchFieldError异常
如果查找到了，则会对字段进行权限验证，若没有权限则返回java.lang.IllegalAccessError异常。
若是一个同名字段同时出现在某类的父类和实现的接口中，按照解析规则仍是可以确定唯一的访问字段，但是javac编译器可能拒绝将其解析为class文件。
2、方法解析：方法解析的第一步和字段解析一样，也是需要先解析出方法表的class_index项中索引的方法所属的类或接口的符号引用。方法所属的类或接口用c表示。接下来会按照以下步骤进行解析：
(1)class文件中类的方法和接口的方法的符号引用的常量类型定义是分开的，如果在类的方法表中发现class_index中索引的c是个接口，则抛出java.lang.IncompatibleClassChangeError 异常。
(2)在类c中若是发现简单名称和描述符都与方法相匹配的目标，则直接引用
(3)否则，递归在c的父类中寻找
(4)否则，在类c实现的接口和父接口中寻找，若存在匹配的方法则说明c是一个抽象类，抛出java.lang.AbstractMethodError异常
(5)否则，宣告查找失败，抛出java.lang.NoSuchMethodError异常
3、接口方法解析：接口方法解析也是需要先解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用，用c表示这个接口。解析过程如下:
(1)与类的解析方法相反，若是发现c是一个类，则抛出java.lang.IncompatibleClassChangeError异常
(2)若是接口c中存在对应的方法，则直接引用
(3)在c的父接口中查找，直到java.lang.Object类，查找到则直接引用
(4)由于java接口运行多继承，若c的不同父类接口中查找到多个对应的方法，则返回其中一个
(5)否则查找失败，抛出java.lang.NoSuchMethodError异常
（五）初始化
类的初始化是类加载过程的最后一个步骤。直到初始化阶段，Java虚拟机才开始真正执行类中编写的Java程序代码。在初始化阶段，就是根据程序员通过程序编码制定的计划去初始化变量和其它资源。初始化阶段就是执行类构造器()方法的过程，这个方法是Javac编译器的自动生成物。()方法是由编译器自动收集类中变量的赋值动作和静态代码块合并而成的。编译器收集顺序是按照语句在源文件中的顺序，静态语句块中只能访问定义在它之前的语句块，不能访问定义在它之后的语句块，但是可以给它之后的语句块赋值。
Java虚拟机会保证在子类的()方法执行前，父类的已经执行，所以最先执行的一定是java.lang.object的()方法。
由于先执行父类的()方法，所以父类中定义静态语句块会优先于子类的变量赋值操作。
如图，B的值应该是2而不是1。
如果类或者接口中没有静态语句块和对变量对赋值语句，那么编译器也可以不为这个类生成()方法
与类不同的是，执行接口的()方法不需要先执行父接口的()方法，只有当父接口定义的变量被使用时，父接口才会被初始化。
四、类加载器
JAVA虚拟机设计团队有意把类加载过程中”根据类的全限定名加载该类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类，实现这个动作的代码被称为”类加载器”。
（一）
类和类的加载器共同确定该类在Java虚拟机的唯一性。即使两个类来源于同一个class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，这两个类就肯定不相等。这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance() 方法的返回结果。
图中构造了一个简单的类加载器，加载了一个类并实例化了这个类的对象。通过第一行输出结果可以看出此对象确实是该类实例化出来的，但通过第二行发现这个对象与类进行所属类型检查返回了false，这是因为有两个classloadertest，一个是虚拟机的应用程序类加载的，一个是我们自定义的类加载器加载的，这两个在Java虚拟机中是两个不同的类。
（二）双亲委派模型
站在Java虚拟机的角度来看，只有两种类加载器，一种是启动类加载器，一种是其它所有的类加载器。
但是站在Java开发人员的角度来看，类加载器应该划分的更细致一点。Java一直保持着三层类加载器，双亲委派的类加载架构。绝大多数Java程序都会使用到以下3个系统提供的类加载器来进行加载：
启动类加载器：负责加载
扩展类加载器：它负责加载
应用程序类加载器：负责加载用户类路径 （ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果程序中没有定义自己的类加载器，一般情况下这个就是程序中默认的类加载器。
图7-2中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型”。这并不是一个具有强制性约束力的模型，而是Java设计者推荐给开发者的一种类加载器的最佳实现。
双亲委派模型的工作流程是：当类加载器收到了加载类的请求，它会先把请求委派给父类加载器去完成，只有当最终父类加载器无法完成才会由子类加载器完成。
使用双亲委派模型的一个明显的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，根据双亲委派模型最终一定会被最顶端的父类加载器(启动类加载器)加载。即使用户自己写了一个java.lang.obejct类，也只是可以正常编译，无法被加载运行。
这段代码的逻辑是：先检查该类是否被加载，若没有则调用父加载器的loadClass()方法，若父类为空则使用默认的启动类加载器进行加载，若父类加载失败则使用自己的findClass()进行加载。
（三）破坏双亲委派模型
直到Java 模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。
第一次被破坏：发生在双亲委派模型出现之前，即JDK1.2之前。在双亲委派模型出现之前，类加载器的概念和java.lang.ClassLoader在Java的第一个版本中就已经存在。面对已经存在的用户自定义的类加载器代码，在引用双亲委派模型时就不得不做一些妥协。只能尽量引导用户在findClass方法中重写加载方法而不是在loadClass方法中。
第二次被破坏：在双亲委派模型中，越基础的类就由越上层的类加载器加载。但是如果基础类型调用用户代码(如JNDI服务)，启动类加载器是不会认识用户代码的。为了解决这个困境，只好引用了只好引入了一个不太优雅的设计：线程上下文类加载器 （Thread Context ClassLoader）。使用线程上下文类加载器就可以去加载服务提供者接口相关的代码，实际上也就是父类加载器去请求子类加载器完成类加载的行为，这种行为违背了双亲委派模型的一般原则。
第三次被破坏：是由于用户对于程序的动态性的追求导致的，如模块热部署、代码热替换。
热部署的规范提案之一就是OSGi，OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现。在OSGi环境下，类加载器不再按照双亲委派模型，而是按照网状模型进行进行搜索。