Java Class Loader
Table of Contents
1. JVM 类加载机制简介
当 Java 源文件编译为 Class 文件后， 虚拟机需要把 Class 文件加载到内存，并对数据进行校验、解析和初始化，最终形成可以被虚拟机直接使用的 Java 类型，这就是虚拟机的类加载机制。
2. 类加载的时机和过程
类从被加载到虚拟机内存到卸载出内存为止，生命周期包括加载（Loading），验证（Verification），准备（Preparation），解析（Resolution），初始化（Initialization），使用（Using）和卸载（Unloading）。如图 1 所示。
Figure 1: Java 类的生命周期
注：其中验证（Verification），准备（Preparation），解析（Resolution）这 3 个阶段属于连接（Linking）阶段。
2.1. 加载
加载过程主要完成 3 件事：
- 通过一个类的全限定名称来获取定义此类的二进制字节流（获取字节流有多种方式，如 zip 包读取、网络中获取等）；
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
- 在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据结构的访问入口。
2.2. 验证
验证是链接阶段的第一步，这个阶段目的是确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机的自身安全。
注：使用 -Xverify:none 参数可关闭大部分的类验证措施。
2.3. 准备
准备阶段是正式为类变量分配内存的阶段，这些变量所使用的内存都将在方法区中进行分配。
2.4. 解析
解析阶段是虚拟机将常量池内的“符号引用”替换为“直接引用”的过程。
符号引用：符号引用用一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义的定位到目标即可。
直接引用：直接引用可以是直接指向目标的指针、相对偏移量或者是一个能够间接定位到目标的句柄。直接引用和间接引用是和虚拟机实现的内存布局相关，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不同。如果有了直接引用，那引用的目标一定在内存中存在。
2.5. 初始化
类初始化阶段是类加载过程最后一步，此阶段才是真正执行类中定义的 Java 程序代码（或者说是字节码）。 初始化阶段是执行类构造器方法的过程。
3. 类加载器
虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到 Java 虚拟机外部去实现，以便让程序决定如何去获取所需要的类，实现这个动作的代码模块称之为“类加载器”。
类加载器最初是为了满足 Java Applet 的需求而开发出来的。虽然目前 Java Applet 技术基本上已经“死掉”，但是类加载器却在类层次划分、OSGi、热部署、代码加密等领域大放异彩，成为了 JAVA 技术体系中一块重要的基石，可谓是失之桑榆，收之东隅。
3.1. 类与类加载器
对于任意一个类，都需要由“加载它的类加载器”和“这个类本身”一同确立其在 JVM 中的唯一性。也就是说：比较两个类是否“相等”，只有在这两个类由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class 文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。
3.2. 类加载器分类
从不同的角度，可对类加载器进行不同的分类。
从 Java 虚拟机角度来讲，只存在两种不同的加载器，一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用 C++实现，是虚拟机自身的一部分；另一种就是所有其它的类加载器，这些类加载都都由 Java 实现，独立于虚拟机外部，并且全部继承自抽象类 java.lang.ClassLoader。
从 Java 开发人员的角度来看，类加载器可以分为 3 种：
- 启动类加载器（Bootstrap ClassLoader），它负责将存放在<JAVA_HOME>\lib 目录中的，或者被
-Xbootclasspath参数所指定的路径中的类库加载到虚拟机中。 - 扩展类加载器（Extension ClassLoader），该加载器由
sun.misc.Launcher$ExtClassLoader实现（继承自抽象类 java.lang.ClassLoader），它负责将存放在<JAVA_HOME>\lib\ext 目录中的，或者被java.ext.dirs系统变量所指定的路径中的所在类库。 - 应用程序类加载器（Application ClassLoader），该加载器由
sun.misc.Launcher$AppClassLoader实现（继承自抽象类 java.lang.ClassLoader），该类加载器负责加载用户类路径上所指定的类库。开发者可通过 ClassLoader 中的 getSystemClassLoader()方法直接获取，故又称为“系统类加载器”。当应用程序没有自定义类加载器时，默认采用该类加载器。
3.3. 双亲委派模型
Parents Delegation Model（双亲委派模型，注：翻译为“父辈代理模型”可能更加容易理解）是 Java 设计者推荐给开发者的一种类加载器实现方式，它并不是一个强制性的约束模型。
图 2 展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。
Figure 2: 类加载器树状组织结构示意图（双亲委派模型）
双亲委派模型的工作过程为： 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类 java.lang.Object，它存放在 rt.jar 之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为 java.lang.Object 的类，并放在程序的 ClassPath 中，那系统中将会出现多个不同的 Object 类，Java 类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
双亲委派模型对于保证 Java 程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派模型的代码在 java.lang.ClassLoader 的 loadClass()方法之中，代码片断如下：
// 双亲委派模型的实现
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器抛出 ClassNotFoundException
// 说明父类加载器无法完成加载请求
}
if (c == null) {
// 在父类加载器无法加载的时候
// 再调用本身的findClass方法来进行类加载
c = findClass(name)
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
3.3.1. 实例：找到类加载器及所有父加载器
每个 Java 类都维护着一个指向定义它的类加载器的引用，通过 getClassLoader() 方法就可以获取到此引用。通过递归调用 getParent() 方法可以输出全部的父类加载器。
public class ClassLoaderTree {
public static void main(String[] args) {
ClassLoader loader = ClassLoaderTree.class.getClassLoader();
while (loader != null) {
System.out.println(loader.toString());
loader = loader.getParent();
}
}
}
上面代码可能输出：
sun.misc.Launcher$AppClassLoader@659e0bfd sun.misc.Launcher$ExtClassLoader@6d06d69c
3.3.2. 实例：实现类加载器
要实现自己的类加载器，可以重写 java.lang.ClassLoader 中的 loadClass(String name) 方法，不过 JDK1.2 以后不提倡用户再去重写 loadClass() 方法，而应把自己的类加载逻辑放到 findClass() 方法中，在 loadClass() 方法逻辑中如果父类加载失败，则会调用自己的 findClass() 方法来完成加载。这样才能保证类加载器都正确实现双亲委派模型。
下面是一个文件系统类加载器的例子（代码摘自：深入探讨 Java 类加载器）：
public class FileSystemClassLoader extends ClassLoader {
private String rootDir;
public FileSystemClassLoader(String rootDir) {
this.rootDir = rootDir;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException { // 重写ClassLoader的loadClass方法
byte[] classData = getClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
}
else {
return defineClass(name, classData, 0, classData.length);
}
}
private byte[] getClassData(String className) {
String path = classNameToPath(className);
try {
InputStream ins = new FileInputStream(path);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 4096;
byte[] buffer = new byte[bufferSize];
int bytesNumRead = 0;
while ((bytesNumRead = ins.read(buffer)) != -1) {
baos.write(buffer, 0, bytesNumRead);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
private String classNameToPath(String className) {
return rootDir + File.separatorChar
+ className.replace('.', File.separatorChar) + ".class";
}
}
3.3.3. 线程上下文加载器（Context Class Loader）
双亲委派很好的解决了各个类加载器基础类的统一问题，但是基础类要是需要回调用户的代码这样就容易出问题了，典型的就是服务提供者接口（Service Provider Interface，SPI），它允许第三方为这些接口提供实现。
按照双亲委派模型，SPI 的接口是 Java 核心库的一部分，由启动类加载器来加载；SPI 实现的 Java 类一般是由系统类加载器来加载的。但启动类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。所以，双亲委派模型在这个场景下无法工作。
为了解决这个问题，引入了另外一个类加载器：线程上下文类加载器，可通过 Thread.setContextClassLoader()设置。使用线程上下文类加载器（而不是使用启动类加载器！）来加载 SPI 接口相关代码，这样就可以成功地加载 SPI 实现相关类。
3.4. Class.forName
Class.forName 是一个静态方法，可以用来加载类。该方法有两种形式： Class.forName(String name, boolean initialize, ClassLoader loader) 和 Class.forName(String className) 。第一种形式的参数 name 表示的是类的全名；initialize 表示是否初始化类；loader 表示加载时使用的类加载器。第二种形式则相当于设置了参数 initialize 的值为 true，loader 的值为当前类的类加载器。
Class.forName 常用于加载数据库驱动，如
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
可加载 Apache Derby 数据库的驱动。
4. 类加载实例
4.1. Tomcat 类加载器
主流的 Java Web 服务器，如 Tomcat、Jetty、WebLogic、WebSphere 等都实现了自己定义的类加载器。这是因为一个功能健全的 Web 服务器，要解决如下几个问题：
（1）部署在同一服务器上的两个 Web 应用程序所使用的 Java 类库可以实现相互隔离。这是最基本的需求，两个不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求一个类库在一个服务器中只有一份，服务器应当可以保证两个应用程序的类库可以相互独立使用。
（2）部署在同一个服务器上的两个 Web 应用程序所使用的 Java 类库可以相互共享，这个需求也很常见，例如用户可能有 10 个使用 Spring 组织的应用程序部署在同一台服务器上，如果把 10 分 Spring 分别放在各个应用程序的隔离目录中，将会是很大的资源浪费——这主要倒不是浪费磁盘空间的问题，而是指类库在使用时都要被加载到服务器内存，如果类库不能共享，虚拟机的方法区很容易就会出现过度膨胀的危险。
（3）服务器需要尽可能的保证自身的安全不受部署的 Web 应用程序影响，目前，很多主流的 Java Web 服务器自身也是使用 Java 语言来实现的，因此服务器本身也有类库依赖问题，一般来说，基于安全考虑，服务器所使用的类库应该与应用程序的类库互相独立。
（4）支持 JSP 应用的 web 服务器，十有八九都需要支持 HotSwap 功能，我们知道 JSP 文件最终要被编译成 Java Class 文件才能被虚拟机执行，但 JSP 文件由于其纯文本存储的特性，被运行时修改的概率远远大于第三方类库或程序自己的 Class 文件，而且 ASP、PHP、JSP 这些网页应用也把修改后无须重启作为一个很大的“优势”来看待，因此“主流”Web 服务器都会支持 JSP 生成类的热替换，当然也有“非主流”，如运行在生产模式下的 WebLogic 服务器默认就不会处理 JSP 文件的变化。
由于上述存在的问题，在部署 Web 应用时，单独的一个 ClassPath 就无法满足需求了，所以各种 Web 服务器都不约而同提供了好几个 ClassPath 路径用户存放第三方类库，这些路径一般都以“lib”或“classess”命名，被放置到不同路径中的类库，具备不同的访问范围和服务对象，通常，每一个目录都会有一个相应的自定义类加载器去加载放置在里面的 Java 类库，那么 Tomcat 是如何规划用户的类库结构和类加载器的？Tomcat 启动时会创建一系列的类加载器：
Bootstrap
|
System
|
Common
/ \
Webapp1 Webapp2 ...
5. 参考
本文主要摘自《深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)》第7章，虚拟机类加载机制