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

提前声明：以下介绍都是基于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 loaded
	        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 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 stats
	                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
	                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
	                sun.misc.PerfCounter.getFindClasses().increment();
	            }
	        }
	        if (resolve) {
	            resolveClass(c);
	        }
	        return c;
	    }
	}
}

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

1. 先是执行findLoadedClass(String)去检测这个class是不是已经加载过了。
2. 执行父加载器的loadClass方法。如果父加载器为null，则jvm内置的加载器去替代，也就是Bootstrap ClassLoader。这也解释了ExtClassLoader的parent为null，但仍然说Bootstrap ClassLoader是它的父加载器，这里最终加载方法是一个native方法。
3. 如果向上委托父加载器没有加载成功，则通过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的子类时候，我们常见的做法是：

1. 重写loadClass(String name)方法；
2. 重写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;
    }

    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        // 首先尝试使用父类加载器加载类
        try {
            return super.loadClass(name);
        } catch (ClassNotFoundException e) {
            // 如果父类加载器无法加载类，则自己加载类
            return findClass(name);
        }
    }

    @Override
    protected 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），所以其他类加载器并没有机会再去加载，从一定程度上防止了危险代码的植入。

---

• 个人公众号
  
• 个人小游戏