Java虚拟机-类加载机制

目录

• 概述
• 类加载的时机
  • 加载
• 类加载的过程
  • 加载
  • 验证
  • 准备
  • 解析
  • 初始化
• 类加载器
  • 类与类加载器
  • 双亲委派模型
  • 破坏双亲委派模型

概述

虚拟机把描述类的数据从Class文件加载到内存，并且对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
编译时无需进行连接工作，类的加载、连接和初始化过程都是在程序运行期间完成的。如面向接口的应用程序可以等到运行时再指定其实际的实现类；用户可以通过预定义或者自定义的类加载器，让本地的应用程序可以在运行时从网络或者其他地方加载一个二进制流作为程序代码的一部分。

类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存为止，生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。

加载

5种情况必须立即对类进行初始化：

1. 使用new实例化对象、读取或者设置一个类的静态字段（被final修饰在编译期以及把结果放入常量池的静态字段除外）、调用一个类的静态方法。
2. 使用java.lang.reflect包的方法对类进行反射调用时，对应的类没有经过初始化，则需要触发其初始化。
3. 初始化一个类时如果其父类没有初始化，则需要先触发父类的初始化。
4. 虚拟机启动时，用户指定类一个要执行的主类，虚拟机会先初始化这个类。
5. JDK1.7如果一个java.lang.invoke.MethodHandle实例最后解析结果位REF_getStatic,REF_putStatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有经过初始化，则需要触发其初始化。
   除了上面这5种之外，其他所有引用的方式都不会触发初始化，称为被动引用。

类加载的过程

过程主要包括加载、验证、准备、解析、初始化这5个阶段

加载

加载阶段，虚拟机主要完成下面3件事情：

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

通过类的全限定名获取类的二进制字节流有多种方式，如：

1. 从Zip、Jar、Ear、War等包种读取。
2. 从网络种获取，Applet。
3. 运行时计算生成，动态代理技术。
4. 其他文件生成，如JSP
   等等

非数组类可以使用系统提供的引导类加载器完成，也可以用户自定义类加载器（重写类加载器的loadClass（）方法）
数组类不通过类加载器创建，由虚拟机直接创建。

验证

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

1. 文件格式验证（确保类文件结构符合JVM标准）
2. 元数据验证（验证元数据信息种的数据类型，信息符合Java规范，是否有父类，是否实现接口中的方法，重载是否符合规则等等）
3. 字节码验证（分析数据流和控制流确定程序语义是合法的，对方法体进行校验分析，例如类型安全，指令不能随意跳转）
   Halting Problem（停机问题）用程序去校验逻辑是无法做到绝对准确的。
4. 符号引用验证（类、字段、方法是否能够访问）

准备

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

解析

解析阶段是虚拟机将常量池内的符号引用替换位直接引用的过程，符号引用在Class文件种以CONSTSNT_Class_info、CONSTSNT_Fieldref_info、CONSTSNT_Methodref_info等类型的常量出现。
符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义的定位到目标即可。
直接引用（Direct References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同，如果有直接引用，那引用的目标必定已经在内存中存在。

1. 类或接口的解析
   假设类为D，要把一个从未解析过的符号引用N解析为一个类或者接口C的直接引用，解析过程分为三步：
   1)C不是数组类型，虚拟机把N的全限定名传递给D的类加载器去加载类C，过程中一旦出现异常，解析宣告失败。
   2)C是数组类型且元素类型是对象，按照1的规则加载数组元素类型，接着由虚拟机生成一个代表此数组维度和元素的数组对象。
   3)上面两步没有任何异常，C在虚拟机中已经成为一个有效的类或者接口，但是解析完成前还要进行符号引用验证，确认D是否具备对于C的访问权限。

2. 字段解析
   解析字段符号引用，首先对字段表内class_index中索引的CONSTANT_Class_info符号引用进行解析，就是类或者接口符号引用，如果过程中发生异常会导致解析失败，如果成功将这个字段所属的类或者接口以C表示，后续操作为：
   1)C本身包含简单名称和字段描述符都与目标匹配的字段，返回这个字段直接引用查找结束
   2)如果C实现了接口，会按照继承关系从下往上查找，如果找到直接引用查找结束
   3)如果C不是java.lang.Object，按照继承关系从下往上查找，如果找到直接引用查找结束
   4)都没找到，抛出java.lang.NoSuchFieldError。如果找到还要判断是否具有访问权限

