【深入理解JVM】深入浅出类加载机制

Java虚拟机把描述类的数据从Class⽂件加载到内存，并对数据进⾏校验、转换解析和初始化，最终形成可以被虚拟机直接使⽤的Java类型，这个过程被称作虚拟机的类加载机制。与那些在编译时需要进⾏连接的语⾔不同，在Java语⾔⾥⾯，类型的加载、连接和初始化过程都是在程序运⾏期间完成的，这种策略让Java语⾔进⾏提前编译会⾯临额外的困难，也会让类加载时稍微增加⼀些性能开销， 但是却为Java应⽤提供了极⾼的扩展性和灵活性，Java天⽣可以动态扩展的语⾔特性就是依赖运⾏期动态加载和动态连接这个特点实现的。例如，编写⼀个⾯向接⼝的应⽤程序，可以等到运⾏时再指定其实际的实现类，⽤户可以通过Java预置的或⾃定义类加载器，让某个本地的应⽤程序在运⾏时从⽹络或其他地⽅上加载⼀个⼆进制流作为其程序代码的⼀部分。

类加载的时机

⼀个类型从被加载到虚拟机内存中开始，到卸载出内存为⽌，它的整个⽣命周期将会经历 加载( Loading ) 、验证 ( Verification ) 、准备 ( Preparation ) 、解析 ( Resolution ) 、 初始化( Initialization ) 、使⽤ ( Using) 和 卸载 ( Unloading) 七个阶段 ，其中验证、准 备、解析三个部分统称为连接(Linking)。

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始，⽽解析阶段则不⼀定: 它在某些情况下可以在初始化阶段之后再开始，这是为了⽀持Java语⾔的运⾏时绑定特性(也称为动态绑定或晚期绑 定)。请注意，这⾥笔者写的是按部就班地“开始”，⽽不是按部就班地“进⾏”或按部就班地 “完成”，强调这点是因为这些阶段通常都是互相交叉地混合进⾏的，会在⼀个阶段执⾏的过程中调⽤、激活另⼀个阶段。

关于在什么情况下需要开始类加载过程的第⼀个阶段“加载”《Java虚拟机规范》中并没有 进⾏强制约束，这点可以交给虚拟机的具体实现来⾃由把握。但是对于初始化阶段， 《Java虚拟机规范》则是严格规定了有且只有六种情况必须⽴即对类进⾏“初始化”(⽽加载、验证、准备⾃然需要在此之前开始):

1. **遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进 ⾏过初始化，则需要先触发其初始化阶段。**能够⽣成这四条指令的典型Java代码场景有
   1. 使⽤new关键字实例化对象的时候。
   2. 读取或设置⼀个类型的静态字段(被final修饰、已在编译期把结果放⼊常量池的静态字段 除外)(常量在编译阶段会存⼊调⽤类的常量池中，本质上没有直接引⽤到定义常量的类， 因此不会触发定义常量的类的初始化) 的时候。
   3. 调⽤⼀个类型的静态⽅法的时候。
2. 使⽤java.lang.reflect包的⽅法对类型进⾏反射调⽤的时候，如果类型没有进⾏过初始 化，则需要先触发其初始化。
3. 当初始化类的时候，如果发现其⽗类还没有进⾏过初始化，则需要先触发其⽗类的初始化。
4. **当虚拟机启动时，**⽤户需要指定⼀个要执⾏的主类(包含main()⽅法的那个类)，虚拟机 会先初始化这个主类。
5. 当使⽤JDK 7新加⼊的动态语⾔⽀持时，如果⼀个java.lang.invoke.MethodHandle实例最后的解 析结果为REF_getStatic、REF_p utStatic、REF_invokeStatic、 REF_newInvokeSpecial四种类型的⽅法句柄，并且这个⽅法句柄对应的类没有进⾏过初 始化，则需要先触发其初始化。
6. 当⼀个接⼝中定义了JDK 8新加⼊的默认⽅法(被default关键字修饰的接⼝⽅法)时，如 果有这个接⼝的实现类发⽣了初始化，那该接⼝要在其之前被初始化。

