mybatis源码解析 - 核心基础组件之数据源组件

接上次分享了日志组件后，咱们此次来分享一个比较重要mybatis基础组件---数据源组件。提到数据源组件，我想问一个问题：请问从mybatis链接池获取一个数据库链接的过程是怎样的？你知道吗？这好像是BAT大厂的一道面试题吧。别着急咱们慢慢来聊。

总体设计架构

今天来分享一下数据源组件的源码实现细节

工厂模式的设计思路

DataSourceFactory: 工厂模式的核心接口，调用者直接和工厂接口交互，用于获取具体的工厂实现类；

DataSource: java数据源的核心接口，用于抽象数据源行为；

UnpooledDataSourceFactory: 非池化工厂的具体实现类，用于建立非池化的数据源对象；

UnpooledDataSource:  主要用于构建原生的Connection对象;

PooledDataSourceFactory: 池化工厂的具体实现类，其继承UnpooledDataSourceFactory非池化工厂类的行为；主要职责建立池化的数据源对象；

PooledDataSource: 池化的数据源，它依赖UnpooledDataSource非池化数据源中链接等信息建立同步、线程安全的池化的数据源。

PooledConnection:  使用动态代理封装和加强原生的Connection数据库链接对象；

PoolState: 用于管理PooledConnection状态的组件，经过维护两个list分别管理空闲和活动的链接资源；

带着以下问题解读mybatis数据源组件设计实现源码

1. 数据源组件为何采用工厂模式实现 ?

2. 池化数据源和非池化数据源有什么联系和区别，池化数据源须要考虑哪些问题？

数据源工厂源码实现

非池化数据源源码实现

池化数据源源码实现

从组件以上的设计思路和源码实现上，咱们不可贵出如下认知：

1. mybatis自身除了实现内置的数据源外，还要对三方数据源(如：durid, dbcp, c3p0等)的接入提供支持。这种业务设计需求下必须对数据源建立和管理，单独提供入口，而且能方便的切换和适配。

2. 采用常规建立对象的方式, 包括：直接new具体数据源类建立对象和经过反射机制建立对象等方式，很明显有如下缺陷：

缺陷一：对象的建立和使用的职责耦合在一块儿， 违反了单一职责原则；

缺陷二：当业务扩展时，必需要修改代码，违反了开闭原则；

那么我认为至少基于以上两大原则，mybatis才会考虑使用工厂模式。那工厂模式的明显优势有哪些呢?

1. 把对象的建立和使用的过程分开，这样就达到了把二者的职责分离的目的；

2. 若是建立对象过程比较复杂，建立过程统一放到工厂维护，即减小了重复代码，又方便了之后对相关过程代码的修改；

3. 当业务扩展时，只须要增长工厂子类，符合开闭原则；

OK, 这个问题解决了。那接下来咱们将重点分析链接池化技术的设计实现源码。

池化数据源构建

封装池化、加强的数据库链接

封装对池化链接进行管理的核心数据结构

idleConnections：空闲池化链接集合, 当链接使用完关闭时，会把它放进这个空闲链接集合缓存; 当获取链接成功时，会将它从该集合中移除。

activeConnections:  正在使用的链接集合，当链接获取成功时，会把池化链接对象放入此集合；当链接关闭时，会把它从该集合中移除。

这两个list集合最终贯穿链接生命周期的始终。

池化数据源管理

拿链接的核心设计思路

拿链接方式和流程总结

上面正好也回答了文章一开始提出的问题!!

close链接的设计思路

关闭链接方式总结

总结

mybatis数据源组件其实设计很精妙，这种设计思路你们值得多思考和在咱们的项目中借鉴，尤为是池化技术、设计模式！后面还为分享mybatis一些优秀的组件和设计思想，请继续关注!