本章我们介绍的是 MyBatis 的插件体系，说是插件，其实用拦截器更为合理，MyBatis 的源码中也称其为拦截器。那我们就从最基础的说起，先了解一下 MyBatis 设计的这个插件是什么。
1. 插件概述
官方文档中并没有说明 MyBatis 插件的具体定义，不过借助拦截器的思路，我们还是很容易理解的：MyBatis 的插件就是一些能拦截某些 MyBatis 核心组件方法，增强功能的拦截器。MyBatis 允许我们在 SQL 语句执行过程中的某些点进行拦截增强，官方文档中列出了四种可供增强的切入点：
Executor ( update, query, flushStatements, commit, rollback, getTransaction, close, isClosed )
ParameterHandler ( getParameterObject, setParameters )
ResultSetHandler ( handleResultSets, handleOutputParameters )
StatementHandler ( prepare, parameterize, batch, update, query )
这些东西看上去不是很眼熟，没有关系，我们可以先来简单的解释一下它们的作用，以及拦截它们的目的。
Executor: 我们上一章也提过了，它是执行 statement 的核心组件，它负责整体的执行把控
拦截 Executor ，则意味着要干扰 / 增强底层执行的 CRUD 等动作
ParameterHandler: 处理 SQL 注入参数的处理器
拦截 ParameterHandler ，则意味着要干扰 / 增强 SQL 参数注入 / 读取的动作
ResultSetHandler：处理原生 jdbc 的ResultSet的处理器
拦截 ResultSetHandler ，则意味着要干扰 / 增强封装结果集的动作
StatementHandler：处理原生 jdbc 的 Statement的处理器
拦截 StatementHandler ，则意味着要干扰 / 增强 Statement 的创建和执行的动作
下面的几个 Handler 相对来讲都不是那么难理解吧，它们都可以理解为是原生 jdbc 的一层包装，MyBatis 的底层执行流程中不需要单独对原生 jdbc 的 API 进行操纵，只需要运用这几个 Handler 就可以。**Executor** 是重中之重，我们生命周期部分的第一个环节就要讲它，各位稍安勿躁。
下面我们先来编写一个简单的插件，初步体会一下 MyBatis 中的插件。
2. 插件快速体验
我们再创建一个新的工程 mybatis-07-extra 吧，准备工作跟前面准备缓存、事务的步骤一样，小册不再赘述。我们直接开始编码。
2.1 编写插件
我们直接创建一个 plugin 包，并新建一个 CustomInterceptor ，让它实现 org.apache.ibatis.plugin.Interceptor 接口：
public class CustomInterceptor implements Interceptor {
@Override
public Object intercept(Invocation invocation) throws Throwable {
return null;
}
}
之后，还需要在类上标注一个 @Intercepts 注解，用于声明要拦截哪个组件的哪个方法（或者哪些组件的哪些方法）：
@Intercepts(@Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class}))
public class CustomInterceptor implements Interceptor { ... }
按照上面的写法，就意味着，我们这个 **CustomInterceptor** 要在 **Executor** 的 **update** 方法执行之前拦截。
拦截之后具体都干什么呢？我们要在 intercept 方法中编写，既然是简单体验，那我们就只是打印一行日志吧：
@Override
public Object intercept(Invocation invocation) throws Throwable {
System.out.println("CustomInterceptor intercept run ......");
// 顺便，把这个Invocation中的东西也打印出来吧
System.out.println(invocation.getTarget());
System.out.println(invocation.getMethod().getName());
System.out.println(Arrays.toString(invocation.getArgs()));
return invocation.proceed();
}
编写好拦截器后，不要忘记将这个拦截器配置到 MyBatis 全局配置文件中：
<plugins>
<plugin interceptor="com.linkedbear.mybatis.plugin.CustomInterceptor"/>
</plugins>
OK ，这样就一切就绪了。
2.2 测试运行
既然是拦截 update 方法，那我们就需要执行一个写操作，这样吧，我们直接把 MyBatisApplication6 中的测试逻辑抄过来，直接在这个基础上修改：
public class InterceptorApplication {
public static void main(String[] args) throws Exception {
InputStream xml = Resources.getResourceAsStream("mybatis-config.xml");
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(xml);
SqlSession sqlSession = sqlSessionFactory.openSession();
DepartmentMapper departmentMapper = sqlSession.getMapper(DepartmentMapper.class);
Department department = departmentMapper.findById("18ec781fbefd727923b0d35740b177ab");
System.out.println(department);
department.setName("技术开发部");
departmentMapper.update(department);
sqlSession.commit();
sqlSession.close();
}
}
最后的 departmentMapper.update 动作，就会触发 Executor 的 update 方法，也就可以触发拦截器的逻辑了。
运行 main 方法，控制台中可以成功打印拦截器执行的逻辑：
Department{id='18ec781fbefd727923b0d35740b177ab', name='开发部', tel='123'}]
CustomInterceptor intercept run ......
org.apache.ibatis.executor.CachingExecutor@418e7838
update
[org.apache.ibatis.mapping.MappedStatement@61230f6a, Department{id='18ec781fbefd727923b0d35740b177ab', name='技术开发部', tel='123'}]
2.3 拦截query方法
上面我们介绍了拦截 update 方法，其他的套路也是一样的，我们再演示一个 query 方法的拦截方式：
@Intercepts(@Signature(type = Executor.class, method = "query",
args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}))
public class CustomInterceptor implements Interceptor {
@Override
public Object intercept(Invocation invocation) throws Throwable {
System.out.println("CustomInterceptor intercept run ......");
System.out.println(invocation.getTarget());
System.out.println(invocation.getMethod().getName());
// 这里我们只关心参数内容
System.out.println(invocation.getArgs()[1]);
return invocation.proceed();
}
}
随后直接重新运行 InterceptorApplication 的 main 方法，控制台就可以打印出查询的相关信息了：
CustomInterceptor intercept run ......
org.apache.ibatis.executor.CachingExecutor@6737fd8f
query
18ec781fbefd727923b0d35740b177ab
OK ，了解了基本的使用方法之后，下面我们来实战编写一个简单的插件：性能分析插件。
3. 实战：性能分析插件
先说一下需求吧，我们在执行 SQL 时难免会碰到慢 SQL ，这种情况下如果有一个比较好的机制，能帮我们把执行较慢的 SQL 都筛出来，那自然是极好的。所以我们来试着做一下这个性能分析的插件。
3.1 拦截哪些方法呢
首先我们考虑一下，哪些方法需要被拦截呢？只有查询吗？
貌似部分增删改也要添加吧，不然遇到这种 SQL 咋办：
insert into tbl_department (...) values (...), (...), (...), (...), (...), (...)
假设后面的 values 非常长，好几万条，那这条 SQL 的执行效率肯定也是不高的，所以增删改查都需要拦截。
所以我们可以先把拦截器创建出来，并打上注解：
@Intercepts({
@Signature(type = StatementHandler.class, method = "query", args = {Statement.class, ResultHandler.class}),
@Signature(type = StatementHandler.class, method = "update", args = {Statement.class})
})
public class PerformanceInterceptor implements Interceptor { ... }
简单说一下为什么选择拦截 StatementHandler 的 update 和 query 方法，检查 SQL 的性能好不好，最好是不要带入 MyBatis 框架本身的执行逻辑耗时，而且 StatementHandler 的 update 和 query 方法，在底层都有一个 Statement 对象的 **execute** 方法执行，而这个 execute 就是执行 SQL 的动作，所以拦截 StatementHandler 之后监控的执行时间更具有参考意义。
3.2 怎么计算耗时呢
最简单的办法当然是取两次时间戳，然后比较一下看差值，当差值超过阈值后，打印警告日志：
@Override
public Object intercept(Invocation invocation) throws Throwable {
System.out.println("PerformanceInterceptor intercept run ......");
long startTime = System.currentTimeMillis();
Object retVal = invocation.proceed();
long endTime = System.currentTimeMillis();
// 此处我们先写死1000ms吧
if (endTime - startTime > 1000) {
// 打印。。。
}
return retVal;
}
但是怎么打印呢？这个难度有点大，因为通过 Invocation 取到的 Statement 是一个被 MyBatis 代理过的对象：
我们需要取它内部的 target ，也就是那个 "h" ，所以这里面实现起来有一点点的别扭：
@Override
public Object intercept(Invocation invocation) throws Throwable {
// ......
if (endTime - startTime > 1000) {
Statement statement = (Statement) invocation.getArgs()[0];
// statement被MyBatis代理了一层，需要取到target
Field targetField = statement.getClass().getSuperclass().getDeclaredField("h");
targetField.setAccessible(true);
PreparedStatementLogger target = (PreparedStatementLogger) targetField.get(statement);
PreparedStatement preparedStatement = target.getPreparedStatement();
String statementToString = preparedStatement.toString();
System.out.println("发现慢SQL：" + statementToString);
System.out.println("执行时间：" + (endTime - startTime) + "ms");
}
return retVal;
}
简单解释一下为什么要这么写，要取代理对象内部的 target ，最简单的办法是使用反射获取，获取到的 target 是一个 PreparedStatementLogger ，它本来是一个装饰者，我们要获取到内部的 delegate ，也就是真正的 PreparedStatement ，这个 Statement 中就有要执行的 SQL ，直接 toString 一下就可以看到了。
这里可能有小伙伴进一步提出疑惑，既然上面 Debug 的时候都看到了，PreparedStatement 中有个 originalSql 属性存放着 SQL ，为什么不把它拿出来呢？是这样的，上面我们看到的 JDBC42PreparedStatement 是 MySQL 驱动包下的，如果回头我们换成 Oracle 或者 PostgreSQL 等其他数据库，那对应的驱动中 SQL 的属性叫什么，我们也不敢确定，总不能因为获取一个 SQL 而考虑适配所有数据库吧，这貌似划不来，所以我们直接 toString 一下就可以了。
OK ，编写完毕之后，不要忘记把插件注册到 MyBatis 全局配置文件中：
<plugins>
<!-- 为防止干扰，先把之前的注释掉
<plugin interceptor="com.linkedbear.mybatis.plugin.CustomInterceptor"/>
-->
<plugin interceptor="com.linkedbear.mybatis.plugin.PerformanceInterceptor"/>
</plugins>
一切准备就绪，下面我们准备测试。
3.3 测试效果
我们可以直接重新运行上面的 InterceptorApplication ，里面有一个 findById 的方法，就可以触发这个拦截器的逻辑了。
OK ，我们直接运行 main 方法，观察控制台的打印：
[main] DEBUG DepartmentMapper.findById - ==> Preparing: select * from tbl_department where id = ?
PerformanceInterceptor intercept run ......
[main] DEBUG DepartmentMapper.findById - ==> Parameters: 18ec781fbefd727923b0d35740b177ab(String)
[main] DEBUG DepartmentMapper.findById - <== Total: 1
Department{id='18ec781fbefd727923b0d35740b177ab', name='技术开发部', tel='123'}
可见拦截器确实运行了，但这条 SQL 的执行效率远没有那么慢，所以下面的慢 SQL 打印逻辑也就没出来。我们可以改一下慢 SQL 的时间阈值为 10ms ，这样几乎所有的 SQL 都会打印了：
public Object intercept(Invocation invocation) throws Throwable {
System.out.println("PerformanceInterceptor intercept run ......");
long startTime = System.currentTimeMillis();
Object retVal = invocation.proceed();
long endTime = System.currentTimeMillis();
if (endTime - startTime > 10) {
// ......
}
return retVal;
}
重新运行 main 方法，控制台这次可以打印出 SQL 了：
[main] DEBUG DepartmentMapper.findById - ==> Preparing: select * from tbl_department where id = ?
PerformanceInterceptor intercept run ......
[main] DEBUG DepartmentMapper.findById - ==> Parameters: 18ec781fbefd727923b0d35740b177ab(String)
[main] DEBUG DepartmentMapper.findById - <== Total: 1
发现慢SQL：com.mysql.jdbc.JDBC42PreparedStatement@3c130745: select * from tbl_department where id = '18ec781fbefd727923b0d35740b177ab'
执行时间：28ms
Department{id='18ec781fbefd727923b0d35740b177ab', name='技术开发部', tel='123'}
到这里我们的性能分析插件其实就算编写完了，但这里面有几个细节可以优化一下。
3.4 优化细节
3.4.1 打印的内容
首先我们观察一下打印的内容：
发现慢SQL：com.mysql.jdbc.JDBC42PreparedStatement@3c130745: select * from tbl_department where id = '18ec781fbefd727923b0d35740b177ab'
很明显我们只想要最后面的 SQL 吧，前面那一堆东西我们根本不需要，所以我们可以就 PreparedStatement 转成 String 后再处理一下，处理的思路就是把前面的这些鬼东西去掉。
注意这里不能直接莽撞着去截字符串，因为不同的 jdbc 数据库驱动，toString 后的内容是不一样的，比方说 PostgreSQL 中的 PreparedStatement 打印之后的内容是没有那些乱七八糟的，直接就是 SQL ：
所以我们要换一种思路：要么，直接把 SQL 截出来吧，管他前面有啥呢，我都不管。
[main] DEBUG jdbc.JdbcTransaction - Opening JDBC Connection
[main] DEBUG led.PooledDataSource - Created connection 789219251.
[main] DEBUG jdbc.JdbcTransaction - Setting autocommit to false on JDBC Connection [org.postgresql.jdbc.PgConnection@2f0a87b3]
select * from tbl_department
OK ，有了上面的分析，下面我们可以试着截一下 SQL ，那截取 SQL 的思路有很多了，可以用 indexOf 的方式，也可以用正则表达式直接提取，这里小册演示一下用正则表达式取 SQL ：
private String getSql(String statementToString) {
// 借助正则表达式的贪心特性，可以保证一次性取到最后
Pattern pattern = Pattern.compile("(select |insert |update |delete ).*");
Matcher matcher = pattern.matcher(statementToString);
if (matcher.find()) {
return matcher.group();
}
return statementToString;
}
之后改一下打印的内容，调用一下 getSql 方法即可：
String statementToString = preparedStatement.toString();
System.out.println("发现慢SQL：" + getSql(statementToString));
OK ，下面我们再运行一下 main 方法，观察控制台的打印：
[main] DEBUG DepartmentMapper.findById - ==> Preparing: select * from tbl_department where id = ?
PerformanceInterceptor intercept run ......
[main] DEBUG DepartmentMapper.findById - ==> Parameters: 18ec781fbefd727923b0d35740b177ab(String)
[main] DEBUG DepartmentMapper.findById - <== Total: 1
发现慢SQL：select * from tbl_department where id = '18ec781fbefd727923b0d35740b177ab'
执行时间：37ms
[main] DEBUG DepartmentMapper.update - ==> Preparing: update tbl_department set name = ?, tel = ? where id = ?
PerformanceInterceptor intercept run ......
[main] DEBUG DepartmentMapper.update - ==> Parameters: 技术开发部(String), 123(String), 18ec781fbefd727923b0d35740b177ab(String)
[main] DEBUG DepartmentMapper.update - <== Updates: 1
发现慢SQL：update tbl_department set name = '技术开发部', tel = '123' where id = '18ec781fbefd727923b0d35740b177ab'
执行时间：45ms
可以发现这次打印的 SQL 是干干净净的了，非常符合我们预期！
3.4.2 硬编码参数
再回过头来看一下我们设定的慢 SQL 时间阈值：
if (endTime - startTime > 10) {
这个 10 很明显被写死了，我们可以充分利用 MyBatis 给我们提供的外部化配置的特性，将这个 10 写到 MyBatis 全局配置文件中：
<plugin interceptor="com.linkedbear.mybatis.plugin.PerformanceInterceptor">
<!-- 最大容忍时间 -->
<property name="maxTolerate" value="10"/>
</plugin>
之后我们回到拦截器中，相应的定义一个同名的成员属性：
public class PerformanceInterceptor implements Interceptor {
private long maxTolerate;
有了这个属性之后，MyBatis 并不会那么智能的帮我们赋属性值，而是在 Interceptor 接口中预留了一个 default 的 setProperties 方法供我们手动赋属性值，所以我们可以重写这个方法，自己赋值：
@Override
public void setProperties(Properties properties) {
this.maxTolerate = Long.parseLong(properties.getProperty("maxTolerate"));
}
这样就不会写死了，最后改一下 intercept 中写死的值，换为这个变量：
if (endTime - startTime > maxTolerate) {
OK ，改好之后我们重新运行 main 方法，可以发现一切正常，所以通过这种外部化配置方式，就解决了参数硬编码的问题。
到此为止，我们就自己实现了一个性能分析插件。
4. 插件生效机制
首先我们先来看看插件是如何加载到 MyBatis 全局的。
4.1 插件的加载
在 MyBatis 全局配置文件的加载中，我们看到了 <plugins> 标签的处理位置是在这里：
private void pluginElement(XNode parent) throws Exception {
if (parent != null) {
for (XNode child : parent.getChildren()) {
String interceptor = child.getStringAttribute("interceptor");
Properties properties = child.getChildrenAsProperties();
// 直接创建拦截器对象
Interceptor interceptorInstance = (Interceptor) resolveClass(interceptor).getDeclaredConstructor().newInstance();
// 拦截器的属性赋值
interceptorInstance.setProperties(properties);
configuration.addInterceptor(interceptorInstance);
}
}
}
本身这个逻辑不复杂，不过当时我们看源码的时候没有进入最后一句，这个 configuration.addInterceptor(interceptorInstance); 可有点讲究。我们进入 addInterceptor 方法：
protected final InterceptorChain interceptorChain = new InterceptorChain();
public void addInterceptor(Interceptor interceptor) {
interceptorChain.addInterceptor(interceptor);
}
注意看，它将创建好的插件放入了一个 InterceptorChain 中！很明显这是一个拦截器链，它是怎么设计的呢？
4.2 InterceptorChain的设计
这个 InterceptorChain 的设计本身并不很复杂，它的内部就是组合了一个 Interceptor 的集合，配合几个方法而已：
public class InterceptorChain {
private final List<Interceptor> interceptors = new ArrayList<>();
public Object pluginAll(Object target) {
for (Interceptor interceptor : interceptors) {
target = interceptor.plugin(target);
}
return target;
}
public void addInterceptor(Interceptor interceptor) {
interceptors.add(interceptor);
}
public List<Interceptor> getInterceptors() {
return Collections.unmodifiableList(interceptors);
}
}
其中这个 pluginAll 方法的使用，我们之前见过几次，可能小伙伴们没有留意，我们可以回顾一下。
MyBatis 的插件可以对四种组件进行增强：
Executor ( update, query, flushStatements, commit, rollback, getTransaction, close, isClosed )
ParameterHandler ( getParameterObject, setParameters )
ResultSetHandler ( handleResultSets, handleOutputParameters )
StatementHandler ( prepare, parameterize, batch, update, query )
所以在创建这四种组件的时候，肯定不是普通的 new 出来，而是 Configuration 统一创建：（以其中两个为例）
public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
executorType = executorType == null ? defaultExecutorType : executorType;
executorType = executorType == null ? ExecutorType.SIMPLE : executorType;
Executor executor;
if (ExecutorType.BATCH == executorType) {
executor = new BatchExecutor(this, transaction);
} else if (ExecutorType.REUSE == executorType) {
executor = new ReuseExecutor(this, transaction);
} else {
executor = new SimpleExecutor(this, transaction);
}
if (cacheEnabled) {
executor = new CachingExecutor(executor);
}
// 插件增强
executor = (Executor) interceptorChain.pluginAll(executor);
return executor;
}
public ParameterHandler newParameterHandler(MappedStatement mappedStatement, Object parameterObject, BoundSql boundSql) {
ParameterHandler parameterHandler = mappedStatement.getLang().createParameterHandler(mappedStatement, parameterObject, boundSql);
// 插件增强
parameterHandler = (ParameterHandler) interceptorChain.pluginAll(parameterHandler);
return parameterHandler;
}
可以看到，全局 Configuration 对象创建这些核心组件的时候，都是先创建出原始的目标对象，然后用哪个 InterceptorChain 去包装（代理），从而得到代理对象。所以 InterceptorChain 的 pluginAll 方法是我们要着重去看的。
4.3 pluginAll
这个 pluginAll 方法本身并不难，本身是调用每一个插件的 plugin 方法：
public Object pluginAll(Object target) {
for (Interceptor interceptor : interceptors) {
target = interceptor.plugin(target);
}
return target;
}
default Object plugin(Object target) {
return Plugin.wrap(target, this);
}
// Plugin
public static Object wrap(Object target, Interceptor interceptor) {
// 4.3.1 获取所有要增强的方法
Map<Class<?>, Set<Method>> signatureMap = getSignatureMap(interceptor);
Class<?> type = target.getClass();
Class<?>[] interfaces = getAllInterfaces(type, signatureMap);
if (interfaces.length > 0) {
// 4.3.2 注意这个Plugin就是自己
return Proxy.newProxyInstance(type.getClassLoader(), interfaces, new Plugin(target, interceptor, signatureMap));
}
return target;
}
而每个 Interceptor 的 plugin 方法，都是会来到 Plugin.wrap 方法，这个逻辑有一点点小复杂，我们对其中比较关键的两步拆解开。
4.3.1 获取所有要增强的方法
代理之前，肯定要先看看这个插件（拦截器）能增强哪些方法，所以这里他会收集 Interceptor 上的 @Intercepts 注解，并得到其中的 Signature 注解数组，逐个解析其中的方法。源码本身并不复杂，各位对照着注释看一下就可以。
先回顾下上面的例子：
@Intercepts({
@Signature(type = StatementHandler.class, method = "query", args = {Statement.class, ResultHandler.class}),
@Signature(type = StatementHandler.class, method = "update", args = {Statement.class})
})
public class PerformanceInterceptor implements Interceptor { ... }
private static Map<Class<?>, Set<Method>> getSignatureMap(Interceptor interceptor) {
// 获取@Intercepts注解
Intercepts interceptsAnnotation = interceptor.getClass().getAnnotation(Intercepts.class);
if (interceptsAnnotation == null) {
throw new PluginException("No @Intercepts annotation was found in interceptor " + interceptor.getClass().getName());
}
// 获取其中的@Signature注解
Signature[] sigs = interceptsAnnotation.value();
Map<Class<?>, Set<Method>> signatureMap = new HashMap<>();
for (Signature sig : sigs) {
// 逐个方法名、参数解析，确保能代理到这些方法
Set<Method> methods = signatureMap.computeIfAbsent(sig.type(), k -> new HashSet<>());
try {
Method method = sig.type().getMethod(sig.method(), sig.args());
methods.add(method);
} // catch ......
}
return signatureMap;
}
4.3.2 创建Plugin对象
最后，它会在 Proxy.newProxyInstance 时创建代理对象，请注意，这里传入了一个 Plugin 对象，也就是当前我们正在看的这个类，对，它本身实现了 InvocationHandler ：
public class Plugin implements InvocationHandler {
// 目标对象
private final Object target;
// 拦截器对象
private final Interceptor interceptor;
// 记录了@Signature注解的信息
private final Map<Class<?>, Set<Method>> signatureMap;
留意一下这个 Plugin 中组合的属性，它里面把接下来插件运行期需要使用的信息都包含了，所以后面在调用代理对象的方法时，这里就可以予以执行了。
OK ，正好我们把整个插件生效的流程都看完了，下面我们就来看 MyBatis 在实际运行期间，插件是如何运行的。
5. 插件运行机制
承接上一小节，Plugin 本身是一个 InvocationHandler ，所以每次代理对象执行的时候，首先会触发它的 invoke 方法：
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
try {
// 检查@Signature注解的信息中是否包含当前正在执行的方法
Set<Method> 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);
}
}
看到中间的 interceptor.intercept(new Invocation(target, method, args)); 是不是非常有感觉了！对了，它就是我们写的那些 Interceptor 要实现的核心 intercept 方法啊，传入的参数就是我们在重写 intercept 方法中拿到的那个 Invocation 对象。所以 MyBatis 的插件运行并没有什么特殊的，就是这么简单。
另外我们可以看看 Invocation 的结构，它本身也很简单，并且它的 proceed 方法就是继续放行原方法的执行：
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;
}
// getter
public Object proceed() throws InvocationTargetException, IllegalAccessException {
return method.invoke(target, args);
}
}
到此为止，MyBatis 的插件机制原理，我们也就全部了解完毕了。