对于这六种会触发类型进⾏初始化的场景，《Java虚拟机规范》中使⽤了⼀个⾮常强烈的限定语 ——“有且只有”，这六种场景中的⾏为称为对⼀个类型进⾏主动引⽤。除此之外，所有引⽤类型的⽅式都不会触发初始化，称为被动引⽤。

对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其⼦类来引⽤⽗类中定义的静态字段，只会触发⽗类的初始化⽽不会触发⼦类的初始化。

类加载的过程

加载

“加载”(Loading)阶段是整个“类加载”(Class Loading)过程中的⼀个阶段。在加载阶段， Java虚拟机需要完成以下三件事情:

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

相对于类加载过程的其他阶段，⾮数组类型的加载阶段(准确地说，是加载阶段中获取类 的⼆进制字节流的动作)是开发⼈员可控性最强的阶段。加载阶段既可以使⽤Java虚拟机⾥内置的引导类加载器来完成，也可以由⽤户⾃定义的类加载器去完成，开发⼈员通过定义⾃⼰的类加载器去控制字节流的获取⽅式(重写⼀个类加载器的findClass()或 loadClass()⽅法)，实现根据⾃⼰的想法来赋予应⽤程序获取运⾏代码的动态性。

对于数组类⽽⾔，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型(Element Type，指的是数组去掉所有维度的类型)最终还是要靠类加载器来完成加载，⼀个数组类(下⾯简称 为C)创建过程遵循以下规则:

1. 如果数组的组件类型(Component Type，指的是数组去掉⼀个维度的类型，注意和前⾯ 的元素类型区分开来)是引⽤类型，那就递归采⽤本节中定义的加载过程去加载这个组件 类型，数组C将被标识在加载该组件类型的类加载器的类名称空间上(这点很重要，在7.4 节会介绍，⼀个类型必须与类加载器⼀起确定唯⼀性)。
2. 如果数组的组件类型不是引⽤类型(例如int[]数组的组件类型为int)，Java虚拟机将会把数 组C标记为与引导类加载器关联。
3. 数组类的可访问性与它的组件类型的可访问性⼀致，如果组件类型不是引⽤类型，它的数 组类的可访问性将默认为public，可被所有的类和接⼝访问到。

验证

验证是连接阶段的第⼀步，这⼀阶段的⽬的是确保Class⽂件的字节流中包含的信息符合 《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运⾏后不会危害虚拟机⾃身的安全。

验证阶段⼤致上会完成下⾯四个阶段的检验动作: ⽂件格式验证、元数据验证、字节码验证和符号引⽤验证。

1. 文件格式验证

第⼀阶段要验证字节流是否符合Class⽂件格式的规范，并且能被当前版本的虚拟机处 理。这⼀阶段可能包括下⾯这些验证点:

·是否以魔数0xCAFEBABE开头。

·主、次版本号是否在当前Java虚拟机接受范围之内。

·常量池的常量中是否有不被⽀持的常量类型(检查常量tag标志)。

·指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。 ·CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。

·Class⽂件中各个部分及⽂件本身是否有被删除的或附加的其他信息。

实际上第⼀阶段的验证点还远不⽌这些，该验证阶段的主要⽬的是保证输⼊的字节流能正确地解析并存储于⽅法区之内，格式上符合描述⼀个Java类型信息的要求。这阶段的验证是基于⼆进制字节流进⾏的，只有通过了这个阶段的验证之后，这段字节流才被允许进⼊Java虚拟机内存的⽅法区中进⾏存储，所以后⾯的三个验证阶段全部是基于⽅法区的存储结构上进⾏的，不会再直接读取、操作字节流了。

元数据验证

第⼆阶段是对字节码描述的信息进⾏语义分析，以保证其描述的信息符合《Java语⾔规 范》的要求，这个阶段可能包括的验证点如下:

·这个类是否有⽗类(除了java.lang.Object之外，所有的类都应当有⽗类)。

