正文Java类加载器( CLassLoader ) 死磕 4: 神秘的双亲委托机制

Posted 2021-01-13 crazymakercircle

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了正文Java类加载器( CLassLoader ) 死磕 4: 神秘的双亲委托机制相关的知识，希望对你有一定的参考价值。

【正文】Java类加载器( CLassLoader ) 死磕4:

神秘的双亲委托机制

本小节目录

4.1. 每个类加载器都有一个parent父加载器
4.2. 类加载器之间的层次关系
4.3. 类的加载次序
4.4 双亲委托机制原理与沙箱机制
4.5. forName方法和loadClass方法的关系
4.6. 使用组合而不用继承
4.7. 各种不同的类加载途径

4.1.每个类加载器都有一个parent父加载器

每个类加载器都有一个parent父加载器，比如加载SystemConfig.class是由AppClassLoader完成，那么AppClassLoader也有一个父加载器，怎么样获取呢？很简单，通过getParent方法。

这里写了一个公共的函数，来取得一个类的加载器的双亲树。代码如下：

    /**

     * 迭代，显示class loader 和 父加载器
     */

    public static void showLoaderTree(ClassLoader loader) {

        while (loader != null) {

            Logger.info(loader.toString());

            loader = loader.getParent();

        }

    }

这个函数，不断循环，向上显示了父亲、父亲的父亲、父亲的父亲的父亲..，直到为空。

这样，就展示了一棵类加载器的双亲树。

使用上面的函数，演示代码如下：

 private static void loaderTreeDemo() throws ClassNotFoundException

    {

        String className = "com.crazymakercircle.config.SystemConfig";

        Class<?> aClass = Class.forName(className);

        ClassLoader aLoader=aClass.getClassLoader();

Logger.info("加载器:"+aLoader.toString());

        ClassLoaderUtil.showLoaderTree(aLoader);

    }

案例路径：com.crazymakercircle.classLoaderDemo.base.ParentTreeDemo

案例提示：无编程不创客、无案例不学习。切记，一定要跑案例哦

案例结果如下：

loaderTreeDemo |>  加载器:[email protected]

  showLoaderTree |>  [email protected]

  showLoaderTree |>  [email protected]

这个说明，当前加载器类型为AppClassLoader，而AppClassLoader父加载器类是ExtClassLoader。ExtClassLoader的父加载器，又是谁呢？没有了打印。

parent为空表示什么意思呢？

我们先来梳理一下加载器之间的层次关系。

4.2. 类加载器之间的层次关系

下面展示一下Bootstrap 启动类加载器、Extention标准扩展类加载器和App应用类加载器三者之间的关系。

大致整理了如下类似的一幅图片：

每一个加载器看护一块自己的地盘。启动Bootstrap 看护的是核心中的核心地盘。

前面讲到，ExtClassLoader的父加载器为空。而上图中，ExtClassLoader的父加载器是Bootstrap 启动类加载器。

实际上，如果一个加载器的parent为空，其父亲加载器就是Bootstrap 启动类加载器。

如果没有特别的设置，自定义加载的parent，默认为App应用加载器。

4.3. 类的加载次序

loadClass 关键源代码，已经在前面有介绍。

下面用一张图，对于类的加载次序，做进一步的介绍。

一般场景下，加载一个类，是从AppClassLoader开始的。

基本的步骤如下：

（1）AppClassLoader查找资源时，不是首先查看自己的地盘是否有这个字节码文件，而是直接委托给父加载器ExtClassLoader。当然，这里有一个假定，就是在AppClassLoader的缓存中，没有找到目标class。比方说，第一次加载一个目标类，这个类是不会在缓存的。

（2）ExtClassLoader查找资源时，也不是首先查看自己的地盘是否有这个字节码文件，而是直接委托给父加载器BootstrapClassLoader。

（3）如果父加载器BootstrapClassLoader在其地盘找到，并且加载成功，则直接返回了；反过来，如果在JVM的核心地盘——%sun.boot.class.path% 中没有找到。则回到ExtClassLoader查找其地盘。

（4）如果父加载器ExtClassLoader在自己的地盘找到，并且加载成功，也直接返回了；反过来，如果在ExtClassLoader的地盘——%java.ext.dirs% 中没有找到。则回到AppClassLoader自己的地盘。

（5）于是乎，逗了一大圈，终于回到了自己的地盘。还附带了两条件，就是前面的老大们没有搞定，否则也没有AppClassLoader啥事情了。

（6）AppClassLoader在自己的地盘找到，这个地盘就是%java.class.path%路径下查找。找到就返回。

（7）最终，如果没有找到，就抛出异常了。

这个过程，就是一个典型的双亲委托机制的一次执行流程。

什么是双亲委托机制呢？

4.4. 双亲委托机制原理与沙箱机制

双亲委派模型的的原理是：

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

为什么要使用这种双亲委托模式呢？

因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。

双亲委托机制，也就构成了JVM 的类的沙箱机制。

沙箱机制是由基于双亲委派机制上采取的一种JVM的自我保护机制，假设你要写一个java.lang.String 的类，由于双亲委派机制的原理，此请求会先交给Bootstrap试图进行加载，但是Bootstrap在加载类时首先通过包和类名查找rt.jar中有没有该类，有则优先加载rt.jar包中的类，因此就保证了java的运行机制不会被破坏。