3. 类方法解析
   和字段解析相似，我们假设方法所属的类解析成功为C，后续操作：
   1)如果在类方法表中发现class_index中索引的C是个接口，就抛出java.lang.IncompatibleClassChangeError，也就是类的方法不能是一个接口方法或者抽象方法，是必须实现的。
   2)如果第一步没问题，就在类C中查找是否有简单名称和描述符都与目标匹配的方法，如果找到直接引用查找结束
   3)否则在C的父类中递归查找，如果找到直接引用查找结束
   4)否则在C的接口列表和父接口中递归查询，如果找到说明C是一个抽象类，查找结束抛出java.lang.AbstractMethodError异常。
   5)都没有找到，抛出java.lang.NoSuchMethodError，如果找到还要判断是否具有访问权限

4. 接口方法解析
   和类方法相似，设定方法所属接口解析成功为C，后续操作：
   1)如果发现class_index的索引C是一个类而不是接口，就抛出java.lang.IncompatibleClassChangeError
   2)在接口C中直接查找，如果找到直接引用查找结束
   3)在接口C的父接口中递归查找，直到java.lang.Object类，如果找到直接引用查找结束
   4)都没有找到，抛出java.lang.NoSuchMethodError，接口的方法默认都是public，因此不具有访问权限问题

初始化

类初始化是类加载过程的最后一步，这里开始执行类中定义的Java程序代码（或者说字节码）。初始化阶段是执行类构造器() 方法的过程。这个方法是由编译期自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并而成的。
() 方法与类构造函数()方法不同，不需要显式调用父类构造器，虚拟机会保证在子类的() 方法执行前，父类的() 已经执行完毕，第一个被执行的() 方法一定是java.lang.Object。

类加载器

虚拟机把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，让应用程序字节决定如何去获取所需要的类，实现这个动作的代码模块称为“类加载器”。

类与类加载器

任意一个类都要由加载他的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器都拥有一个独立的类名称空间。两个类是否相等，需要来源于同一个Class文件，被同一个虚拟机加载，同一个类加载器。

双亲委派模型

Java虚拟机只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全部都继承自抽象类java.lang.ClassLoader。
根据更细致的分法，绝大部分Java程序都会使用到以下3种系统提供的类加载器。

1. 启动类加载器（Bootstrap ClassLoader）
   这个类加载器负责将存放在<JAVA_HOME>lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别如rt.jar，名字不符合的即使放在路径中也不会被加载），启动类加载器无法被Java程序直接引用。
2. 扩展类加载器（Extension ClassLoader）
   这个类加载器由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>libext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
3. 应用程序类加载器（Application ClassLoader）
   这个类加载器由sun.misc.Launcher$AppClassLoader实现，这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称之为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般就是使用这个类加载器。

类加载器的双亲委派模式（Parents Delegation Model）是指除了顶层的启动类加载器外，其余的类加载器都应当由自己的父类加载器，类加载器之间的父子关系一般不会以继承（Inheritantce）的关系来实现，而是都使用组合（Composition）的关系来复用父加载器的代码。
双亲委派模型的工作过程是：如果一个类加载器收到类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，所有的加载请求最终都传送到顶层的启动类加载器中，只有父加载器无法完成加载请求（它的搜索范围中没有找到所需要的类），子加载器才会尝试自己去加载。
这样Java类随着它的类加载器一起具备了一种带有优先级的层次关系，例如java.lang.Object，它在rt.jar中，无论哪个类加载器要加载这个类最终都是交给顶层启动类加载器进行加载，这样Object类在所有的加载器环境中都是同一个类。

破坏双亲委派模型

1. 由于JDK1.0时代就存在类加载器，而双亲委派模型在JDK1.2之后才被引入，所以为了兼容做了一些调整。
2. 例如JNDI的场景中，JNDI的代码有启动类加载器加载，但是要调用在ClassPath下的接口提供者的代码。所以Java引入的线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader() 方法进行设置，如果创建线程时未设置会从父线程中继承一个，如果应用全局都没有设置过，那这个类加载器默认就是应用程序加载器。JDNI会使用这个类加载器去加载服务商代码，所以实际是父类加载器请求子类加载器去完成类加载动作。
3. 程序的动态性。代码热替换（HotSwap），模块热部署（HotDeployment）。JSR-291（OSGi R4.2）。