解释JAVA SPI 破坏双亲委派模型的原因

水深无声 2022-12-13 11:25 134阅读 0赞

# 一、JVM三种类加载器 #

>  *  **Bootstrap Classloader 启动类加载器**：负责加载/lib 下的核心类库，此加载器本身内嵌于JVM，在 Java 中找不到具体的引用，C++开发；
>  *  **Extension Classloader 扩展类加载器**：负责加载/lib/ext 下的扩展类库，Java开发；
>  *  **Application Classloader 系统应用类加载器**：负责-classpath 指定路径类库加载，Java开发；
>  *  ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JyYXZlX2hlYXJ0NHB6ag_size_16_color_FFFFFF_t_70_pic_center]
>  *  这里有个源码细节，由于启动类加载器是内嵌于 JVM 且无法被引用，因此 Extension Classloader 指派 parent 为 null，即等同于指派启动类加载器为自己的父加载器

# 二、双亲委派机制的特点 #

>  *  **加载过程**
>     
>     简单来说，当一个类加载器得到一个类加载任务 t 的时候，首先会委派其 parent A 去加载，A 拿到任务后，也会进一步委派到 A 的 parent B。层层向上递归直到委派到启动类加载器。
>     
>     但我们知道，每个 classloader 负责的加载域是不一样的，启动类加载器需根据 t 给出的类全限定名（如 com.Test）在其所负责的域里搜寻此类字节码，如果找到，则加载之；如果找不到，则表示无法加载，把代理权限往下\*\*（父->子）\*\*转移，直到某个加载器在负责的加载域中找到该类为止。
>  *  **可见性**
>     
>     假定 A 作为 B 的 parent，A 加载的类 对 B 是可见的； 然而 B 加载的类 对 A 却是不可见的。
>  *  **为什么要有双亲委派模型？**
>     
>     一个类在同一个类加载器中具有**唯一性(Uniqueness)**，而不同类加载器中是允许同名类存在的，这里的同名是指**全限定名相同**。但是在整个JVM里，纵然全限定名相同，若类加载器不同，则仍然不算作是同一个类，无法通过 instanceOf 、equals 等方式的校验。
>     
>     由于唯一性的存在，Class 被替换就有可能了，而双亲委派模型定义了一套类加载的优先层级，很好的防止核心类库被恶意替换。毕竟核心类库是 bootstrap classloader 加载的，而 bootstrap 是内嵌于JVM的，在双亲委派模型基础上，任何类加载任务都会交由 bootstrap classloader 这位大佬经手过目一次，只要是核心类库中的类，都会被 bootstrap classloader 加载，间接确保核心类库不被其他类加载器加载。
>     
>     换言之，在遵循了双亲委派模型的规则之下，是不允许出现核心类库被替换或取代的可能，即不能在自己的 classpath 定义 java.lang.\*之类的Class去替换JRE 中的Class。
>  *  **特别声明**
>     
>     双亲委派模型，JVM官方不是强制实现的，就是，不同的JVM厂商可以实现自己的class加载机制
>     
>     这个机制的安全性也是有限的。假如有人能登入服务器，能够直接替换JDK目录的文件。上述机制也就失效了。为了保证严格的安全，还应该保证系统文件要做数字签名。

# 三、SPI（Service Provider Interface） #

>  *  **什么是SPI机制？**  
>     ![在这里插入图片描述][20201012102610731.png_pic_center]
>     
>     Java 在核心类库中定义了许多接口，并且还给出了针对这些接口的调用逻辑，然而并未给出实现。开发者要做的就是定制一个实现类，在 META-INF/services 中注册实现类信息，以供核心类库使用。说的直白点，JNDI是JVM的接口，SPI是对应厂商的接口实现类
>  *  **典型的例子：JDBC驱动包**
>     
>     Java从1.6搞出了SPI就是为了优雅的解决这样的问题——JDK提供接口，供应商提供服务。编程人员编码时面向接口编程，然后JDK能够自动找到合适的实现，岂不是很爽？
>     
>     提供商提供的类不能放JDK里的lib目录下，所以也就没法用BootstrapClassLoader加载了。所以当你代码写了
>     
>         Class clz = Class.forName("java.sql.Driver");
>         Driver d = (Driver)clz.newInstance();
>     
>     这个代码会用Bootstrap ClassLoader尝试去加载.问题是java.sql.Driver是个接口，无法真的实例化，就报错了。
>     
>     没有SPI时，你可以现在classpath里加一个mysql-connector-java.jar，然后这样写
>     
>         Class clz = Class.forName("com.mysql.jdbc.Driver");
>         Driver d = (Driver) clz.newInstance();
>     
>     这里用了Application Classloader加载了mysql-connector-java.jar的com.mysql.jdbc.Driver。问题是你hard code了一定要加载"com.mysql.jdbc.Driver"，不是很优雅，违背面向接口编程思想。使用SPI后，代码大致会这样
>     
>         Connection connection = 
>         DriverManager.getConnection("jdbc:mysql://xxxxxx/xxx", "xxxx", "xxxxx");
>     
>     java.sql.Driver 是最为典型的 SPI 接口，java.sql.DriverManager 通过扫包的方式拿到指定的实现类，完成 DriverManager的初始化。
>     
>     这里就违背了双亲委派的**可见性**原则，**启动类加载器** 加载的 DriverManager 是不可能拿到 **系统应用类加载器** 加载的实现类 ，这似乎通过某种机制打破了双亲委派模型。
>  *  **JVM是如何拿到SPI实现类的呢？**
>     
>     通过从线程上下文（ThreadContext）获取 classloader ，借助这个classloader 可以拿到实现类的 Class。
>     
>     （源码上讲，这里是通过 Class.forName 配合 classloader拿到的）
>     
>     线程上下文 classloader并非具体的某个loader，一般情况下是 application classloader， 但也可以通过 **java.lang.Thread\#setContextClassLoader** 这个方法指定 classloader。
>     
>     说简单点，就是通过**线程上下文加载器的反射机制**，拿到对应的实例对象的。

# 四、总结 #

> 文字可能比较多，读者可能看迷糊了
> 
> 简单说，SPI机制打破了双亲委派机制的可见性原则，所以，我们说，SPI违背了双亲委派模型

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JyYXZlX2hlYXJ0NHB6ag_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/f9e60129ff394878a14d2148fb9cbb16.png
[20201012102610731.png_pic_center]: /images/20221123/95285e731a524ccd82eb4563af578591.png