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

2,948 阅读8分钟

本文首发于个人网站,如需转载请注明来源:类加载器中的双亲委派模型,看这篇就够了

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

双亲委派模型

四种类加载器

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

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

双亲委派模型

  • 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());

    }
}

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

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

image-20191013140720888

例子3:Arthas中的classloader命令

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

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

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()方法进行设置,如果创建线程时候它还没有被设置,就会从父线程中继承一个,如果再应用程序的全局范围都没有设置过的话,那这个类加载器就是应用程序类加载器。

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

线程上下文加载器

源码分析

接下来,我们以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. www.journaldev.com/349/java-cl…
  2. www.cnblogs.com/joemsu/p/93…
  3. 《深入理解Java虚拟机》
  4. 《码出高效Java开发手册》

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

javaadu