一文搞懂“什么是双亲委派”

文章目录

双亲委派介绍
类加载器介绍
类加载流程
验证
自定义类加载器
为什么要设计这种机制

提前声明：以下介绍都是基于jdk9之前版本的双亲委派机制，jdk9及之后版本双亲委派会有变化，不在本篇介绍。

双亲委派介绍

双亲委派机制（Parent Delegation Mechanism）是Java中的一种类加载机制。在Java中，类加载器负责加载类的字节码并创建对应的Class对象。双亲委派机制是指当一个类加载器收到类加载请求时，它会先将该请求委派给它的父类加载器去尝试加载。只有当父类加载器无法加载该类时，子类加载器才会尝试加载。

这种机制的设计目的是为了保证类的加载是有序的，避免重复加载同一个类。Java中的类加载器形成了一个层次结构，根加载器（Bootstrap ClassLoader）位于最顶层，它负责加载Java核心类库。其他加载器如扩展类加载器（Extension ClassLoader）和应用程序类加载器（Application ClassLoader）都有各自的加载范围和职责。通过双亲委派机制，可以确保类在被加载时，先从上层的加载器开始查找，逐级向下，直到找到所需的类或者无法找到为止。

这种机制的好处是可以避免类的重复加载，提高了类加载的效率和安全性。同时，它也为Java提供了一种扩展机制，允许开发人员自定义类加载器，实现特定的加载策略。

类加载器介绍

上面说到了几个类加载器，小伙伴们可能有点懵，我简单介绍下3个最重要的类加载器。

Bootstrap classLoader：这个加载器是最顶层的加载器，主要加载核心类库，%JRE_HOME%\lib下的jar包，在jdk源码中其实是找不到这个类的，它是使用C/C++语言实现的，本身是虚拟机的一部分。不过能够在ClassLoader类中调用findBootstrapClass(String name)方法取得这个类，不过该方法也是native方法，看不到具体实现。
ExtClassLoader：这个是扩展的类加载器，加载目录%JRE_HOME%\lib\ext目录下的jar包。需要注意的是Bootstrap classLoader并不是ExtClassLoader严格意义上的父加载器，ExtClassLoader实例中有个变量是ClassLoader parent，这个变量的值是null。当ClassLoader执行loadClass(String name, boolean resolve)方法时，检查到parent值是null，然后会执行findBootstrapClassOrNull(String name)找到Bootstrap classLoader。
AppClassLoader：这个类加载当前应用的classpath的所有类。它的ClassLoader parent是ExtClassLoader。AppClassLoader和ExtClassLoader最顶层的父类是ClassLoader，ClassLoader是个抽象类。

类加载流程

类的加载流程用一句话简单说就是向上委托，向下查找加载。流程如下：
在这里插入图片描述
下面再用代码看一下类加载器的加载流程。

