mybatis源码（五）springboot pagehelper实现查询分页

1、背景

springboot的pagehelper插件能够实现对mybatis查询的分页管理，而且在使用时只需要提前声明即可，不需要修改已有的查询语句。使用如下：

之前对这个功能一直很感兴趣，但是一直没完整看过，今天准备详细梳理下。按照个人的习惯，我喜欢带着问题去看源码，这次浏览源码我希望可以了解以下两个问题：
1）分页插件什么时候被加载的
2）分页插件什么时候生效的，如何生效的

2、技巧（可跳过）

mybatis自身的功能原理这里我们不深入探讨，网上文章很多，我之前也写过类似的文章，这里为了防止文章杂乱，我们只关注感兴趣的点，即mybatis pagehelper分页原理，其它的一笔带过。另外因为mybatis查询生效都是用的代理对象。如果对源码不是很熟悉，很难第一时间找到打断点的位置。不过通过查看page的源码可以知道，最后的分页参数都放到了threadlocal对象里，如下：

而最后使用该threadlocal时是一定会调用它的获取和移除方法，因此我们在它的这两个方法中加断点。等进入断点后再通过方法栈追踪其全流程。如下：

3、源码追踪流程

有了上述方法栈的查看，我们知道了查询的入口和大体流程，现在重新执行查询跟随源码脚步来详细看下分页的实现逻辑。首先是在代码中我们主动进行分页查询，如下：

前三行代码很简单，主要是从httpservletrequest中获取分页参数，并设置到当前线程的threadlocal变量中。第四行则是调用接口方法进行查询。在mybatis中，接口方法最终功能的实现主要是依靠MapperProxy代理类实现（代理类中包含接口和xml配置相关信息），所以接下来我们直接到MapperProxy中打断点追踪（至于mybatis如何关联接口和mapper.xml文件，MapperProxy如何生成等问题不是本文讨论重点，感兴趣的可以单独去查阅或者浏览我以前的相关文章）。

MapperProxy是代理对象，主要调用方法是invoke方法，所以在该方法中加断点，或者依靠第二步中的技巧查看整个查询的方法栈，随后再在MapperProxy对应的行中加断点。具体断点信息如下：

因为method不是Object类型，所以执行else里面的代码：

可以看到最后会执行PlainMethodInvoker对象里的invoke方法，所以我们接着到该方法中打断点并继续追踪查看：

可以看到调用SqlSessionTemplate对象的selectList方法，我们接着向下看：

再接着到DefaultSqlSession中继续查看：

可以看到，最后会调用CachingExecutor的query方法，但是这里要留意一点，那就是CachingExecutor是一个代理对象，执行代理对象方法首先要进入代理，并执行invoke方法。我们这里通过断点调试的步入查看执行哪个类的invoke方法：

可以看到最终是通过Plugin代理实现CachingExecutor对象query方法的调用。我们再接着向下看：

因为要执行的方法是查询方法，其是分页拦截器指定要拦截的方法类型，所以会进入拦截方法中。这里我标记了两个框，第一个是拦截，第二个是不进行拦截直接执行查询方法，因此可以推测分页逻辑是再拦截器中进行的。拦截器中会进行sql的改写，所以这里进入拦截器中进一步查看。拦截器对象为PageInterceptor，到这终于和本文的主题关联上了，接下来我们到分页拦截器中看一下：

可以看到源码中都加好注释了，看起来就更简单了，这里我们看下进入分页的条件：

可以看到最后获取的page对象实际上就是我们一开在代码中传入分页参数创建的page对象。因为page对象不为空，所以会返回false，进而不跳过分页逻辑。（另外这里要提醒下各位小伙伴，page对象继承了ArrayList，所以断点查看时看不得page里面的内容，只能看到其size为0。）

我们接着回到主流程向下看，随后会判断是否需要计算总数，默认创建page时需要计算总数，这里我们就不进入before方法查看了，里面逻辑比较简单。下面我们简单看下计算总数的逻辑：

可以看到其计算总数的sql比较精简，主要是根据查询的对象和条件直接计算总数。这里sql的解析和生成主要是依赖jsqlparser工具类实现(jsqlparser的使用可以参考我以前的文章)，sql解析比较复杂，感兴趣的可以自行查看。接着我们再回到主流程，看下何时添加的分页查询参数：

可以看到最后再sql末尾加了limit分页参数，而这个sql的改写过程与计算count类似，都是通过jsqlparser工具实现的。

通过上面的流程，我们已经知道了分页插件如何生效的了。但是还有一个问题是分页插件如何被加载的。这个流程比较简单，我也是通过第二步的技巧逆推的全流程。下面我按照正常项目的加载顺利简单介绍下：
当我们在pom中引入pageHelper插件依赖并且在yml中配置分页相关的信息时，项目启动后就会主动的进行插件的初始化并注入到插件拦截器链里面。大体逻辑如下：

可以看到分页插件有个配置类，其在项目初始化的时候会创建分页拦截器，并调用Configuration进行添加，接着我们看下最后会将拦截器添加到哪里：

可以看到最终会添加到拦截器链对象的私有集合里。但是我们最终使用拦截器是在Plugin对象里用的，而不是在拦截器链里面，那Plugin如何使用到该拦截器的呢？

在拦截器链里有个pluginAll方法，它会封装拦截器成一个“链式”动态代理对象，代理类是Plugin，该方法会在创建Executor时执行（还记得前面源码里介绍这块的提醒吧，Executor是一个被动态代理的对象），通过pluginAll方法，将拦截器封装成链并将Executor放在链路最后一层。

可以看到通过pluginAll方法将拦截器封装成了一个链，下面再看一下Executor的创建就完全清晰了：

至此，我们两个问题都再浏览源码的过程中清晰了。

4、总结

1）该文章主要是探究sringboot分页插件实现的原理，所以对于mapper.xml与接口方法的整合和mybatis代理对象如何实现查看没有细讲，但是这部分也是查询过程中核心的代码。

2）由PageInterceptor分页拦截器拦截指定的查询请求，然后在拦截方法中调用PageHelper中的方法对sql进行改写，最后再进行提交。

2）无论计算总数还是重写分页sql，都是通过jsqlparser工具实现的（为了使得文章主题清晰，这里没有介绍sql的改写过程，jsqlparser的使用可以浏览我以前的文章）

3）Plugin是一个链式动态代理对象，最后一个节点是Executor被代理对象，前面的节点是Interceptor被代理对象。

4）再Plugin.wrap方法中会提取出拦截器里的signature标签，并保存在每个Plugin链式代理对象中。在被代理对象执行对应方法时，如果plugin代理对象包含对应的signature集合则说明当前被代理对象是拦截器，如果不包含signature或者signature标签没有拦截当前方法，则直接执行当前方法。