·这个类的⽗类是否继承了不允许被继承的类(被final修饰的类)。

·如果这个类不是抽象类，是否实现了其⽗类或接⼝之中要求实现的所有⽅法。

·类中的字段、⽅法是否与⽗类产⽣⽭盾(例如覆盖了⽗类的final字段，或者出现不符合规 则的⽅法重载，例如⽅法参数都⼀致，但返回值类型却不同等)。

第⼆阶段的主要⽬的是对类的元数据信息进⾏语义校验，保证不存在与《Java语⾔规 范》定义相悖的元数据信息。

字节码验证

第三阶段是整个验证过程中最复杂的⼀个阶段，主要⽬的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。在第⼆阶段对元数据信息中的数据类型校验完毕以后，这阶段就要对类的⽅法体(Class⽂件中的Code属性)进⾏校验分析，保证被校验 类的⽅法在运⾏时不会做出危害虚拟机安全的⾏为，例如:

· 保证任意时刻操作数栈的数据类型与指令代码序列都能配合⼯作，例如不会出现类似于 “在操作栈放置了⼀个int类型的数据，使⽤时却按long类型来加载⼊本地变量表中”这样的 情况。

· 保证任何跳转指令都不会跳转到⽅法体以外的字节码指令上。

· 保证⽅法体中的类型转换总是有效的，例如可以把⼀个⼦类对象赋值给⽗类数据类型， 这是安全的，但是把⽗类对象赋值给⼦类数据类型，甚⾄把对象赋值给与它毫⽆继承关系、完全不相⼲的⼀个数据类型，则是危险和不合法的。

如果⼀个类型中有⽅法体的字节码没有通过字节码验证，那它肯定是有问题的;但如果⼀ 个⽅法体通过了字节码验证，也仍然不能保证它⼀定就是安全的。即使字节码验证阶段中进⾏了再⼤量、再严密的检查，也依然不能保证这⼀点。

符号引⽤验证

最后⼀个阶段的校验⾏为发⽣在虚拟机将符号引⽤转化为直接引⽤的时候，这个转化动作将在连接的第三阶段——解析阶段中发⽣。符号引⽤验证可以看作是对类⾃身以外(常量 池中的各种符号引⽤)的各类信息进⾏匹配性校验，通俗来说就是，**该类是否缺少或者被禁⽌访问它依赖的某些外部类、⽅法、字段等资源。**本阶段通常需要校验下列内容:

·符号引⽤中通过字符串描述的全限定名是否能找到对应的类。

·在指定类中是否存在符合⽅法的字段描述符及简单名称所描述的⽅法和字段。

·符号引⽤中的类、字段、⽅法的可访问性(private、protected、public、)是否可被当前类访问。

符号引⽤验证的主要⽬的是确保解析⾏为能正常执⾏，如果⽆法通过符号引⽤验证， Java虚拟机将会抛出⼀个 java.lang.IncompatibleClassChangeError 的⼦类异常 ， 典型的如 : java.lang.IllegalAccessError、java.lang.NoSuchFieldError、 java.lang.NoSuchMethodError等。

验证阶段对于虚拟机的类加载机制来说，是⼀个⾮常重要的、但却不是必须要执⾏的阶段，因为验证阶段只有通过或者不通过的差别，只要通过了验证，其后就对程序运⾏期没有任何影响了。如果程序运⾏的全部代码(包括⾃⼰编写的、第三⽅包中的、从外部加载的、动态⽣成的等所有代码)都已经被反复使⽤和验证过，在⽣产环境的实施阶段就可以 考虑使⽤-Xverify: none参数来关闭⼤部分的类验证措施，以缩短虚拟机类加载的时间。

准备

