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

迷南。 2021-09-10 10:14 265阅读 0赞

> 本文首发于个人网站，如需转载请注明来源：[类加载器中的双亲委派模型，看这篇就够了][Link 1]

在上一篇文章中，我们梳理了[类加载器的基本概念][Link 2]：类的生命周期、类加载器的作用、类的加载和卸载的时机等等，这篇文章我们接着前文继续复习类加载器的知识，主要包括：JVM中有哪些类加载器？它们之间是什么关系？什么是双亲委派机制？

## 双亲委派模型 ##

### 四种类加载器 ###

从JVM的角度看，类加载器主要有两类：Bootstrap ClassLoader和其他类加载，Bootstrap ClassLoader是C++语言实现，是虚拟机自身的一部分；其他类加载器都是Java语言实现，不属于虚拟机，全部继承自抽象类java.lang.ClassLoader。

从Java开发者的角度看，需要了解类加载器的双亲委派模型，如下图所示：

![44770-8725208151697d31.png][]

双亲委派模型

*  Bootstrap ClassLoader：启动类加载器，这个类加载器将负责存放在<JAVA\_HOME>/lib目录中、被-Xbootclasspath参数所指定的路径中，并且是虚拟机会识别的jar类库加载到内存中。更直白点说，就是我们常用的java.lang开头的那些类，一定是被Bootstrap ClassLoader加载的。
 *  Extension ClassLoader：扩展类加载器，这个类加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA\_HONME>/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());
    
        }
    }

运行上述代码的接入过下图所示：

![44770-3885ec152b46fc78.png][]

image-20191013141845449

### 例子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"));
        }
    }

![44770-b7bcf2409a4c1aa9.png][]

image-20191013140720888

### 例子3：Arthas中的classloader命令 ###

**Arthas**中提供了classloader命令，可以用来查看当前应用中的类加载器相关的统计信息，如下图所示，

1.  输入classloader后展示的表格汇总了当前应用的类加载器、每个类加载器的实例个数、每个类加载器加载的类的个数。
2.  输入classloader -t后，展示了当前应用中类加载器的层次结构，可以看出，BootStrap ClassLoader确实在类加载器体系的顶层，接下来是扩展类加载器，再然后是应用类加载器，这里还有一个ArthasClassLoader，是Arthas自己实现的一个自定义类加载器。

![44770-5f09307da0bded59.png][]

image-20191013135633962

## 双亲委派模型的工作过程 ##

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是**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()方法进行设置，如果创建线程时候它还没有被设置，就会从父线程中继承一个，如果再应用程序的全局范围都没有设置过的话，那这个类加载器就是应用程序类加载器。

有了线程上下文加载器，就可以解决上面的问题——父类加载器需要请求子类加载器完成类加载的动作，这种行为实际上就是打破了双亲委派的加载规则。

![44770-e80d333a73876c25.png][]

线程上下文加载器

### 源码分析 ###

接下来，我们以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中关于类加载器的命令的用法，在实际排查问题时可以考虑使用。

## 参考资料 ##

1.  [https://www.journaldev.com/349/java-classloader\#java-classloader-hierarchy][https_www.journaldev.com_349_java-classloader_java-classloader-hierarchy]
2.  [https://www.cnblogs.com/joemsu/p/9310226.html][https_www.cnblogs.com_joemsu_p_9310226.html]
3.  《深入理解Java虚拟机》
4.  《码出高效Java开发手册》

--------------------

本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。

![44770-4e61421679e2d7b2.png][]

javaadu

[Link 1]: https://links.jianshu.com/go?to=http%3A%2F%2Fwww.javaadu.online%2F%3Fp%3D510
[Link 2]: https://links.jianshu.com/go?to=http%3A%2F%2Fwww.javaadu.online%2F%3Fp%3D429
[44770-8725208151697d31.png]: /images/20210804/a726bb34956c42379ec2795d6293f6b8.png
[44770-3885ec152b46fc78.png]: /images/20210804/e06df0309a6c45148e11d8edca10ce1b.png
[44770-b7bcf2409a4c1aa9.png]: /images/20210804/4755552c2a61468ba09acbad986342e1.png
[44770-5f09307da0bded59.png]: /images/20210804/36496d1dc68a478db65eb595c86e9042.png
[44770-e80d333a73876c25.png]: /images/20210804/4008cb845e3a497c92c77c543848088e.png
[https_www.journaldev.com_349_java-classloader_java-classloader-hierarchy]: https://links.jianshu.com/go?to=https%3A%2F%2Fwww.journaldev.com%2F349%2Fjava-classloader%23java-classloader-hierarchy
[https_www.cnblogs.com_joemsu_p_9310226.html]: https://links.jianshu.com/go?to=https%3A%2F%2Fwww.cnblogs.com%2Fjoemsu%2Fp%2F9310226.html
[44770-4e61421679e2d7b2.png]: /images/20210804/367f34ba37404bd09b9fdb32f3764811.png