双亲委派机制

问题描述

双亲委派机制

双亲委派机制是java类加载里的一个很有意思的机制，同时也是面试常问的一个问题

---

分析：

提示：这里填写问题的分析：

如果面试官问你，类加载过程是哪几步？

巴拉巴拉巴拉…（加载、验证、准备、解析、初始化）
见这小伙子面容惊奇，脸泛红光，不由自主的就问了一下双亲委派模型说一下吧；遇见没准备充分的，瞬间懵逼。

下面我们就来说一下这个一个有意思的虚拟机类加载机制。

一说起双亲委派，就必然要先聊一下Java中的类加载器。

Java中的类加载器
Bootstrap ClassLoader (启动类加载器)

Bootstrap ClassLoader，启动类加载，默认加载的是jdk\lib目录下jar中诸多类；

这个路径可以使用 -Xbootclasspath参数指定。

Extension ClassLoader (扩展类加载器)

Extension ClassLoader，扩展类加载器，默认加载jdk\lib\ext\目录下jar中诸多类；

这个路径可以使用 java.ext.dirs系统变量来更改。

Application ClassLoader (应用程序类加载器)

Application ClassLoader，应用程序类加载器，负责加载开发人员所编写的诸多类。

User ClassLoader (自定义类加载器)

自定义类加载器，当存在上述类加载器解决不了的特殊情况，或存在特殊要求时，可以自行实现类加载逻辑。

关系如图所示：

双亲委派模型是什么？
说完了类加载器，下面我们就说一下什么是双亲委派模型吧。

其是在JDK1.2期间被引入的，而后陆续被推荐给开发者，到目前已经成为了最常用的类加载器实现方式了。

双亲委派整个过程分为以下几步：

假设用户刚刚摸鱼写的Test类想进行加载，这个时候首先会发送给应用程序类加载器AppCloassLoader；
然后AppClassLoader并不会直接去加载Test类，而是会委派于父类加载器完成此操作，也就是ExtClassLoader；
ExtClassLoader同样也不会直接去加载Test类，而是会继续委派于父类加载器完成，也就是BootstrapClassLoader；
BootstrapClassLoader这个时候已经到顶层了，没有父类加载器了，所以BootstrapClassLoader会在jdk/lib目录下去搜索是否存在，因为这里是用户自己写的Test类，是不会存在于jdk下的，所以这个时候会给子类加载器一个反馈。
ExtClassLoader收到父类加载器发送的反馈，知道了父类加载器并没有找到对应的类，爸爸靠不住，就只能自己来加载了，结果显而易见，自己也不行，没办法，只能给更下面的子类加载器了。
AppClassLoader收到父类加载器的反馈，顿时明白，原来爸爸虽然是爸爸，但是他终究不能管儿子的私事，所以这时候，AppClassLoader就自己尝试去加载。
结果，就这样成功了，走了一大圈，兜兜转转还是自己干。
这个并没有那么复杂，我就不画图了哈，大家如果想看图，可以去网上再搜一下，我记得有个大佬画的就很形象。

为什么要使用双亲委派模型？
使用双亲委派模型，有一个很大的好处，就是避免原始类被覆盖的问题。

比如，用户编写了一个Object类，放入程序中加载。

当没有双亲委派机制时，就会出现重复的Object类，会给开发人员造成很大的困扰，本来就只需要基于JDK开发就好了，现在还得把JDK中的类全记住，避免编写重复的类。

当存在双亲委派机制时呢，整个事情就不一样了，每次加载类时，都会遵循双亲委派机制，去问父类是否可以加载，如果可以呢，那就不需要再次加载了，这样事情就变得简单了。（老子走的路，小子不能走 ）

---