类加载机制概述

在Class文件中描述的各种信息最终都需要加载到虚拟机中之后才能运行和使用。

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

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

类加载时机

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用、卸载7个阶段。其中验证、准备、解析三个部分统称为连接。

其中加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按着整个顺序按部就班的开始，而解析阶段则不一定，有时候会在初始化之后进行，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。但是要注意的是，这里我们说的是按部就班的“开始”，并没有说是按部就班的“完成”，也就是说并不是一个阶段完成之后再进行下一个阶段，而是可能一个阶段正在进行中的时候下一个阶段就开始了，但是每个阶段的“开始时间”是遵循上面的顺序的。

那什么时候开始类加载过程的第一个阶段“加载”呢？《Java虚拟机规范》中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对初始化阶段，《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

• 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化。能够生成这四条指令的典型Java代码场景有：
  • 使用new关键字实例化对象的时候。
  • 读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候
    -调用一个类型的静态方法的时候
• 使用java.lang.reflect包中的方法对类型进行反射调用的时候，如果此类没有进行过初始化，则需要先对此类进行初始化
• 在初始化一个类的时候，如果这个类的父类没有初始化，则需要先触发其父类的初始化
• 当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化整个主类。
• 当使用JDk1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic.REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
• 当一个接口中定义了JDK8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

这六种场景种的行为称为对一个类型进行主动引用。除此之外，所有引用类的方式都不会触发初始化，称为被动引用。

类加载过程

Java虚拟机中类加载的全过程，也就是加载、验证、准备、解析和初始化这五个阶段所具体执行的动作。

加载

加载阶段虚拟机需要完成以下三种事情：

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

相对于类加载过程的其他阶段，非数组类型的加载阶段（准确的说，是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的。加载阶段即可以使用Java虚拟机里内置的引导类加载器完成，也可以由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（重写一个类加载器的findClass()或loadClass()方法），实现根据自己的想法来赋予应用程序获取运行代码的动态性。

对于数组类而言，情况就有所不同，数组类本身就不通过类加载器创建，它是由java虚拟机直接在内存中动态构建出来的。但是数组类和类加载器仍然由很密切的关系，因为数组类的元素类型最终还是要靠类加载器去加载。一个数组类创建过程遵循以下规则：

• 如果数组的组件类型是引用类型，那就递归采用我们上面提到的加载过程去加载这个组件类型，数组将被标识在加载该组件类型的类加载器的类名称空间上。
• 如果数组的组件类型不是引用类型（例如int[]）Java虚拟机将会把数组标记为与引导类加载器关联。
• 数组类的可访问性与它的组件类型的可访问性一致，如果组件类型不是引用类型，它的数组类的可访问性将默认为public，可被所有的类和接口访问到。

加载阶段结束后，Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中了，方法区中的数据存储格式完全由虚拟机实现自行定义。类型数据安置在方法区之后，会在Java堆内存中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的类型数据的外部接口。

加载阶段与连接阶段的部分动作是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些在加载阶段之中进行的动作，仍然属于连接阶段的一部分，这两个阶段的时间仍然保持着固定的先后顺序。

验证

验证是连接阶段的第一步。这个阶段的目的是为了确保Class文件的字节流中包含的信息符合当前《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段可能包括下面这些验证点：

1. 文件格式校验：要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
2. 元数据校验：对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java虚拟机规范》的要求。
3. 字节码校验：整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型校验完毕以后，这阶段就要对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。
4. 符号引用校验：此阶段的校验行为发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三个阶段----解析阶段中发生。符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。

准备

准备阶段是正式为类中定义的静态变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域，在JDK7之前，HotSpot使用永久代来实现方法区时，实现是完全符合这种逻辑概念的；而在JDK7及以后，类变量则会随着Class对象一起存放在Java堆中，这时候“类变量在方法区”就完全是一种对逻辑概念的表述了。

这个阶段有两个容易产生混淆的概念需要强调一下，首先这时候进行内存分配的仅包括类变量（即静态变量，被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化的时候随着对象一起分配在java堆中。其次，这里所说的初始值“通常情况下”是数据类型的零值，例如：public static int a=123;那么此时a在准备阶段过后的初始值为0，而不是123，因为这个时候尚未开始执行任何java方法，而把a赋值为123的操作是在初始化阶段进行的。注意，刚才说的是“通常情况”下初始值为零值，那相对的会有一些“特殊情况”：如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量a就会被初始化为ConstantValue属性所指定的值，假设上面类变量a的定义变为：public static final int a=123;编译时javac将会为a生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将a赋值为123.

