MyBatis 源码分析 - 插件机制

    • 1.简介
  • 2. 插件机制原理

  • 3. 源码分析

    • 3.1 植入插件逻辑
  • 3.2 执行插件逻辑

  • 4. 实现一个分页插件

  • 5. 总结

| 序号 | 内容 | 链接 |

| — | — | — |

| 1 | MyBatis 源码分析 - MyBatis入门 | https://thinkwon.blog.csdn.net/article/details/114808852 |

| 2 | MyBatis 源码分析 - 配置文件解析过程 | https://thinkwon.blog.csdn.net/article/details/114808962 |

| 3 | MyBatis 源码分析 - 映射文件解析过程 | https://thinkwon.blog.csdn.net/article/details/115423167 |

| 4 | MyBatis 源码分析 - SQL 的执行过程 | https://thinkwon.blog.csdn.net/article/details/115603376 |

| 5 | MyBatis 源码分析 - 内置数据源 | https://thinkwon.blog.csdn.net/article/details/116331419 |

| 6 | MyBatis 源码分析 - 缓存原理 | https://thinkwon.blog.csdn.net/article/details/116809942 |

| 7 | MyBatis 源码分析 - 插件机制 | https://thinkwon.blog.csdn.net/article/details/116809961 |

1.简介


一般情况下,开源框架都会提供插件或其他形式的拓展点,供开发者自行拓展。这样的好处是显而易见的,一是增加了框架的灵活性。二是开发者可以结合实际需求,对框架进行拓展,使其能够更好的工作。以 MyBatis 为例,我们可基于 MyBatis 插件机制实现分页、分表,监控等功能。由于插件和业务无关,业务也无法感知插件的存在。因此可以无感植入插件,在无形中增强功能。

开发 MyBatis 插件需要对 MyBatis 比较深了解才行,一般来说最好能够掌握 MyBatis 的源码,门槛相对较高。本篇文章在分析完 MyBatis 插件机制后,会手写一个简单的分页插件,以帮助大家更好的掌握 MyBatis 插件的编写。

2. 插件机制原理


我们在编写插件时,除了需要让插件类实现 Interceptor 接口,还需要通过注解标注该插件的拦截点。所谓拦截点指的是插件所能拦截的方法,MyBatis 所允许拦截的方法如下:

  • Executor (update, query, flushStatements, commit, rollback, getTransaction, close, isClosed)

  • ParameterHandler (getParameterObject, setParameters)

  • ResultSetHandler (handleResultSets, handleOutputParameters)

  • StatementHandler (prepare, parameterize, batch, update, query)

如果我们想要拦截 Executor 的 query 方法,那么可以这样定义插件。

@Intercepts({

@Signature(

type = Executor.class,

method = “query”,

args ={MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}

)

})

public class ExamplePlugin implements Interceptor {

// 省略逻辑

}

除此之外,我们还需将插件配置到相关文件中。这样 MyBatis 在启动时可以加载插件,并保存插件实例到相关对象(InterceptorChain,拦截器链)中。待准备工作做完后,MyBatis 处于就绪状态。我们在执行 SQL 时,需要先通过 DefaultSqlSessionFactory 创建 SqlSession 。Executor 实例会在创建 SqlSession 的过程中被创建,Executor 实例创建完毕后,MyBatis 会通过 JDK 动态代理为实例生成代理类。这样,插件逻辑即可在 Executor 相关方法被调用前执行。

以上就是 MyBatis 插件机制的基本原理。接下来,我们来看一下原理背后对应的源码是怎样的。

3. 源码分析


3.1 植入插件逻辑

本节,我将以 Executor 为例,分析 MyBatis 是如何为 Executor 实例植入插件逻辑的。Executor 实例是在开启 SqlSession 时被创建的,因此,下面我们从源头进行分析。先来看一下 SqlSession 开启的过程。

// -☆- DefaultSqlSessionFactory

public SqlSession openSession() {

return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false);

}

private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {

Transaction tx = null;

try {

// 省略部分逻辑

// 创建 Executor

final Executor executor = configuration.newExecutor(tx, execType);

return new DefaultSqlSession(configuration, executor, autoCommit);

}

catch (Exception e) {…}

finally {…}

}

Executor 的创建过程封装在 Configuration 中,我们跟进去看看看。

// -☆- Configuration

public Executor newExecutor(Transaction transaction, ExecutorType executorType) {

executorType = executorType == null ? defaultExecutorType : executorType;

executorType = executorType == null ? ExecutorType.SIMPLE : executorType;

Executor executor;

// 根据 executorType 创建相应的 Executor 实例

if (ExecutorType.BATCH == executorType) {…}

else if (ExecutorType.REUSE == executorType) {…}

else {

executor = new SimpleExecutor(this, transaction);

}

if (cacheEnabled) {

executor = new CachingExecutor(executor);

}

// 植入插件

executor = (Executor) interceptorChain.pluginAll(executor);

return executor;

}

如上,newExecutor 方法在创建好 Executor 实例后,紧接着通过拦截器链 interceptorChain 为 Executor 实例植入代理逻辑。那下面我们看一下 InterceptorChain 的代码是怎样的。

public class InterceptorChain {

private final List interceptors = new ArrayList();

public Object pluginAll(Object target) {

// 遍历拦截器集合

for (Interceptor interceptor : interceptors) {

// 调用拦截器的 plugin 方法植入相应的插件逻辑

target = interceptor.plugin(target);

}

return target;

}

/** 添加插件实例到 interceptors 集合中 */

public void addInterceptor(Interceptor interceptor) {

interceptors.add(interceptor);

}

/** 获取插件列表 */

public List getInterceptors() {

return Collections.unmodifiableList(interceptors);

}

}