**准备阶段是正式为类中定义的变量(即静态变量，被static修饰的变量)分配内存并设置类变量初始值的阶段。**从概念上讲，这些变量所使⽤的内存都应当在⽅法区中进⾏分配，但必须注意到⽅法区本身是⼀个逻辑上的区域，在JDK 7及之前，HotSpot使⽤永久代来实现⽅法区时，实现是完全符合这 种逻辑概念的; ⽽在JDK 8及之后，类变量则会随着Class对象⼀起存放在Java堆中，这时候“类变量在⽅法区”就完全是⼀种对逻辑概念的表述了。

关于准备阶段，还有两个容易产⽣混淆的概念笔者需要着重强调，⾸先是这时候进⾏内存分配的仅包括类变量，⽽不包括实例变量，实例变量将会在对象实例化时随着对象⼀起分配在Java堆中。其次是这⾥所说的初始值“通常情况”下是数据类型的零值，假设⼀个类变量的定义为:

那变量value在准备阶段过后的初始值为0⽽不是123，因为这时尚未开始执⾏任何Java⽅法，⽽把value赋值为123的putstatic指令是程序被编译后，存放于类构造器()⽅法之中，所以把value赋值为123的动作要到类的初始化阶段才会被执⾏。

上⾯提到在“通常情况”下初始值是零值，那⾔外之意是相对的会有某些“特殊情况”: 如果 类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量值就会被初始化为 ConstantValue属性所指定的初始值，假设上⾯类变量value的定义修改为:

编译时Javac将会为value⽣成ConstantValue属性，在准备阶段虚拟机就会根据 ConstantValue的设置将value赋值为123。

解析

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

符号引⽤(Symbolic References): **符号引⽤以⼀组符号来描述所引⽤的⽬标，符号可以是任何形式的字⾯量，只要使⽤时能⽆歧义地定位到⽬标即可。**符号引⽤与虚拟机实现的内存布局⽆关，引⽤的⽬标并不⼀定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同， 但是它们能接受的符号引⽤必须都是⼀致的，因为符号引⽤的字⾯量形式明确定义在《Java虚拟机规范》的Class⽂件格式中。

直接引⽤(Direct References): **直接引⽤是可以直接指向⽬标的指针、相对偏移量或者是⼀个能间接定位到⽬标的句柄。**直接引⽤是和虚拟机实现的内存布局直接相关的，同⼀个符号引⽤在不同虚拟机实例上翻译出来的直接引⽤⼀般不会相同。如果有了直接引⽤，那引⽤的⽬标必定已经在虚拟机的内存中存在。

解析动作主要针对类或接⼝、字段、类⽅法、接⼝⽅法、⽅法类型、⽅法句柄和调⽤点限定符这7类符号引⽤进⾏。

初始化

类的初始化阶段是类加载过程的最后⼀个步骤，之前介绍的⼏个类加载的动作⾥，除了在加载阶段⽤户应⽤程序可以通过⾃定义类加载器的⽅式局部参与外，其余动作都完全由 ava虚拟机来主导控制。直到初始化阶段，Java虚拟机才真正开始执⾏类中编写的Java 程序代码，将主导权移交给应⽤程序。

初始化阶段就是执⾏类构造器()⽅法的过程。()并不是程序员在Java代码中直接编写的⽅法，它是Javac编译器的⾃动⽣成物。

类加载器

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

类与类加载器

类加载器虽然只⽤于实现类的加载动作，但它在Java程序中起到的作⽤却远超类加载阶段。对于任意⼀个类，都必须由加载它的类加载器和这个类本身⼀起共同确⽴其在Java虚拟机中的唯⼀性，每⼀个类加载器，都拥有⼀个独⽴的类名称空间。这句话可以表达得更通俗⼀些: ⽐较两个类是否“相等”，只有在这两个类是由同⼀个类加载器加载的前提下才有意义，否则，即使这两个类来源于同⼀个Class⽂件，被同⼀个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

双亲委派模型

站在Java虚拟机的⻆度来看，只存在两种不同的类加载器: ⼀种是启动类加载器 (Bootstrap ClassLoader)，这个类加载器使⽤C++语⾔实现，是虚拟机⾃身的⼀部分; 另外⼀种就是其他所有的类加载器，这些类加载器都由Java语⾔实现，独⽴存在于虚拟 机外部，并且全都继承⾃抽象类 java.lang.ClassLoader。

