SPI是如何规避双亲委派机制的?

1、何为双亲委派机制?

双亲委派机制是什么？

双亲委派机制指的是Java中类加载机制的特性。

双亲委派机制是作用于什么地方？

双亲委派机制主要作用于类加载的时候。

类加载器

首先需要清晰的知道，双亲委派机制指的是类加载的特性。在了解其特性之前，我们需要先了解类加载器有哪些(不考虑自定义加载器的情况)。

类加载器之间的结构如何：

可以看出来，App类加载器是最小的一层，也是我们开发用户接触最多的一层，越往上加载的类就越核心。

双亲委派机制是什么样的结构？

双亲委派机制其实就是描述类加载器加载类的顺序及其特点。

我们开发者需要去加载类的场景每天都在接触，例如在代码中new Car(我们自己的类)，此时就是需要去加载这个类。在触发加载类的时候，开发者处于加载器的最低层。那么就可以看作成：App类加载器去加载Car这个类。

而实际上的加载顺序是这样的：

App类加载器--通知-->Ext类加载器--通知-->BootStrap类加载器

BootStrap类加载器--发现找不到该类,则向下返回-->Ext类加载器--发现找不到该类,继续向下返回-->App类加载器(当前类加载器如果找不到该类则抛出异常，否则加载成功)

上述为双亲委派机制加载类时的顺序，其特点为先向上通知到最顶层，再由最顶层往下尝试，直到成功加载或到达发送加载类请求的加载器。

这种加载特点最大的作用如下：

安全性：由于Java核心类均有BootStrap加载器、Ext加载器去加载，再加上这种加载类的特性，可以有效防止Java核心类被篡改，正常的Java应用无法修改核心类实现。不仅可以应用在Java核心类中，当我们的应用是插件式时，此方式也可以防止插件中篡改主程序的代码。

2、SPI是什么?

上面我们讲述了双亲委派机制，现在要讲述SPI。

SPI是什么？

SPI（Service Provider Interface）是JDK内置的一种服务提供发现机制，可以用来启用框架扩展和替换组件，主要是被框架的开发人员使用。

例如数据库驱动中java.sql.Driver接口，其他不同厂商可以针对同一接口做出不同的实现，MySQL和PostgreSQL都有不同的实现提供给用户，而Java的SPI机制可以为某个接口寻找服务实现。Java中SPI机制主要思想是将功能实现剔除到程序之外，这针对与模块化解耦有很大的作用。

例如下图：

除数据库驱动以外，例如日志框架、Dubbo等也涉及到SPI机制。

在上图中，例如当我们需要具体Driver实现的时候，直接通过JDK的API：

ServiceLoader<java.sql.Driver> serviceLoader = ServiceLoader.load(java.sql.Driver.class);
for (java.sql.Driver driver : serviceLoader) {
     // mysql、pg、oracle、db2等
}

注意，SPI机制存在一些约定，这些约束如下：

1. 三方接口需在META-INF/services/${interface_name}文件中列举实现类，每一个实现类为一行。例如数据库这，那么示例如下：

   META-INF/services/java.sql.Driver

com.mysql.cj.jdbc.Driver
org.postgresql.Driver
oracle.jdbc.OracleDriver
com.ibm.db2.jcc.DB2Driver

​ 2.定义的实现类必须实现对应接口

​ 3.实现类必须提供无参构造器

3、为什么说SPI规避了双亲委派机制?

​ 注意，我们前面说了双亲委派机制中，加载器会往上层加载器递交加载请求，我们已知java.util.ServiceLoader的类加载器为BootStrap加载器。此加载器已经是最顶层，无更加上层的加载器。而按照加载器职责的约定，ServiceLoader所属类加载器的职责是加载jdk核心类，其是无法加载到用户的类。例如下图：

​ 现在的问题是：既然ServiceLoader的类加载器是最顶层的，其加载职责不负责我们自己的类，那么它是如何加载到类似JDBC这种实现类的呢？

附：ServiceLoader的类加载器是BootStrap类加载器，在程序中是无法获取到该类的类加载器的。

4、SPI是如何规避双亲委派机制的?

​ 要搞清楚这个问题的原因，得先确认我们使用SPI的入口：

ServiceLoader<Xxxx> serviceLoader = ServiceLoader.load(Xxxx.class);

​ 进入该方法，寻找其实现的方式：

java.util.ServiceLoader#load(java.lang.Class)

​ 注意此处获取了当前线程的类加载器，而在线程中调用该类方法的是我们用户自己。那么这里就理解为获取到了用户的类加载器。

​ 再往该方法中查找，找到该段代码：

java.util.ServiceLoader#ServiceLoader

​ 注意该段代码中，cl为上一步获取到的类加载器，如果发现类加载器不存在，会再次获取系统默认加载器，这个系统默认加载器在常规情况下是用于加载启动类的加载器(jdk注释中解释)，而启动类则是我们用户自己定义的类，这里毋庸置疑也会是应用类加载器。

​ 从上面的代码中我们总结出来，ServiceLoader获取了我们的应用类加载器，至此load方法入口基本上没有其他内容可以细看。

​ 为减轻文章阅读压力，直接跳转到该方法

java.util.ServiceLoader.LazyIterator#nextService

​ 注意这里的loader是我们前面获取到的应用类加载器，这个方法中是获取到了具体需要实例化的实现类，即将对其进行实例化， 在这之前需要先获取到Class，这里使用Class.forName(class, false, ClassLoader)方法，这个方法的含义是使用指定的类加载器去加载指定的类。既然这里的类加载器是应用类加载器，那么类加载顺序自然就又回到了应用类加载器-->扩展类加载器-->BootStrap类加载器-->扩展类加载器-->应用类加载器，能加载到我们想要的类也就不奇怪了。

​ 看到这里也就明白了为什么使用SPI仍然能正常加载类了。

​ SPI的加载机制看起来虽然方面，但仍然有缺点：

1. 无法实现动态加载、卸载的效果，只有最简单的加载三方类的实现。
1. 由于实现原因，实现类必须提供无参构造器，局限性和扩展性很低

​ 综合来说，SPI简单但局限性大，项目中能接受这些缺点就可以放心使用，如接受不了则可以模拟SPI机制自行实现一套加载机制，自己实现起来扩展性和局限性肯定是原生SPI不能比的。

​ 本次内容结束，如发现内容错误请留言，会尽快改正。