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

时间  2019-11-06
标签 加载 双亲 委派 模型 详解 繁體版
原文   原文链接

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

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

双亲委派模型

四种类加载器

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

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

双亲委派模型

  • Bootstrap ClassLoader：启动类加载器，这个类加载器将负责存放在<JAVA_HOME>/lib目录中、被-Xbootclasspath参数所指定的路径中，而且是虚拟机会识别的jar类库加载到内存中。更直白点说，就是咱们经常使用的java.lang开头的那些类，必定是被Bootstrap ClassLoader加载的。sql

  • 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的类加载器就是应用类加载器。app

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
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程