深入理解Java虚拟机之——类加载机制

声明：原创作品，转载请注明出处https://www.jianshu.com/p/336a6f7dd413

Java是一门面向对象的语言，万物皆对象，万物都可以用一个类来描述。当我们想要描述一个事物的时候，我们会先创建一个.class文件，然后使用的时候只需要在代码中new下，这样这个类的实例对象就出来了。接着就可以调用这个对象的各种之前已经定义的方法。那么就有个问题，就是一个.class文件是如何进入到我们的虚拟机中的，进入之后又做了怎样的处理。其实这一系列过程我们称之为类加载机制。

一.类的生命周期

一个类在虚拟机中完整的生命周期包括以下几个阶段：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）、卸载（Unloading）。其中验证、准备、解析三个部分统称为连接（Linking）。顺序如下图：

类的生命周期

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，但是解析阶段不一样，有可能会在初始化之后，这是为了支持Java语言的运行时绑定。
类的加载过程其实只是上面的加载到初始化过程，接下来我们来挨个看下这几个阶段：

二.类的加载过程

1.加载

这一阶段虚拟机主要要做的三件事情是：

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

2.验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证分四个阶段：文件格式验证、元数据验证、字节码验证和符号引用验证。
a.文件格式验证
第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
b.元数据验证
第二阶段是对字节码描述的信息进行予以分析，以保证其描述的信息符合Java语言规范的要求。
c.字节码验证
第三阶段是整个验证过程中最复杂的一个阶段，主要工作是进行数据流和控制流分析。在第二阶段对元数据信息中的数据类型做完校验后，这个阶段对类的方法体进行校验分析。这个阶段的任务是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。
d.符号引用验证
最后一个阶段的校验发生在虚拟机将符号引用转为直接引用的时候，这个转换动作将在连接的第三个阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性的校验，其目的是确保解析动作能正常执行。

3.准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。这里的类变量指的是被static修饰的变量，这里设置的初始值为0值。如下

public static int value  = 123;

那么变量value在准备阶段过后其值为0而不是123，当然如果这个value是被final修饰，那么在准备阶段会直接设置为123，如下：

public static final int value = 123;

4.解析

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

符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。
直接引用（Direct References）:直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

对同一个符号引用进行多次解析请求是很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存。解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行。

a.类或接口的解析
假设当前代码所处的类为D，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那虚拟机完成整个解析的过程需要包括以下3个步骤：

1.如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类。在加载过程中，由于无数据验证、字节码验证的需要，又将可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程出现任何异常，解析过程就将宣告失败。
2.如果C是一个数组类型，并且数组的元素类型为对象，也就是N的描述符会是类似[java.lang.Integer的形式，那将会按照第一点的规则加载数组元素类型。如果N的描述符如前面所假设的形式，需要加载的元素类型就是java.lang.Integer,接着由虚拟机生成一个代表此数组维度和元素的数组对象。
3.如果上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认C是否具备对D的访问权限。如果发现不具备访问权限，将抛出java.lang.IllegalAccessError异常。

b.字段解析
在解析字段之前先要解析字段所属的类或接口，如果解析成功，那将这字段所属的类或接口用C表示，虚拟机规范要求按照如下步骤对C进行后续字段的解析：

1.如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
2.否则，如果在C中实现了接口，将会按照继承关系从上往下递归搜索各个接口和它的父接口，如果接口中包含了简单名称和字段描述符都与目标想匹配的字段，则返回这个字段的直接引用，查找结束。
3.否则，如果C不是java.lang.Object的话，将会按照继承关系从上往下递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。
4.否则，查找失败，抛出java.lang.NoSuchFieldError异常。

如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

c.类方法解析
类方法解析的第一个步骤与字段解析一样，需要先解析方法所属的类或接口，如果成功我们依然用C表示这个类，接下来虚拟机将会按照如下步骤进行后续的类方法解析：

1.类方法和接口方法符号引用的常量类型定义是分开的，如果C是一个接口，则直接抛出java.lang.IncompatibleClassChangeError异常。
2.如果通过了上面这步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
3.否则，在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
4 否则，在类C实现的接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在相匹配的方法，说明类C是一个抽象类，这个时候查找结束，抛出java.lang.AbstractMethodError异常。
5.否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常。

最后如果查找过程成功返回了直接引用，将会对这个方法进行权限验证；如果发现不具备对此方法的访问权限，将抛出java.lang.IllegalAccessError异常。

d.接口方法解析
同上，解析接口方法时需先解析方法所属的类或符号的符号引用，如果成功，依然用C表示这个接口，解析步骤如下：

1.与类方法解析相反，如果发现这个C是类不是接口，则直接抛出java.lang.IncompatibleClassChangeError异常。
2.否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
3.否则，在接口C的父接口中递归查找，直到java.lang.Object类为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
4.否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常。

由于接口中的所有方法都默认是public，所以不存在访问权限的问题，因此接口方法的符号解析应当不会抛出java.lang.IllegalAccessError异常。

5.初始化

类初始化阶段是类加载过程的最后一步，之前的阶段几乎都是由虚拟机主导和控制，这一阶段才真正执行自己定义的Java程序代码。初始化阶段是执行类构造器<clinit>()方法的过程。来看下<clinit>()方法相关说明：

<clinit>()方法是由编译器自动搜集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器搜集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但是不能访问。
<clinit>()方法与类的构造函数不同，它不需要显示的调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。
由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作
<clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法，但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父类接口中定义的变量被使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。

3.类加载器

类加载器的功能很简单，就是通过一个类的全限定名来获取描述此类的二进制字节流。类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。

类加载器的分类

类加载分三种：启动类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）、应用程序类加载器（Application ClassLoader）。其中启动类加载器是由C++语言实现，是虚拟机自身的一部分，另外两种均有Java语言实现，独立于虚拟机外部并且全部继承自抽象类java.lang.ClassLoader。

启动类加载器：负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。
扩展类加载器：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序类加载器：这个类加载器由sun.msc.Launcher$AppClassLoader来实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委托模型

我们的应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器之间的关系如下：

双亲委托模型

上面的这种层次关系，就称为类加载器的双亲委派模型（Parents Delegation Model）。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父类关系一般不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。
双亲委派模型的工作过程是：如果一个类加载器收到了类加载器的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载。
双亲委派模型实现原理：其代码实现都在java.lang.ClassLoader的loadClass方法中，首先会检查是否已经被加载过，若没有加载则调用父加载器的loadClass方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，则在抛出ClassNotFoundException异常后，再调用自己的findClass方法进行加载。

破坏双亲委派模型

双亲委派模型主要出现过三次被破坏情况
第一次破坏
双亲委派模型是JDK1.2之后才被引入的，需要自定义类加载器时，之前都是直接重写ClassLoader的loadClass()方法，而引入双亲委派模型后只需要在findClass中实现，所以之前的方式不符合双亲委派模型。
第二次破坏
上面我们提到启动类加载器都是加载一些API中基础的类，但是有的时候需要用启动类加载器加载自己的代码，这就打破原有的双亲委派模型，比如JNDI服务。
第三次破坏
关于OSGi等热部署技术，OSGi是一种平级的加载，是一种网状结构，而不是上述的双亲委派结构，是一种树状结构。

参考书籍：《深入理解Java虚拟机》