从Dubbo内核聊聊双亲委派机制

Posted 2021-04-05 肥朝

前言

谈到Dubbo总是避不开SPI思想,因为这个是Dubbo内核中非常重要的一部分,但是SPI是个很大的话题,本篇和之前的一样,为dubbo源码解析专题的知识预热篇.我们公司实际项目就用到了Dubbo的SPI.后面会给大家分享,我们实际项目中,是如何使用SPI,以及SPI后续我们又是如何进优化的.

插播面试题

• 你是否了解spi,讲一讲什么是spi,为什么要使用spi?

• 对类加载机制了解吗,说一下什么是双亲委托模式,他有什么弊端,这个弊端有没有什么我们熟悉的案例,解决这个弊端的原理又是怎么样的?

spi的简单介绍

如果提到api相信大家都知道,spi的话,知道的人就相对少一些.

简单的说,api是给使用者使用的,spi是给拓展者使用的.一个好的开源框架,必须要留一些拓展点.让参与者尽量黑盒拓展,而不是白盒修改代码,否则分支,质量,合并,冲突都会很难管理.并且框架作者能做到的功能,拓展者也一定能做到.

如果从使用层面来说,就是运行时,动态给接口添加实现类.其实这有有点像IoC的思想,将装配的控制权移到程序之外

如果从生活中的例子讲,就是比如浏览器插件,比如墙上的插头不够我们就接个排插,而不是伤筋动骨改插头(感觉不是很贴切,前期你暂且这么不规范的粗略理解)

再多的言语都是抽象的,那么我们用代码来简单实现一下spi

spi的简单实现

接口和具体实现类

1public interface ISayName {
2    void say();
3}

1public class SayEnglishName implements ISayName{
2    @Override
3    public void say() {
4        System.out.println("Toby");
5    }
6}

1public class SayChineseName implements ISayName{
2    @Override
3    public void say() {
4        System.out.println("肥朝");
5    }
6}

配置文件,需放置在META-INF/services/接口全限定名

1com.toby.spi.impl.SayChineseName
2com.toby.spi.impl.SayEnglishName

demo目录结构

测试结果如下

通过改变配置文件,我们就能动态的改变一个接口的实现类.

细心的小伙伴可能发现,比如我想新增一个实现类SayFranceNameImpl,这样的话光改配置文件也还是不行,还要预先包里面就有这个实现类才行啊.

这个先别急,后面会介绍javassist,也就是动态字节码技术.这样可以在运行时动态生成Java类,就不存在要预先把接口的实现类先在包里放好.更多内容,关注肥朝即可.

当然细心的小伙伴可能还发现了,这个我就算不用spi,我用spring的ioc也能通过配置文件动态的注入不同的实现类啊

比如dubbo的设计中,就不想强依赖Spring的IoC容器,但是自已造一个小的IoC容器,也觉得有点过度设计.另外dubbo是不需要依赖任何第三方库的,引用官方文档原话如下

理论上 Dubbo 可以只依赖 JDK，不依赖于任何三方库运行，只需配置使用 JDK 相关实现策略

敲黑板划重点

经常看到有人问两类问题

• java人这么多,是否饱和了?

• 为什么总是要面试造火箭,进去拧螺丝?

你可以问一下你同事,你知道什么是spi吗,如果他不知道的话,那你觉得他把上面的这个简单的例子实现要多久?如果从使用这个层面做区分的话,很难做到有效的区分.无论是做什么,要想在竞争中脱颖而出,就必须做到三个字.差异化.

Java基础中比较容易产生差异化的两个区域就在于JVM和并发编程.如果只是停留在使用层面,那么关注肥朝的博客意义并不大,因此,本篇的spi还需要与ClassLoader结合.

学习JVM和并发编程买本书是必不可少的,以下内容参考了实战Java虚拟机.如果你看的是深入Java虚拟机也没关系,不要纠结于获取知识的渠道,没人在意你做的是五年高考三年模拟还是王后雄学案.
以下内容截取了该书中的部分核心内容,非常感谢作者的辛勤奉献(希望大家支持正版书籍).

从ClassLoader引出spi

ClassLoader的简单介绍

Class的装载大体上可以分为加载类、连接类和初始化三个阶段,在这三个阶段中,所有的Class都是由ClassLoader进行加载的,然后Java虚拟机负责连接、初始化等操作.也就是说,无法通过ClassLoader去改变类的连接和初始化行为.

Java虚拟机会创建三类ClassLoader,分别是

• BootStrap ClassLoader(启动类加载器)

• Extension ClassLoader(扩展类加载器)

• APP ClassLoader(应用类加载器,也称为系统类加载器)

此外,每个应用还可以自定义ClassLoader

ClassLoader的双亲委托模式

在ClassLoader的结构中,还有一个重要的字段parent,它也是一个ClassLoader的实例,这个字段字段表示的ClassLoader也成为这个ClassLoader的双亲.在类加载的过程中,可能会将某些请求交于自己的双亲处理.

如图,应用类加载器的双亲为扩展类加载器,扩展类加载器的双亲为启动类加载器.

系统中的ClassLoader在协同工作时,默认会使用双亲委托模式.即在类加载的时候,系统会判断当前类是否已经被加载,如果被加载,就会直接返回可用的类,否则就会尝试加载,在尝试加载时,会先请求双亲处理,如果双亲请求失败,则会自己加载.

双亲委托模式的弊端

判断类是否加载的时候,应用类加载器会顺着双亲路径往上判断,直到启动类加载器.但是启动类加载器不会往下询问,这个委托路线是单向的,即顶层的类加载器,无法访问底层的类加载器所加载的类,如图

启动类加载器中的类为系统的核心类,比如,在系统类中,提供了一个接口,并且该接口还提供了一个工厂方法用于创建该接口的实例,但是该接口的实现类在应用层中,接口和工厂方法在启动类加载器中,就会出现工厂方法无法创建由应用类加载器加载的应用实例问题.

拥有这样问题的组件有很多,比如JDBC、Xml parser等.JDBC本身是java连接数据库的一个标准,是进行数据库连接的抽象层,由java编写的一组类和接口组成，接口的实现由各个数据库厂商来完成

双亲委托模式的补充

在Java中,把核心类(rt.jar)中提供外部服务,可由应用层自行实现的接口,这种方式成为spi.那我们看一下,在启动类加载器中,访问由应用类加载器实现spi接口的原理

Thread类中有两个方法

1public ClassLoader getContextClassLoader()//获取线程中的上下文加载器
2public void setContextClassLoader(ClassLoader cl)//设置线程中的上下文加载器
3

通过这两个方法,可以把一个ClassLoader置于一个线程的实例之中,使该ClassLoader成为一个相对共享的实例.这样即使是启动类加载器中的代码也可以通过这种方式访问应用类加载器中的类了.如下图

写在最后