了解了双亲委派机制是什么之后，一直纠结为什么这里要叫“双亲”，于是乎上网查了一些资料，大部分都说是翻译的问题，除此之外，其中一篇博客中提到了另一种见解，可以作为参考理解。
 
“双亲委派”一词的由来 – 业余草
 
“双亲委派”这个词估计也就是翻译错误的问题，或者是这样一种可能性。相对于AppClassLoader，即应用程序类加载器。它加载我们项目（工程）下的 CLASSPATH 路径下的类，它会委托 ExtClassLoader 标准扩展（Extension）类加载器（也有称作扩展类加载器），这时 ExtClassLoader 会再次委派 BootstrapClassLoader 启动类加载器。BootstrapClassLoader 是 Java 虚拟机的第一个类加载器，它不能再向上委托了。因此，根据这个过程，我们发现一共委托了两次，所以“双亲委派”中有一个双。而“亲”字，在中国代表的是亲人的意思，而委托两次，都是交给父类来处理，因此都算得上叫亲人。所以“双亲委派”中的双亲应该就是这样来的。
 
 
总结（对 Parents Delegation Model 翻译为的 双亲委派机制 理解）：
 
1. 翻译的问题，parents 翻译为父母，即双亲
 
2. AppClassLoader 向上委托了两次，即“双”，“亲”代表亲人的意思
 
3. 可以直接理解成父委派模型
 
 
如果你还有不同的观点，欢迎留言讨论哦！

原文链接：https://mp.weixin.qq.com/s/6nJ-6cDLW6TfysWV5ZB3Iw
 作者：三太子敖丙
 
大家在开发过程中经常碰到一些类加载的问题，比如：
 
ClassNotFoundException
 
Cause: java.lang.ClassNotFoundException: Cannot find class: com.cc.A
 
NoClassDefFoundError
 
Cause: java.lang.NoClassDefFoundError: Cannot find class: com.cc.A
 
上述问题均和java类加载有关，如果不清楚JVM中类加载的原理，上述问题会让人郁闷至极，侥幸在网上找到解决方案也只是暂时解决问题，后续在另外的场景中碰到又会继续懵逼。
 
我这篇文章将对 Java 类加载器的双亲委派加载原理进行阐述，并结合实例程序深究类的双亲委派加载机制，大家彻底了解掌握类加载原理，清楚了类加载原理后，碰到上述类似问题就能快速解决，并在后续开发中避免类似问题。
 
什么是Java类加载？
 
java类加载器负责将编译好的 Java class 件加载到 Java 虚拟机（JVM）中的运行时数据区中，供执行引擎调用。
 
java类加载在JVM体系结构中的位置如图所示：
 
 
没有类加载机制，编写的java程序就没法在JVM中运行，因此掌握java类加载是非常重要的。
 
JVM类加载层级关系
 
执行java程序时，会启动一个JVM进程，JVM在启动时会做一些初始化操作，比如获取系统参数等等，然后创建一个启动类加载器，用于加载JVM运行时必须的一些类到内存中，同时也会创建其他两个类加载器扩展类加载器和系统类加载器。
 
启动类加载器、扩展类加载器和系统类加载器之间的关系如下图所示：
 
 
 
**启动类加载器：**java虚拟机启动后创建的第一个类加载器，由C++语言实现，所以我们在java代码中查看其信息时，看到的均为null。
 
 
扩展类加载器：由启动类加载器加载，并将扩展类加载器中的parent的值设置为null（表示指向启动类加载器），同时继承自URLClassLoader。
 
 
系统类加载器：由启动类加载器加载，并将系统类加载期中的parent的值设置为上述创建的扩展类加载器。，同时继承自URLClassLoader。
 
在代码中可以通过如下方式查看类加载中的parent指向：
 
 
代码查看类加载器的parent
 
注意：这里的parent不是java的继承机制，而是类加载器中的一个实例属性，用于在类加载时的委托对象，parent属性定义在其所继承的ClassLoader中，定义如下所示。
 