public abstract class ClassLoader {protected Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException{synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loadedClass<?> 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 thrown if class not found// from the non-null parent class loader}if (c == null) {// If still not found, then invoke findClass in order// to find the class.long t1 = System.nanoTime();c = findClass(name);// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if (resolve) {resolveClass(c);}return c;}}
}

这段代码基本上解释了前面说的类加载流程。

先是执行findLoadedClass(String)去检测这个class是不是已经加载过了。
执行父加载器的loadClass方法。如果父加载器为null，则jvm内置的加载器去替代，也就是Bootstrap ClassLoader。这也解释了ExtClassLoader的parent为null，但仍然说Bootstrap ClassLoader是它的父加载器，这里最终加载方法是一个native方法。
如果向上委托父加载器没有加载成功，则通过findClass(String)查找。

验证

上面讲了类加载的流程，那我们就写代码验证一下。

public class ClassLoaderExample {public static void main(String[] args) {//当前类加载器ClassLoader loader = ClassLoaderExample.class.getClassLoader();System.out.println(loader);//父类加载器ClassLoader parentLoader = loader.getParent();System.out.println(parentLoader);//父类的父类ClassLoader grandParentLoader = parentLoader.getParent();System.out.println(grandParentLoader);}
}

结果如下：

sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@1540e19d
null

可以看出我们自定义的类确实是由AppClassLoader加载的，而AppClassLoader的父加载器确实是ExtClassLoader，而ExtClassLoader的父加载器也确实是null。

自定义类加载器

Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

在自定义ClassLoader的子类时候，我们常见的做法是：

重写loadClass(String name)方法；
重写findclass(String name)方法；

子类重写loadClass()方法的实现最好是直接调用super.loadClass()方法，因为这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法的逻辑会导致模型被破坏，容易造成问题。当调用super.loadClass()没有加载到类时，再调用findclass()方法。

而重写findclass()方法就没那么多顾虑了，这个方法的实现就是在某个路径下发现并加载对应的类。

具体实现代码如下：

package org.example;import java.io.ByteArrayOutputStream;
import java.io.FileInputStream;
import java.io.IOException;public class MyClassLoader extends ClassLoader {private String path;private String packageName;public MyClassLoader(String path, String packageName) {this.path = path;this.packageName = packageName;}@Overridepublic Class<?> loadClass(String name) throws ClassNotFoundException {// 首先尝试使用父类加载器加载类try {return super.loadClass(name);} catch (ClassNotFoundException e) {// 如果父类加载器无法加载类，则自己加载类return findClass(name);}}@Overrideprotected Class<?> findClass(String name) throws ClassNotFoundException {// 在这里实现自己的类加载逻辑，例如从特定位置加载类文件// 这里只是一个示例，实际实现需要根据具体需求进行处理byte[] classData = loadClassData(name);if (classData == null) {throw new ClassNotFoundException();}return defineClass(packageName + name, classData, 0, classData.length);}private byte[] loadClassData(String name) {// 在这里实现加载类文件的逻辑，返回类文件的字节数组// 这里只是一个示例，实际实现需要根据具体需求进行处理try {FileInputStream fis = new FileInputStream(path + name + ".class");ByteArrayOutputStream bos = new ByteArrayOutputStream();byte[] buffer = new byte[1024];int len;while ((len = fis.read(buffer)) != -1) {bos.write(buffer, 0, len);}fis.close();bos.close();return bos.toByteArray();} catch (IOException e) {e.printStackTrace();}return null;}public static void main(String[] args) {// 创建自定义类加载器MyClassLoader classLoader = new MyClassLoader("/Users/bigfish/IdeaProjects/basic/target/classes/org/example/", "org.example.");try {// 使用自定义类加载器Class<?> clazz = classLoader.loadClass("MyClassLoader");System.out.println("加载此类的类加载器为：" + clazz.getClassLoader());System.out.println("加载此类的类加载器的父类加载器为：" + clazz.getClassLoader().getParent());} catch (ClassNotFoundException e) {System.out.println("Class not found");}}}

结果如下：

加载此类的类加载器为：org.example.MyClassLoader@1540e19d
加载此类的类加载器的父类加载器为：sun.misc.Launcher$AppClassLoader@18b4aac2

可以看出我们自定义的类加载的父类加载器为AppClassLoader，各个类加载器的调用顺序如下：

在这里插入图片描述
看到这里，也许有人会疑惑，上面代码中我们并没有把AppClassLoader作为父类加载器给自定义类加载器赋值啊，那为何父类加载器会是AppClassLoader呢？

其实是有赋值的地方的，是在ClassLoader的无参构造方法赋值的，代码如下。

protected ClassLoader(ClassLoader parent) {this(checkCreateClassLoader(), parent);
}protected ClassLoader() {this(checkCreateClassLoader(), getSystemClassLoader());
}

其中getSystemClassLoader()返回的就是AppClassLoader。

为什么要设计这种机制

最后总结一下，这种设计有个好处是，如果有人想替换系统级别的类：String.java。篡改它的实现，在这种机制下这些系统的类已经被Bootstrap classLoader加载过了（为什么？因为当一个类需要加载的时候，最先去尝试加载的就是BootstrapClassLoader），所以其他类加载器并没有机会再去加载，从一定程度上防止了危险代码的植入。