解析

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

符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。

直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到的目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的。如果有了直接引用，那引用的目标必定已经在内存中存在了。

初始化

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正的开始执行类中定义的java程序代码（或者说是字节码）。

类和类加载器

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

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

类加载器的分类：

从Java虚拟机角度来讲，只存在两种不同的类加载器：一种是启动类加载器，这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是其他所有的类加载器，这些类加载器都有java语言实现，独立存在于虚拟机外部，并且都继承自抽象类java.lang.ClassLoader。

但是从Java开发人员角度来看，类加载器还可以划分的更细致一些。自JDK1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构。尽管这套架构在Java模块化系统出现后有了一些调整变动，但依然未改变其主体结构。三层类加载器大致可以分为：

• 启动类加载器：这个类加载器负责将存放在<JAVA_HOME>\lib目录中的，或者被-XbootClasspath参数所指定的路径中存放的，而且是虚拟机能够识别的类库加载到虚拟机内存中。
• 扩展类加载器：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。根据“扩展类加载器”这个名称，就可以推断出这是一种Java系统类库的扩展机制，JDK的开发团队允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能。JDK9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。
• 应用程序类加载器：这个类加载器由sun.misc.Launcher$APPClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystemClassLoader方法的返回值，所以有些地方也称它为“系统类加载器”。它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
• 自定义类加载器：

此四种类型的加载器从上到下存在父子关系，但是这里类加载器之间的父子关系一般不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。

双亲委派模型

各种类加载器之间的层次关系构成为类加载器的“双亲委派模型”。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里的类加载器之间的父子关系一般不是以继承的关系来实现的，而是使用组合关系来复用类加载器的代码。

需要注意的是，双亲委派模型不是一个具有强制性约束力的模型，而是Java设计者们推荐给开发者的一种类加载实现的最佳实践。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

使用双亲委派模型来组织加载器之间的关系，一个好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都委派给处理模型最顶端的启动类加载器进行加载，因为Object类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序ClassPath中，那么系统中就会出现多个不同的Object类，应用程序就会变得一片混乱。

破坏双亲委派模型

上面说过双亲委派模型并不是一个具有强制性约束力的模型，而是Java设计者们推荐给开发者的一种类加载实现的最佳实践。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模的“被破坏”的情况。
第一次破坏：这次其实发生在双亲委派模型出现之前----即JDK1.2面世以前的“远古”时代。由于双亲委派模型在JDK1.2之后才有，但是类加载器的概念和抽象类ClassLoader在Jdk的第一个版本就存在了，面对已经存在的用户自定义类加载器的代码，当Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的ClassLoader中添加一个新的protected方法findClass()，并引导用户编写类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。
第二次破坏：这次主要是有双亲委派模型自身的缺陷导致的，双亲委派模型很好的解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类又要调用访问用户的代码，该怎么办呢？一个典型的例子就是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器完成加载，肯定属于Java中很基础的服务了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（SPI）的代码，问题来了，启动类加载器是绝不可能认识、加载这些代码的，该怎么办呢？
为了解决这个问题，Java的设计团队只好引入一个不太好的设计：线程上下文加载器。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则。

第三次破坏：这次主要是用户对程序动态性的追求而导致的，这里说的“动态性”指的是一些非常“热”门的名词：代码热替换、模块热部署等。说白了就是希望Java应用程序能像我们的电脑外设那样，接上鼠标、优盘，不用重启机器就能立即使用，哪块有问题就换哪块，不用关机也不用重启。
而第三次双亲委派模型的破坏体现在Java中的事件，要追溯到从2008开始的在Java社区有关模块化规范的论战，中间的博弈很是复杂，但最终以IBM公司主导的JSR-291（即OSGi R4.2）获胜。虽然SUN公司后来在JDK9中发布了Jigsaw规范，并且现已成为Java的标准功能，但它仍需小心翼翼地避开OSGi R4.2运行期动态热部署上的优势，仅局限于静态地解决模块间封装隔离和访问控制的问题。那OSGi是如何通过类加载器实现热部署的呢？
OSGi 实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块都有自己的类加载器，当需要更换一个Bundle时，就把Bundle连同它的类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不在是双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。