类加载器中的双亲委派模型详解

2021-07-06 01:07:13

在上一篇文章中，我们梳理了类加载器的基本概念：类的生命周期、类加载器的作用、类的加载和卸载的时机等等，这篇文章我们接着前文继续复习类加载器的知识，主要包括：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面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。

码农公寓