Java的双亲委派机制能描述下吗

466 06-17

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

巴拉巴拉巴拉...~~（加载、验证、准备、解析、初始化）~~

见这小伙子面容惊奇，脸泛红光，不由自主的就问了一下双亲委派模型说一下吧；遇见没准备充分的，瞬间懵逼。

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

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

Java中的类加载器

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

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

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

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

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

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

关系如图所示：

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

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

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

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

这个并没有那么复杂，我就不画图了哈，大家如果想看图，可以去网上再搜一下，我记得有个大佬画的就很形象。

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

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

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

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

这个问题，其实就算是双亲委派模型中最深入的问题了，最起码中高级工程师面试，问到这也就下个话题了。

这里我也简单说一下吧，最常见的也是人们常说的有两种，分别是：

为什么呢？因为如果你去看ClassLoader类的源码时，你会发现，双亲委派的核心代码就是在这个方法中的；试想，你如果重写了这个方法，自然而然的就打破了双亲委派机制了。

因为双亲委派机制不能支持SPI(Service Provider Interface), 所以才会引入线程上下文类加载器，有了它，就可以打通双亲委派模型的层次结构来反向使用类加载器来完成类加载。

这个目前也是没有办法的事，涉及到SPI的目前都在使用这种方式来完成类加载，其中就包括常用到的JNDI、JDBC、JAXB等。

这里其实还有一个可以打破双亲委派模型的情况，那就是OSGI，这个解释是在《深入理解 Java虚拟机》这本书中，可能是这本书的作者本身就对OSGI比较熟悉，而且看简介还出过一本OSGI的书。

在很多应用环境中，OSGI被当做模块化热部署实现的关键，所以，这样就说明了，OSGI一定会对类加载过程做相应的一些措施。