站在Java开发⼈员的⻆度来看，类加载器就应当划分得更细致⼀些。⾃JDK 1.2以来， Java⼀直保持着三层类加载器、双亲委派的类加载架构。

启动类加载器(Bootstrap Class Loader)

前⾯已经介绍过，这个类加载器负责加载存放在 \lib⽬录，或者被-Xbootclasspath参数所指定的路径中存放的，⽽且是Java虚拟机能够识别的(按照⽂件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib⽬录中也不 会被加载)类库加载到虚拟机的内存中。启动类加载器⽆法被Java程序直接引⽤，⽤户在编写⾃定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使⽤null代替即可。

扩展类加载器(Extension Class Loader)

这个类加载器是在类 sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载 \lib\ext⽬录中，或者被java.ext.dirs系统变量所指定的路径中所有的类 库。根据“扩展类加载器”这个名称，就可以推断出这是⼀种Java系统类库的扩展机制， JDK的开发团队允许⽤户将具有通⽤性的类库放置在ext⽬录⾥以扩展Java SE的功能，在 JDK 9之后，这种扩展机制被模块化带来的天然的扩展能⼒所取代。由于扩展类加载器是 由Java代码实现的，开发者可以直接在程序中使⽤扩展类加载器来加载Class⽂件。

应⽤程序类加载器(Application Class Loader)

这个类加载器由sun.misc.Launcher$Ap pClassLoader来实现。由于应⽤程序类加载器是ClassLoader类中的getSystemClassLoader()⽅法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载⽤户 类路径(ClassPath)上所有的类库，开发者同样可以直接在代码中使⽤这个类加载器。如果应⽤程序中没有⾃定义过⾃⼰的类加载器，⼀般情况下这个就是程序中默认的类加载器。

图中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents Delegation Model）”。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

双亲委派模型的⼯作过程:

如果⼀个类加载器收到了类加载的请求，它⾸先不会⾃⼰去 尝试加载这个类，⽽是把这个请求委派给⽗类加载器去完成，每⼀个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当⽗加载器 反馈⾃⼰⽆法完成这个加载请求(它的搜索范围中没有找到所需的类)时，⼦加载器才会尝试⾃⼰去完成加载。

使⽤双亲委派模型来组织类加载器之间的关系，⼀个显⽽易⻅的好处就是Java中的类随 着它的类加载器⼀起具备了⼀种带有优先级的层次关系。

代码中先检查请求加载的类型是否已经被加载过，若没有则调⽤⽗加载器的loadClass()⽅法，若⽗加载器为空则默认使⽤启动类加载器作为⽗加载器。假如⽗类加载器加载失败，抛出ClassNotFoundException异常的话，才调⽤⾃⼰的findClass()⽅法尝试进⾏加载。

破坏双亲委派模型

直到Java 模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。

1. 双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远 古”时代。由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类 java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代 码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术 手段避免loadClass()被子类覆盖的可能性，只能在JDK 1.2之后的java.lang.ClassLoader中添加一个新的 protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在 loadClass()中编写代码。上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面， 按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样 既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

2. 双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类 加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被 称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变 的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？

   为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器 （Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方 法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内 都没有设置过的话，那这个类加载器默认就是应用程序类加载器。 有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类 加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行 为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性 原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、 JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供 者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了 java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加 载提供了一种相对合理的解决方案。

3. 双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的，这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等。说 白了就是希望Java应用程序能像我们的电脑外设那样，接上鼠标、U盘，不用重启机器就能立即使用， 鼠标有问题或要升级就换个鼠标，不用关机也不用重启。对于个人电脑来说，重启一次其实没有什么 大不了的，但对于一些生产系统来说，关机重启一次可能就要被列为生产事故，这种情况下热部署就 对软件开发者，尤其是大型系统或企业级软件开发者具有很大的吸引力。