【JVM系列读书笔记】四、虚拟机类加载机制

注：本文主要参考《深入理解Java虚拟机 第2版》

1、概述

Java语言经编译器编译为Class文件后，虚拟机如何加载这些Class到内存中，并使用，这个就需要了解虚拟机类加载机制。

2、通过类加载机制解决 "Class Not Found" 问题

在刚毕业时，接手了一个“祖传”，需求是将此项目中依赖的一个tool.jar包中一个方法的功能修改，重新部署即可。

这个项目思路比较简单，将tool-1.0.jar 版本源码导入IDE中，然后照需求修改打包为tool-2.0.jar，导入“祖传项目”，本地运行都正常。但是上线了运行，tool-2.0.jar新的代码没有生效。

尝试了对比项目中tool-2.0.jar包的MD5与本地打包的一致，以及在tool-2.0.jar中新增的日志，都没有解决。

于是，通过打印jar包中类的加载绝对路径，发现打印的是在tomcat的目录下有个tool-1.0.jar包，最后才解决到此tomcat中还有其他项目也依赖tool-1.0.jar包，所以为了节省tomcat的内存将公共的jar包放到了tomcat的lib目录下。

后面了解到了虚拟机的类加载机制，才知道是双亲委派模型导致代码中的tool-2.0.jar包无法加载成功，因此我们进入正题，了解虚拟机类加载机制。

3、虚拟机类加载机制

从类被加载到虚拟机内存中开始，到卸载出内存位置，它的整个生命周期包括如下7个阶段：

1. 加载（Loading），主要完成以下3件事：
   1. 通过一个类的全限定名来获取定义此类的二进制字节流；
   2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
   3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；
2. 验证（Verification），为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害自身的安全，大致有4个阶段的检验动作：
   1. 文件格式验证，验证是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，如魔数是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内等；
   2. 元数据验证，对字节码描述的信息进行语义分析，以保证其描述信息符合Java语言规范，如这个类是否有父类、是否继承了不被允许继承的类等；
   3. 字节码验证，主要是同数据流和控制流分析，确认程序语义是合法的，符合逻辑的；
   4. 符号引用验证，可以看做对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验，如符号引用中通过字符串描述的全限定名是否能找到对应的类；
3. 准备（Preparation）， 是正式为类比那里分配内存，并设置类变量初始值的阶段这些比那里所使用的内存都将在方法区中进行分配；
4. 解析（Resolution），是虚拟机将常量池内的符号引用替换为直接引用的过程；
5. 初始化（Initialization），初始化阶段虚拟机规范中严格规定了有且只有一下5种情况会立即对类进行初始化：
   • 遇到new（使用new关键字）、getstatic（获取静态字段）、putstatic（设置静态字段）、invokestatic（调用静态方法）这4个字节码指令时，如果类没有进行过初始化，则需要先行触发其初始化；
   • 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化；
   • 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类初始化；
   • 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类；
   • 当使用JDK1.7的动态语言支持时，如果一个java.lang.invokeMethodHandle示例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄、并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化；
6. 使用（Using）;
7. 卸载（Unloading）；

而其中的验证+准备+解析三个阶段统称为连接，其中加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序进行，但是解析阶段则不一定，因为再某些情况下可以在初始阶段之后再开始，这是为了支持Java语言的动态绑定。

4、类加载器与双亲委派模型

4.1、类加载器

类是被类加载器加载到虚拟机内存中的，而类加载器是指：实现“通过一个类的全限定命令来获取描述此类的二进制字节流”这一动作的代码。

在Java虚拟机的角度来看，只有两种不同的类加载器：

1. 启动类加载器（Bootstrap ClassLoader），使用C++语言实现，是虚拟机自身的一部分；
2. 所有其他的类加载器，是有Java语言实现，独立于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader；

而在Java开发人员的角度讲，绝大部分程序有如下3中系统提供的类加载器：

1. 启动类加载器（Bootstrap ClassLoader），与前面描述的是同一个，负责加载存放于<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路劲各种的，并且是虚拟机能识别的类库加载到虚拟机内存中；
2. 扩展类加载器（Extension ClassLoader），这个加载器由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的类库，开发者可以直接使用扩展类加载器；
3. 应用程序类加载器（Application ClassLoader）：这个类加载器由sun.miscLauncher$AppClassLoader实现，由于此加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般称为系统类加载器，负责加载用户类路径（ClassPath)上所指定的类库，开发者有直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是炒年糕小中默认的类加载器；

4.2、双亲委派模型

4.1小节所讲的类加载器，相互配合进行加载，如果有必要，还可以加入用户自定义的类加载器，它们之间组成的层次模型被称为“类加载器的双亲委派模型（Parents Delegation Model）”，如下图所示：

图中的模型，处理顶层的启动类加载器之外，其余加载器都应该有自己的父类加载器。双亲委派模型的工作流程如下：一个类加载器收到了类加载的请求，自己不会直接进行尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载需求（它的搜索范围没有找到所需的类），子加载器才会尝试自己去加载。

使用双亲委派模型的优势是可以保证Java程序的文档运行，不会出现同一个类加载多次的情况。

5、小结

双亲委派模型对于我们了解类的加载过程具有非常大的帮助，它并不是一个强制的约束模型，但是可以给我们很多启发。对于OSGi的类加载器更为复杂，后续需要继续学习，双亲委派模型则是基础。