Mybatis(十) - 插件

本章我们介绍的是 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 代理过的对象：

img

我们需要取它内部的 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 的插件机制原理，我们也就全部了解完毕了。