From: https://www.sohu.com/a/334000357_505800
来源: java 一日一条
原标题：阿里面试：什么地方违反了双亲委派模型
在开讲双亲委派模型之前，我们先要了解一下类加载机制
类加载机制 是指将类的 class 文件读入到内存，并为之创建一个 java.lang.Class 对象。中间对数据做了 校验，转换解析和初始化等操作。
一般情况下我们说了有三种加载器：
- 最基础：Bootstrap ClassLoader（加载 JDK 的 / lib 目录下的类）
- 次基础：Extension ClassLoader（加载 JDK 的 / lib/ext 目录下的类）
- 普通：Application ClassLoader（程序自己 classpath 下的类）
图片来源于网络
双亲委派模型要求如果一个类可以被委派最基础的 ClassLoader 加载，就不能让高层的 ClassLoader 加载。
举个例子：我们实际中用到的一些类如：String，Object 等，都是来自于 jdk 的 lib 下的 rt.jar 包，但是如果我们有工作需要在自己的项目中也创建相同名称的类，我们如何来区分呢，双亲委派就完美的解决了这个问题，BootStrap 加载 rt.jar 包，剩下的由它的子加载器下的子加载器来加载。当然这里的父子不是指的一般意义上的父类和子类。
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委派父类加载器去完成。每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个请求（他的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
在很多的时候面试官会问我们如何破坏双亲委派模型和为什么要破坏它
在实际的应用中双亲委派解决了 java 基础类统一加载的问题，但是却着实存在着一定的缺席。jdk 中的基础类作为用户典型的 api 被调用，但是也存在被 api 调用用户的代码的情况，典型的如 SPI 代码。
SPI 机制简介
SPI 的全名为 Service Provider Interface，主要是应用于厂商自定义组件或插件中。在 java.util.ServiceLoader 的文档里有比较详细的介绍。简单的总结下 java SPI 机制的思想：我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块、xml 解析模块、jdbc 模块等方案。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。Java SPI 就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似 IOC 的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。
所以 jdk 开发人员就引入了线程上下文类加载器（Thread Context ClassLoader），这类类加载器可以通过 java.lang.Thread 类的 setContextClassLoader 方法进行设置。
其实在 jdbc 的使用中，我们很好的体会到它的作用，我们平时看到的 mysql 的加载是这个样子的：
在以上的代码中就实现了注册 mysql 驱动和获取数据库连接。
以上的代码是 DriverManager 的初始化方法 loadInitialDrivers，大家可以从中看到先是获取 jdbc.drivers 属性，得到类的路径。然后通过系统类加载器加载。
注意 driversIterator.next 最终就是调用 Class.forName(DriverName, false, loader) 方法，也就是最开始我们在第一张图中注释掉的那一句代码。
对于自己加载不了的类怎么办，直接用线程上下类加载器加载，通过
ClassLoadercl =Thread.currentThread.getContextClassLoader;
这条语句获取本地线程然后实现上下类加载。牛逼了，所以这个地方 Bootstrap Classloader 加载器拿到了 Application ClassLoader 加载器应该加载的类，就打破了双亲委派模型
本文由 Suremotoo 创作，采用 知识共享署名4.0
国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Jun 1,2020