public abstract class ClassLoader {
   ....................
    // The parent class loader for delegation
    private final ClassLoader parent;
 
JVM类加载的默认加载路径
 
每种类型的类加载器默认都会有自己的加载路径，启动类加载器、扩展类加载器和系统类加载器的默认加载路径如下图所示：
 
三种类加载器的加载路径
 
 
 
 
如上图所示：
 
1、启动类加载器（BootClassLoader）由C++语言编写，负责在JVM启动时加载jdk自身的一些核心class类（jar包形式）到JVM中，加载时寻找资源的路径由只读系统属性：”sun.boot.class.path“ 指定，一般为：”JAVA_HOME/jre/classes“目录（在该目录下只能放class文件，jar包形式文件不生效）。
 
查看启动类加载类加载路径可以通过获取系统属性：”sun.boot.class.path“进行查看，如图所示：
 
lancher中设置启动类加载路径
 
 
启动类加载器加载路径
 
 
 
 
2、扩展类加载器(ExtClassLoader)，负责加载位于系统属性："java.ext.dirs"指向的目录下加载class文件（jar包或者直接class文件形式）到JVM中，比如通常ext类加载路径为：”$JAVA_HOMEx/jre/lib/ext“ 。
 
支持在JVM启动之前进行修改路径，运行中修改路径不生效，扩展类路径中仅支持jar包的加载。
 
查看扩展类加载器的类加载路径可以通过获取系统属性：”java.ext.dirs“进行查看或向上转型为URLClassLoader（上面说扩展类加载器继承自URLClassLoader），查看位于父类URLClassLoader中urls属性的方式进行查看，如图所示：
 
扩展类加载器路径
 
 
3、系统类加载器（AppClassLoader），负责加载应用classpath路径下的class文件（jar包或者直接class文件形式）到JVM中，当系统中没有设置classpath路径时，默认加载当前路径下的class文件。
 
查看系统类加载器的类加载路径可以通过获取系统属性：”java.class.path“进行查看或向上转型为URLClassLoader上面说扩展类加载器继承自URLClassLoader），查看位于父类URLClassLoader中urls属性的方式进行查看，如图所示：
 
系统类加载路径
 
 
 
 
JVM类加载双亲委托机制
 
JVM加载class类文件到虚拟机时，默认首先采用系统类加载器去加载用到的class类，采用的是双亲委托加载机制。
 
所谓双亲委托，顾名思义，就是当前类加载器(以系统类加载器为例)在加载一个类时，委托给其双亲（注意这里的双亲指的是类加载器中parent属性指向的类加载器）先进行加载。
 
双亲类加载器在加载时同样委托给自己的双亲，如此反复，直到某个类加载器没有双亲为止（通常情况下指双亲为null，也即为当前的双亲为扩展类加载器，其parent为启动类加载器），然后开始在依次在各自的类路径下寻找、加载class类。
 
如下图所示：
 
双亲委派
 
 
 
 
双亲委托加载实例
 
实例采用JDK版本
 
 
 
java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12， mixed mode)
 
 
本实例涉及到两个类：TestMain.java 和 A.java，期中TestMain为启动类，在启动类中调用类A中的方法执行进行输出，分别输出启动类和被依赖类的类加载器信息，类定义如下所示：
 
 
 
我们将两个java文件拷贝到某个目录下，在我本地比如放在E:\java_app目录下，windows下打开命令行窗口，切换到E:\java_app，对当前java文件进行编译，执行命令javac TestMain.java。
 
此时会在当前目录下生产对应的class文件（这里只需要对TestMain执行编译命令，因为TestMain依赖了A，所以Jdk编译器就会自动先去编译依赖的A），如图所示：
 
编译命令
 
 
接下来我们将观察java类加载机制是怎样实现双亲委托加载的。
 
委托给扩展类加载器加载
 
由于扩展类在自身类路径下加载只支持寻找jar包的方式，因此我们通过工具将A.class文件打包进A.jar。
 
然后将A.jar放置到扩展类加载路径：$JAVA_HOME/jre/lib/ext，同时保留当前目录中的A.class文件。如图所示：
 
扩展委派
 
 
此时在当前目录：E:\java_app下仍然保留有A.class文件，在扩展类加载器路径下多了一个包含了A.class的A.jar文件，在当前目录下执行java命令执行TestMain，命令为：java TestMain，输出如下所示：
 
扩展委派结果
 
 
 
 
由上图输出结果可知，class A虽然在系统类加载器的加载路径中，但由于类加载的委托机制，A首先将由系统类加载器委托给其双亲扩展类加载器进行加载，刚好在扩展类加载器的加载路径中包含了A.class(包含在A.jar中)，所以A最终由扩展类加载器进行了加载。
 
委托给启动类加载器进行加载
 
通常情况下，普通类的加载不应该委托给启动类加载器进行加载，因为前面说过启动类加载器由C++实现，在java虚拟机启动时生成的，在java环境中获取她的信息均为null。
 
本实例为了探究类加载的双亲委托机制，所以特意将构造一个将普通类委托给其加载的场景。
 
前面在讲到启动类加载器加载路径时指出了启动类加载器的加载路径由只读系统属性”sun.boot.class.path“ 指定，且仅支持加载该目录下固定的jar文件。
 
在jdk8中还有”$JAVA_HOME/jre/classes“目录也是启动类加载器加载的路径（该路径默认可能不存在，可以手工创建一个），在该目录下只能放class文件，jar包形式文件不生效。
 