以上是 InterceptorChain 的全部代码,比较简单。它的 pluginAll 方法会调用具体插件的 plugin 方法植入相应的插件逻辑。如果有多个插件,则会多次调用 plugin 方法,最终生成一个层层嵌套的代理类。形如下面:

img

当 Executor 的某个方法被调用的时候,插件逻辑会先行执行。执行顺序由外而内,比如上图的执行顺序为 plugin3 → plugin2 → Plugin1 → Executor

plugin 方法是由具体的插件类实现,不过该方法代码一般比较固定,所以下面找个示例分析一下。

// -☆- ExamplePlugin

public Object plugin(Object target) {

return Plugin.wrap(target, this);

}

// -☆- Plugin

public static Object wrap(Object target, Interceptor interceptor) {

/*

  • 获取插件类 @Signature 注解内容,并生成相应的映射结构。形如下面:

  • {

  • Executor.class : [query, update, commit],
    
  • ParameterHandler.class : [getParameterObject, setParameters]
    
  • }

*/

Map<Class<?>, Set> signatureMap = getSignatureMap(interceptor);

Class<?> type = target.getClass();

// 获取目标类实现的接口

Class<?>[] interfaces = getAllInterfaces(type, signatureMap);

if (interfaces.length > 0) {

// 通过 JDK 动态代理为目标类生成代理类

return Proxy.newProxyInstance(

type.getClassLoader(),

interfaces,

new Plugin(target, interceptor, signatureMap));

}

return target;

}

如上,plugin 方法在内部调用了 Plugin 类的 wrap 方法,用于为目标对象生成代理。Plugin 类实现了 InvocationHandler 接口,因此它可以作为参数传给 Proxy 的 newProxyInstance 方法。

到这里,关于插件植入的逻辑就分析完了。接下来,我们来看看插件逻辑是怎样执行的。

3.2 执行插件逻辑

Plugin 实现了 InvocationHandler 接口,因此它的 invoke 方法会拦截所有的方法调用。invoke 方法会对所拦截的方法进行检测,以决定是否执行插件逻辑。该方法的逻辑如下:

// -☆- Plugin

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

try {

/*

  • 获取被拦截方法列表,比如:

  • signatureMap.get(Executor.class),可能返回 [query, update, commit]

*/

Set methods = signatureMap.get(method.getDeclaringClass());

// 检测方法列表是否包含被拦截的方法

if (methods != null && methods.contains(method)) {

// 执行插件逻辑

return interceptor.intercept(new Invocation(target, method, args));

}

// 执行被拦截的方法

return method.invoke(target, args);

} catch (Exception e) {

throw ExceptionUtil.unwrapThrowable(e);

}

}

invoke 方法的代码比较少,逻辑不难理解。首先,invoke 方法会检测被拦截方法是否配置在插件的 @Signature 注解中,若是,则执行插件逻辑,否则执行被拦截方法。插件逻辑封装在 intercept 中,该方法的参数类型为 Invocation。Invocation 主要用于存储目标类,方法以及方法参数列表。下面简单看一下该类的定义。

public class Invocation {

private final Object target;

private final Method method;

private final Object[] args;

public Invocation(Object target, Method method, Object[] args) {

this.target = target;

this.method = method;

this.args = args;

}

// 省略部分代码

public Object proceed() throws InvocationTargetException, IllegalAccessException {

// 调用被拦截的方法

return method.invoke(target, args);

}

}

关于插件的执行逻辑就分析到这,整个过程不难理解,大家简单看看即可。

4. 实现一个分页插件


为了更好的向大家介绍 MyBatis 的插件机制,下面我将手写一个针对 MySQL 的分页插件。Talk is cheap. Show the code。

@Intercepts({

@Signature(

type = Executor.class, // 目标类

method = “query”, // 目标方法

args ={MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}

)

})

public class MySqlPagingPlugin implements Interceptor {

Kafka实战笔记

关于这份笔记,为了不影响大家的阅读体验,我只能在文章中展示部分的章节内容和核心截图

image.png

  • Kafka入门
  • 为什么选择Kafka
  • Karka的安装、管理和配置

image.png

  • Kafka的集群
  • 第一个Kafka程序
  • image.png

afka的生产者

image.png

  • Kafka的消费者
  • 深入理解Kafka
  • 可靠的数据传递

image.png

image.png

  • Spring和Kalka的整合
  • Sprinboot和Kafka的整合
  • Kafka实战之削峰填谷
  • 数据管道和流式处理(了解即可)

image.png

  • Kafka实战之削峰填谷

image.png

存中…(img-honGxJrE-1721147360035)]

  • Kafka的集群
  • 第一个Kafka程序
  • [外链图片转存中…(img-0zUxpftx-1721147360037)]

afka的生产者

[外链图片转存中…(img-IcccsWoY-1721147360037)]

  • Kafka的消费者
  • 深入理解Kafka
  • 可靠的数据传递

[外链图片转存中…(img-Ng6y5Vim-1721147360038)]

[外链图片转存中…(img-WOwbm5y4-1721147360038)]

  • Spring和Kalka的整合
  • Sprinboot和Kafka的整合
  • Kafka实战之削峰填谷
  • 数据管道和流式处理(了解即可)

[外链图片转存中…(img-ydD55Kl6-1721147360039)]

  • Kafka实战之削峰填谷

[外链图片转存中…(img-ei0S6OkQ-1721147360039)]

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值