类加载器中的双亲委派模型详解
在上一篇文章中，我们梳理了类加载器的基本概念：类的生命周期、类加载器的作用、类的加载和卸载的时机等等，这篇文章我们接着前文继续复习类加载器的知识，主要包括：JVM中有哪些类加载器？它们之间是什么关系？什么是双亲委派机制？
双亲委派模型
四种类加载器
从JVM的角度看，类加载器主要有两类：Bootstrap ClassLoader和其他类加载，Bootstrap ClassLoader是C++语言实现，是虚拟机自身的一部分；其他类加载器都是Java语言实现，不属于虚拟机，全部继承自抽象类java.lang.ClassLoader。
从Java开发者的角度看，需要了解类加载器的双亲委派模型，如下图所示：
- Bootstrap ClassLoader：启动类加载器，这个类加载器将负责存放在/lib目录中、被-Xbootclasspath参数所指定的路径中，并且是虚拟机会识别的jar类库加载到内存中。更直白点说，就是我们常用的java.lang开头的那些类，一定是被Bootstrap ClassLoader加载的。
- Extension ClassLoader：扩展类加载器，这个类加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载/lib/ext目录中的、或者被java.ext.dirs系统变量指定的路径中的所有类库。
- Application ClassLoader：应用程序类加载器，这个类加载器由sun.misc.Launcher$AppClassLoader实现，它负责加载用户CLASSPATH环境变量指定的路径中的所有类库。如果应用程序中没有自定义过自己的类加载器，这个就是一个Java程序中默认的类加载器。
- 用户自定义的类加载器：用户在需要的情况下，可以实现自己的自定义类加载器，一般而言，在以下几种情况下需要自定义类加载器：（1）隔离加载类。某些框架为了实现中间件和应用程序的模块的隔离，就需要中间件和应用程序使用不同的类加载器；（2）修改类加载的方式。类加载的双亲委派模型并不是强制的，用户可以根据需要在某个时间点动态加载类；（3）扩展类加载源，例如从数据库、网络进行类加载；（4）防止源代码泄露。Java代码很容易被反编译和篡改，为了防止源码泄露，可以对类的字节码文件进行加密，并编写自定义的类加载器来加载自己的应用程序的类。
例子1：不同的类加载器
在下面的代码中，java.util.HashMap是rt.jar包中的类，因此它的类加载器是null，DNSNameService类是放在ext目录下的jar包中的类，因此它的类加载器是ExtClassLoader；MyClassLoaderTest的类加载器就是应用类加载器。
import java.util.HashMap;
import sun.net.spi.nameservice.dns.DNSNameService;
public class MyClassLoaderTest {
public static void main(String[] args) {
System.out.println("class loader for HashMap: " + HashMap.class.getClassLoader());
System.out.println(
"class loader for DNSNameService: " + DNSNameService.class.getClassLoader());
System.out.println("class loader for this class: " + MyClassLoaderTest.class.getClassLoader());
System.out.println("class loader for Blob class: " + com.mysql.jdbc.Blob.class.getClassLoader());
}
}运行上述代码的接入过下图所示：
例子2：不同类加载器管理的文件路径
通过下面的这个程序，可以看到，每个类加载器负责的jar文件路径都不一样：
public class JVMClassLoader {
public static void main(String[] args) {
System.out.println("引导类加载器加载路径：" + System.getProperty("sun.boot.class.path"));
System.out.println("扩展类加载器加载路径：" + System.getProperty("java.ext.dirs"));
System.out.println("系统类加载器加载路径：" + System.getProperty("java.class.path"));
}
}
例子3：Arthas中的classloader命令
Arthas中提供了classloader命令，可以用来查看当前应用中的类加载器相关的统计信息，如下图所示，
- 输入classloader后展示的表格汇总了当前应用的类加载器、每个类加载器的实例个数、每个类加载器加载的类的个数。
- 输入classloader -t后，展示了当前应用中类加载器的层次结构，可以看出，BootStrap ClassLoader确实在类加载器体系的顶层，接下来是扩展类加载器，再然后是应用类加载器，这里还有一个ArthasClassLoader，是Arthas自己实现的一个自定义类加载器。
双亲委派模型的工作过程
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的Class Path中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
双亲委派模型的实现非常简单，实现双亲委派的代码在java.lang.ClassLoader的loadClass()方法之中，如下面的代码所示：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先，检查该类是否已经被加载
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器抛出ClassNotFoundException，
// 说明父类加载器无法完成加载请求
}
if (c == null) {
// 在父类加载器无法加载的时候，再调用本类的findClass方法进行类加载请求
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
// 当前类加载器是该类的define class loader
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}破坏双亲委派模型
线程上下文加载器
如上所述，双亲委派模型很好得解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），如果基础类又要回调用户的类该怎么办？一个非常经典的例子就是SQL的驱动管理类——java.sql.DriverManager。
java.sql.DriverManager是Java的标准服务，该类放在rt.jar中，因此是由启动类加载器加载的，但是在应用启动的时候，该驱动类管理是需要加载由不同数据库厂商实现的驱动，但是启动类加载器找不到这些具体的实现类，为了解决这个问题，Java设计团队提供了一个不太优雅的设计：线程上下文加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时候它还没有被设置，就会从父线程中继承一个，如果再应用程序的全局范围都没有设置过的话，那这个类加载器就是应用程序类加载器。
有了线程上下文加载器，就可以解决上面的问题——父类加载器需要请求子类加载器完成类加载的动作，这种行为实际上就是打破了双亲委派的加载规则。
源码分析
接下来，我们以java.sql.DriverManager为例，看下线程上下文加载器的用法，在java.sql.DriverManager类的下面这个静态块中，是JDBC驱动加载的入口。
/**
* Load the initial JDBC drivers by checking the System property
* jdbc.properties and then use the {@code ServiceLoader} mechanism
*/
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}顺着loadInitialDrivers()方法往下看，使用线程上下文加载器的地方在ServiceLoader.load里
private static void loadInitialDrivers() {
// ……省去别的代码
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();
try{
while(driversIterator.hasNext()) {
driversIterator.next();
}
} catch(Throwable t) {
// Do nothing
}
return null;
}
});
//…… 省去别的代码ServiceLoader.load方法的代码如下，JDBC的sqlDriverManager就是这里获得的上下文加载器来驱动用户代码加载指定的类的。
public static <S> ServiceLoader<S> load(Class<S> service) {
// 获取当前线程中的上下文类加载器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}那么这个上下文加载器是什么时候设置进去的呢？前面我们提到了：
这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时候它还没有被设置，就会从父线程中继承一个，如果再应用程序的全局范围都没有设置过的话，那这个类加载器就是应用程序类加载器。
看下setContextClassLoader()方法别谁调用了，最终我们在Launcher中找到了如下代码：
public class Launcher {
//……省去别的代码
public Launcher() {
Launcher.ExtClassLoader var1;
try {
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
Thread.currentThread().setContextClassLoader(this.loader);
//……省去别的代码
}
}总结
这篇文章我们复习了类加载器的双亲委派模型、双亲委派模型的工作过程，以及打破双亲委派模型的必要性和源码分析。在第一部分的结尾，我们还演示了Arthas中关于类加载器的命令的用法，在实际排查问题时可以考虑使用。
参考资料
- https://www.journaldev.com/349/java-classloader#java-classloader-hierarchy
- https://www.cnblogs.com/joemsu/p/9310226.html
- 《深入理解Java虚拟机》
- 《码出高效Java开发手册》
本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。