因此，本实例程序将当前目录下的A.class文件拷贝到启动类加载器的类路径：”$JAVA_HOME/jre/classes“中，同时保留当前目录中的A.class文件，也保留扩展类加载器类路径中的A.jar。
 
类存放路径如图所示：
 
委派启动
 
 
在当前目录：E:\java_app目录下执行命令运行TestMain，命令为：java TestMain，输出如下所示：
 
委派启动结果
 
 
由上图输出结果可知，class A虽然在系统类加载器的加载路径中，也存在扩展类加载器的加载路径中，但由于类加载的委托机制，A首先将由系统类加载器委托给其双亲扩展类加载器进行加载。
 
扩展类加载器又会继续进行委托加载（实际上因为扩展类加载器的parent：启动类加载器为null，所以此时的委托动作实际上就是去启动类加载器的加载路径中寻找class A），最终由启动类加载进行了A的加载。
 
双亲委托加载方向
 
类加载器在加载类时，只能向上递归委托其双亲进行类加载，而不可能从双亲再反向委派当前类加载器来进行类加载。
 
在中国象棋中，卒子过河之后的行走轨迹永远只能是前进或者左右平移，可以很形象的比作双亲委托类加载的这种方向性。
 
 
卒子过河比喻当前类加载器委派其双亲加载了某个类。这个类的后续依赖的加载已经和当前类加载器没有关系。
 
 
过河之后的卒子只能前进，表示双亲在加载类的依赖类时，只能继续递归进行双亲委派。
 
 
左右平移表示双亲在递归双亲委派加载失败后，在双亲类加载器自己的加载路径中进行加载。
 
为了表明委派具有方向性，我们继续拿上面的TestMain.class和A.class两个类做实验。
 
上述委托实例中我们的场景时是：TestMain中依赖了A，我们将A通过双亲委托方式进行了加载，本次实验中，我们将TestMain委托给双亲加载。
 
参照上述的操作步骤，将TestMain.class打进TestMain.jar中，放到扩展类加载器的加载路径中，同时也保留TestMain.class到当前目录，如下图所示：
 
委派加载顺序1
 
 
切换到当前应用目录，执行java命令运行程序：java TestMain，执行结果如下所示：
 
委派顺序执行结果
 
 
如上图所示，出现错误了，TestMain被扩展类加载器加载了，依赖的A却没有能被加载到。
 
原因就是上述说的委派加载具有方向性导致的：
 
1、运行java命令执行TestMain程序时，系统类加载器准备加载TestMain，根据双亲委派机制，先委派给其双亲进行加载，最后，双亲扩展类加载器在其加载路径中的TestMain.jar中找到了TestMain.class，完成了TestMain的加载。
 
2、TestMain中依赖了A，此时，会根据加载了TestMain的类加载器：扩展类加载器去加载A，加载方式根据委托机制递归委托给双亲加载，扩展类加载器的双亲为启动类加载器，在启动类加载器的加载路径中不存在A，加载失败，此时由扩展类加载器在自己的加载路径中加载A，也因为加载路径中没有A.class存在，A.class存在于系统类加载器的加载路径中，但是扩展类加载器不会再返回去委托系统类加载器进行加载，所以直接抛出加载失败异常，出现了上述的错误。
 
总结
 
这次大致介绍了java的类加载在整个JVM中的作用，详细介绍了JVM中的启动类加载器、扩展类加载器和系统类加载器三者之间的关系，并结合实例着重介绍了类加载的双亲委派加载原理，理解java的双亲委派加载原理之后，就能在后续的程序开发设计中在程序的动态设计这块掌握更多高级技能，开发出更加优秀的产品。
 
 

双亲委派机制
 
在加载类的时候，会一级一级向上委托，判断是否已经加载，从自定义类加载器-》应用类加载器-》扩展类加载器-》启动类加载器，如果到最后都没有加载这个类，则回去加载自己的类。
 
 
双亲委托有个弊端：
 
不能向下委派，不能不委派
 
怎么打破双亲委派机制：（也就是能向下委派和不委派）
 
自定义类加载器（不委派）
 
spi机制（向下委派）
 
打破双亲委派
 
打破双亲委派的两种方式：
 
1.通过spi机制，使用ServiceLoader.load去加载
 
2.通过自定义类加载器，继承classloader，重写loadclass方法
 
SPI机制
 
spi机制是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能，比如在JDBC中就使用到了SPI机制。
 
为什么通过spi机制就能打破双亲委托？
 
因为在某些情况下父类加载器需要委托子类加载器去加载class文件。受到加载范围的限制，父类加载器无法加载到需要的文件。
 
以Driver接口为例，DriverManager通过Bootstrap ClassLoader加载进来的，而com.mysql.jdbc.Driver是通过Application ClassLoader加载进来的。由于双亲委派模型，父加载器是拿不到通过子加载器加载的类的。这个时候就需要启动类加载器来委托子类来加载Driver实现，从而破坏了双亲委派。
 
