【双亲委派机制详解】

最新推荐文章于 2023-09-28 15:42:06 发布

Memory_zk

最新推荐文章于 2023-09-28 15:42:06 发布

阅读量588

点赞数 1

文章标签： java jvm

本文链接：https://blog.csdn.net/qq_44316957/article/details/127300983

版权

定义

双亲委派机制是JDK1.2时引入的，主要是为了 避免重复加载 及 安全性。

当一个类加载器需要加载类的时候，它会先检查是否已经加载过，如果没有的话，会直接交给父加载器去加载，而父加载器又委托给根加载器加载，当根加载器和父加载器都无法加载时，才会由自己去加载。其实本身使用了递归去做处理。

类加载器

在Java中，提供了三种类加载器，分别加载不同路径的Class文件（我们也可以自定义类加载器，指定其加载路径）：

BootstrapClassLoader：启动类加载器

主要加载核心的类库 [JAVA_HOME/jre/lib] (java.lang.*等)，比如我们用的String、Object都是其加载的，以及构造ExtClassLoader和AppClassLoader。并且该类加载器是由C++写的。

ExtClassLoader：(ExtensionClassLoader) 扩展类加载器

主要负责加载 [JAVA_HOME/jre/lib/ext]目录下的一些扩展的jar包。

AppClassLoader：(ApplicationClassLoader) 应用类加载器

主要负责加载当前应用下的所有类以及引入的依赖包。

先来看看是不是这样加载的：

在这里插入图片描述

首先，我们可以看到：

加载SpringApplication类的类加载器是AppClassLoader。（Spring是我们引入的依赖包）
加载EventQueueMonitor类的类加载器是ExtClassLoader。（EventQueueMonitor类存在于JAVA_HOME\jre\lib\ext的 jaccess.jar包内）
加载String类的类加载器是null，是因为BootstrapClassLoader是C++写的，在Java不是对象。（String类是属于JAVA_HOME\jre\lib的 rt.jar包内）

由此，可以看出，确实分工明确，各个加载器各自加载不同路径的class文件。
而我们回归主题，双亲委派在其中做了什么工作呢？我们接着看。

双亲委派

双亲委派的定义在上文中已经简单赘述，它是如何实现的，我们看源码：

首先我们找到AppClassLoader和ExtClassLoader共同的基类ClassLoader，找到其中的核心方法loadClass()。
在该方法的注释上，我们看到一段：

Invoke findLoadedClass(String) to check if the class has already been loaded.
Invoke the loadClass method on the parent class loader. If the parent is null the class loader built-in to the virtual machine is used, instead.
Invoke the findClass(String) method to find the class.

大概意思是：

首先，调用findLoadedClass()来检查类是否已经加载。
接着，在父类加载器上调用loadClass方法。如果父类为空，则使用虚拟机内置的类装入器。
最后调用findClass(String)方法来查找类。

在这里插入图片描述

图片引用自双亲委派机制

什么意思呢？我们看源码就懂了：

1. 首先在第一行，判断类有没有被加载

Class<?> c = findLoadedClass(name);

2. 如果没有被加载，则表示先将其委托给父加载器加载。

3. 而父加载器若是不为空，则会调用父加载器的loadClass()方法。

if (parent != null) {
    c = parent.loadClass(name, false);
}

这不就是递归吗！而我们也可以查看下ExtClassLoader类，发现并没有重写loadClass()方法，所以，类加载器一直调用的都是同一个逻辑。

4. 而如果没有找到父加载器的话，说明已经到顶了，直接调用根加载器去加载

c = findBootstrapClassOrNull(name);

5. 最终，如果都没有加载成功的话，则递归结束，向下传递，通过下面的类加载器去加载

if (c == null) {
    // If still not found, then invoke findClass in order
    // to find the class.
    long t1 = System.nanoTime();
    c = findClass(name);
}

简单来说，逻辑大体如下：

首先AppClassLoader尝试加载，调用loadClass()方法。（++AppClassLoader重写了该方法，但是前面几乎都是在做校验。++）
在方法中，首先查看该类是否已经加载。
如果未加载，则不会立即加载，而是委托给父类加载器ExtClassLoader去加载。
而ExtClassLoader也是一样，检查该类是否加载过，如果没有则委托父类加载器去加载。
但是对于ExtClassLoader来说，它没有父类加载器，parent为空，为空的话，则直接委托给BootstrapClassLoader去加载。所以也可以说BootstrapClassLoader是ExtClassLoader的父类加载器。
而如果BootstrapClassLoader加载不了，则会回到ExtClassLoader，由ExtClassLoader执行findClass()方法尝试加载。
而如果加载不了，则会继续回到AppClassLoader，调用其findClass()方法进行加载。