SPI机制demo：
 
public interface HelloService {
    public String getName();
}
public class Hello1 implements HelloService{
    @Override
    public String getName() {
        return "hello1";
    }
}
public class Hello2 implements HelloService{
    @Override
    public String getName() {
        return "hello2";
    }
}
 
来一个main方法去加载它，将使用ServiceLoader来进行加载
 
public class SPITest {
    public static void main(String[] args) {
        ServiceLoader<HelloService> serviceLoader = ServiceLoader.load(HelloService.class);
        for (HelloService helloService :serviceLoader){
            System.out.println(helloService.getName());
        }
    }
}
 
配置文件，文件名为接口的全路径，文件内容为实现类的全路径，如我的为：com.chuan.service.Hello1
 
 
输出结果：hello1
 
只配置了Hello1，所以只发现了这一个实现类。
 
自定义类加载器
 
实现逻辑：自定义类继承classLoader，作为自定义类加载器，重写loadClass方法，不让它执行双亲委派逻辑，从而打破双亲委派。
 
先看一个没有重写的demo
 
结果：
 
sun.misc.Launcher$AppClassLoader@58644d46
 
发现是app类加载器。
 
然后重写loadClass方法
 
public class MyClassLoader extends ClassLoader{
    public static void main(String[] args) throws ClassNotFoundException {
        // ServiceLoader.load()
        MyClassLoader myClassLoader = new MyClassLoader();
        Class<?> aClass = myClassLoader.loadClass(Test1.class.getName());
        System.out.println(aClass.getClassLoader());
    }
    protected Class<?> findClass(String className) throws ClassNotFoundException {
        System.out.println("My findClass!");
        return null;
    }

    protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    //修改classloader的原双亲委派逻辑，从而打破双亲委派
                    if (name.startsWith("com.chuan")){
                        c=findClass(name);
                    }
                    else {
                        c=this.getParent().loadClass(name);
                    }
                } catch (ClassNotFoundException e) {
                }

                if (c == null) {
                    long t1 = System.nanoTime();
                    c = findClass(name);
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }
}
class Test1{

        }
 
运行报错，因为没有委派给app类加载器，所以找不到加载不了这个类。
 
那么新的问题又来了，如果我自定义类记载器和核心类重名怎么办，该怎么加载，又或者我想篡改核心类内容，jvm又是怎么解决的？
 
jvm肯定解决了这个问题，openjdk源码在AccessController.doPrivileged
 
学名叫做沙箱安全机制，主要作用是：保护核心类，防止打破双亲委派机制，防篡改，如果重名的话就报异常，这里的重名指包名加类名都重复。
 
demo：
 
package java.lang;

public class Integer {
    public static void main(String[] args) {
        System.out.println("1");
    }
}
 
运行报错：
 
错误: 在类 java.lang.Integer 中找不到 main 方法, 请将 main 方法定义为:
 
public static void main(String[] args)
 
否则 JavaFX 应用程序类必须扩展javafx.application.Application
 
 

 
你得先知道
 
在介绍双亲委派机制的时候，不得不提 ClassLoader 。说ClassLoader之前，我们得先了解下Java的基本知识。
 
Java是运行在Java的虚拟机(.class 的
 
JVM中提供了三层的ClassLoader：
 
ExtClassLoader：主要负责加载jre/
 
那如果有一个 Hello.class 文件是如何被加载到JVM中的呢？
 
双亲委派机制
 
我打开了我的ClassLoader 类。然后将代码翻到 loadClass 方法：
 
public Class> loadClass(String name) throws ClassNotFoundException {
 
return loadClass(name, false);
 
}
 
// -----:point_down::point_down:-----
 
protected Class> loadClass(String name, boolean resolve)
 
throws ClassNotFoundException
 
{
 
// First, check if the class has already been loaded
 
Class> c =
 
其实这段代码已经很好的解释了双亲委派机制，为了大家更容易理解，我做了一张图来描述一下上面一段代码到底是怎么做的：
 

 
从上图中我们就更容易理解了，当一个Hello.class这样的文件要被加载时。不考虑我们自定义检查是否加载过 ，如果有那就无需再加载了。如果没有，那么会拿到 父加载器 ，然后调用父加载器的 loadClass 方法。父类中同理会先检查自己是否已经加载过，如果没有再往上。注意这个过程，知道到达 Bootstrap classLoader 之前，都是没有哪个加载器自己选择加载的。如果父加载器无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出 ClassNotFoundException 。
 
为什么要设计这种机制
 
这种设计有个好处是，如果有人想替换系统级别的类：String.java。篡改它的实现，但是在这种机制下这些系统的类已经被Bootstrap classLoader加载过了，所以并不会再去加载，从一定程度上防止了危险代码的植入。