我们在使用数据库进行查询时,很多时候会用到分页展示功能,因此除了像mybatis这样的完善的orm框架之外,还有pagehelper这样的插件帮助减轻我们的工作。

  pagehelper的实现方式是,不需要我们去编写分页代码,只需要调用一个分页方法,出来的结果就是经过分页处理的。一来,我们的xml中的sql编写就会灵活很多,二来,它可以帮我们规避各种不同类型的数据库的分页描述方式。所以,总体来说是个好事。

0. 使用pagehelper遇到的坑说明

  现象是这样的:我们有一个场景是查询数据库表中的全量记录返回给第三方,但是突然某一天发现第三方告警说我们给的数据不对了,比如之前会给到200条记录的,某次只给到了10条记录。

  随后我们推出了几个猜想:1. 第三方系统处理数据有bug,漏掉了一些数据;2. 数据库被人临时改掉过,然后又被复原了;3. 数据库bug,在全量select时可能不返回全部记录;

  其实以上猜想都显得有点无厘头,比如数据库怎么可能有这种低级bug?但是人在没有办法的情况下只能胡猜一通了。最后终于发现是pagehelper的原因,因为分页乱套了,复用了其他场景下的分页设置,丢到数据库查询后返回了10条记录;

1. pagehelper的至简使用方式

  本身pagehelper就是一个辅助工具类,所以使用起来一般很简单。尤其在springboot中,只要引用starter类,依赖就可以满足了。(如果是其他版本,则可能需要配置下mybatis的intercepter)

        <!-- https://mvnrepository.com/artifact/com.github.pagehelper/pagehelper-spring-boot-starter -->
<dependency>
<groupId>com.github.pagehelper</groupId>
<artifactId>pagehelper-spring-boot-starter</artifactId>
<version>${pagehelper.version}</version>
</dependency>

  在使用时只需要加上 Page.startPage(pageNum, pageSize) 即可。

    public Object getUsers(int pageNum, int pageSize) {
PageHelper.startPage(pageNum, pageSize);
List<UserEntity> list = userMapper.selectAllWithPage(null);
com.github.pagehelper.Page listWithPage = (com.github.pagehelper.Page) list;
System.out.println("listCnt:" + listWithPage.getTotal());
return list;
}

  而真正的sql里只需按没有分页的样式写一下就可以了。

    <select id="selectAllWithPage" parameterType="java.util.Map"
resultType="com.my.mvc.app.dao.entity.UserEntity">
select * from t_users
</select>

  还是很易用的。少去了一些写死的sql样例。

2. pagehelper实现原理简说

  pagehelper不是什么高深的组件,实际上它就是一个mybatis的一个插件或者拦截器。是mybatis在执行调用时,将请求转发给pagehelper处理,然后由pagehelper包装分页逻辑。

    // com.github.pagehelper.PageInterceptor#intercept
@Override
public Object intercept(Invocation invocation) throws Throwable {
try {
Object[] args = invocation.getArgs();
MappedStatement ms = (MappedStatement) args[0];
Object parameter = args[1];
RowBounds rowBounds = (RowBounds) args[2];
ResultHandler resultHandler = (ResultHandler) args[3];
Executor executor = (Executor) invocation.getTarget();
CacheKey cacheKey;
BoundSql boundSql;
//由于逻辑关系,只会进入一次
if (args.length == 4) {
//4 个参数时
boundSql = ms.getBoundSql(parameter);
cacheKey = executor.createCacheKey(ms, parameter, rowBounds, boundSql);
} else {
//6 个参数时
cacheKey = (CacheKey) args[4];
boundSql = (BoundSql) args[5];
}
checkDialectExists(); List resultList;
//调用方法判断是否需要进行分页,如果不需要,直接返回结果
if (!dialect.skip(ms, parameter, rowBounds)) {
//判断是否需要进行 count 查询
if (dialect.beforeCount(ms, parameter, rowBounds)) {
//查询总数
Long count = count(executor, ms, parameter, rowBounds, resultHandler, boundSql);
//处理查询总数,返回 true 时继续分页查询,false 时直接返回
if (!dialect.afterCount(count, parameter, rowBounds)) {
//当查询总数为 0 时,直接返回空的结果
return dialect.afterPage(new ArrayList(), parameter, rowBounds);
}
}
resultList = ExecutorUtil.pageQuery(dialect, executor,
ms, parameter, rowBounds, resultHandler, boundSql, cacheKey);
} else {
//rowBounds用参数值,不使用分页插件处理时,仍然支持默认的内存分页
resultList = executor.query(ms, parameter, rowBounds, resultHandler, cacheKey, boundSql);
}
return dialect.afterPage(resultList, parameter, rowBounds);
} finally {
if(dialect != null){
dialect.afterAll();
}
}
}

  如果没有分页逻辑需要处理,和普通的没什么差别,如果有分页请求,则会在原来的sql之上套上limit.. offset.. 之类的关键词。从而完成分页效果。

2. 为什么pagehelper的分页会乱套?

  现在我们来说说为什么分页会乱套?原因是 PageHelper.startPage(xx) 的原理是将分页信息设置到线程上下文中,然后在随后的查询中使用该值,使用完成后就将该信息清除。

    /**
* 开始分页
*
* @param pageNum 页码
* @param pageSize 每页显示数量
* @param count 是否进行count查询
*/
public static <E> Page<E> startPage(int pageNum, int pageSize, boolean count) {
return startPage(pageNum, pageSize, count, null, null);
}
/**
* 开始分页
*
* @param pageNum 页码
* @param pageSize 每页显示数量
* @param count 是否进行count查询
* @param reasonable 分页合理化,null时用默认配置
* @param pageSizeZero true且pageSize=0时返回全部结果,false时分页,null时用默认配置
*/
public static <E> Page<E> startPage(int pageNum, int pageSize, boolean count, Boolean reasonable, Boolean pageSizeZero) {
Page<E> page = new Page<E>(pageNum, pageSize, count);
page.setReasonable(reasonable);
page.setPageSizeZero(pageSizeZero);
//当已经执行过orderBy的时候
Page<E> oldPage = getLocalPage();
if (oldPage != null && oldPage.isOrderByOnly()) {
page.setOrderBy(oldPage.getOrderBy());
}
setLocalPage(page);
return page;
}
protected static final ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal<Page>(); /**
* 设置 Page 参数
*
* @param page
*/
protected static void setLocalPage(Page page) {
LOCAL_PAGE.set(page);
} // com.github.pagehelper.PageHelper#afterAll
@Override
public void afterAll() {
//这个方法即使不分页也会被执行,所以要判断 null
AbstractHelperDialect delegate = autoDialect.getDelegate();
if (delegate != null) {
delegate.afterAll();
autoDialect.clearDelegate();
}
clearPage();
} /**
* 移除本地变量
*/
public static void clearPage() {
LOCAL_PAGE.remove();
}

  那么什么情况下会导致分页信息乱套呢?实际上就是线程变量什么情况会被乱用呢?线程被复用的时候,将可能导致该问题。比如某个请求将某个线程设置了一个线程变量,然后随后另一个请求复用了该线程,那么这个变量就被复用过去了。那么什么情况下线程会被复用呢?一般是线程池、连接池等等。是的,大概就是这么原理了。

  

3. 分页问题复现

  既然从理论上说明了这个问题,能否稳定复现呢?咱们编写下面的,很快就复现了。

@RestController
@RequestMapping("/hello")
@Slf4j
public class HelloController { @Resource
private UserService userService; // 1. 先请求该getUsers接口,将得到异常,pageNum=1, pageSize=1
@GetMapping("getUsers")
@ResponseBody
public Object getUsers(int pageNum, int pageSize) {
return userService.getUsers(pageNum, pageSize);
} // 2. 多次请求该 getAllActors接口,正常情况下会得到N条全表记录,但将会偶发地得到只有一条记录,现象复现
@GetMapping("getAllActors")
@ResponseBody
public Object getAllActors() {
return userService.getAllActors();
}
} @Service
@Slf4j
public class UserService { @Resource
private UserMapper userMapper; public Object getUsers(int pageNum, int pageSize) {
PageHelper.startPage(pageNum, pageSize);
// 此处强行抛出异常, 使以上 pagehelper 信息得以保存
throw new RuntimeException("exception ran");
} public Object getAllActors() {
// 正常的全表查询
List<ActorEntity> list = userMapper.selectAllActors();
return list;
}
}

  验证步骤及结果如下:(数据方面,自己随便找一些表就好了)

// 步骤1: 发送请求: http://localhost:8081/hello/getUsers?pageNum=1&pageSize=1
// 步骤2: 发送请求: http://localhost:8081/hello/getAllActors
// 正常时返回
[{"actorId":1,"firstName":"PENELOPE","lastName":null,"lastUpdate":null},{"actorId":2,"firstName":"NICK","lastName":null,"lastUpdate":null},{"actorId":3,"firstName":"ED","lastName":null,"lastUpdate":null},{"actorId":4,"firstName":"JENNIFER","lastName":null,"lastUpdate":null},{"actorId":5,"firstName":"JOHNNY","lastName":null,"lastUpdate":null},{"actorId":6,"firstName":"BETTE","lastName":null,"lastUpdate":null},{"actorId":7,"firstName":"GRACE","lastName":null,"lastUpdate":null},{"actorId":8,"firstName":"MATTHEW","lastName":null,"lastUpdate":null},{"actorId":9,"firstName":"JOE","lastName":null,"lastUpdate":null},{"actorId":10,"firstName":"CHRISTIAN","lastName":null,"lastUpdate":null},{"actorId":11,"firstName":"ZERO","lastName":null,"lastUpdate":null},{"actorId":12,"firstName":"KARL","lastName":null,"lastUpdate":null},{"actorId":13,"firstName":"UMA","lastName":null,"lastUpdate":null},{"actorId":14,"firstName":"VIVIEN","lastName":null,"lastUpdate":null},{"actorId":15,"firstName":"CUBA","lastName":null,"lastUpdate":null},{"actorId":16,"firstName":"FRED","lastName":null,"lastUpdate":null},... // 出异常时返回
[{"actorId":1,"firstName":"PENELOPE","lastName":null,"lastUpdate":null}]

  以上,几乎都可以复现该现象。实际上该问题由于tomcat的连接池复用导致的,本身和pagehelper关联不是很大,但是在此处却可能带来比较大的影响。这也警示我们使用ThreadLocal 时,一定要小心清理,否则将产生难以预料的结果。而且将很难排查。供诸君参考。

pagehelper踩坑记之分页乱套的更多相关文章

  1. Spark踩坑记——Spark Streaming+Kafka

    [TOC] 前言 在WeTest舆情项目中,需要对每天千万级的游戏评论信息进行词频统计,在生产者一端,我们将数据按照每天的拉取时间存入了Kafka当中,而在消费者一端,我们利用了spark strea ...

  2. Spark踩坑记——数据库(Hbase+Mysql)

    [TOC] 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值.最近一个实时消费者处理任务,在使用spark streami ...

  3. 【踩坑记】从HybridApp到ReactNative

    前言 随着移动互联网的兴起,Webapp开始大行其道.大概在15年下半年的时候我接触到了HybridApp.因为当时还没毕业嘛,所以并不清楚自己未来的方向,所以就投入了HybridApp的怀抱. Hy ...

  4. Spark踩坑记——共享变量

    [TOC] 前言 Spark踩坑记--初试 Spark踩坑记--数据库(Hbase+Mysql) Spark踩坑记--Spark Streaming+kafka应用及调优 在前面总结的几篇spark踩 ...

  5. Spark踩坑记——从RDD看集群调度

    [TOC] 前言 在Spark的使用中,性能的调优配置过程中,查阅了很多资料,之前自己总结过两篇小博文Spark踩坑记--初试和Spark踩坑记--数据库(Hbase+Mysql),第一篇概况的归纳了 ...

  6. djangorestframework+vue-cli+axios,为axios添加token作为headers踩坑记

    情况是这样的,项目用的restful规范,后端用的django+djangorestframework,前端用的vue-cli框架+webpack,前端与后端交互用的axios,然后再用户登录之后,a ...

  7. HttpWebRequest 改为 HttpClient 踩坑记-请求头设置

    HttpWebRequest 改为 HttpClient 踩坑记-请求头设置 Intro 这两天改了一个项目,原来的项目是.net framework 项目,里面处理 HTTP 请求使用的是 WebR ...

  8. vue踩坑记

    vue踩坑记 易错点 语法好难啊qwq 不要把'data'写成'date' 在v-html/v-bind中使用vue变量时不需要加变量名 在非vue事件中使用vue中变量时需要加变量名 正确 < ...

  9. 【bug记录】OS Lab4 踩坑记

    OS Lab4 踩坑记 Lab4在之前Lab3的基础上,增加了系统调用,难度增加了很多.而且加上注释不详细,开玩笑的指导书,自己做起来困难较大.也遇到了大大小小的bug,调试了一整天. 本文记录笔者在 ...

  10. 【bug记录】OS Lab3 踩坑记

    OS Lab3 踩坑记 Lab3在之前Lab2的基础上,增加了进程建立.调度和中断异常处理.其中测试包括进程建立以及进程调度部分. 由于是第一次做bug记录,而且是调试完bug后再做的记录,所以导致记 ...

随机推荐

  1. Svelte Ui Admin后台管理系统|svelte3+svelteUI中后台前端解决方案

    基于svelte3.x+svelteKit+svelte-ui网页后台管理系统SvelteAdmin. Svelte-Ui-Admin 基于svelte3.x+svelteKit+vite3+echa ...

  2. 日志收集工具 Fluentd 使用教程

    转载自:https://mp.weixin.qq.com/s?__biz=MzU4MjQ0MTU4Ng==&mid=2247499829&idx=1&sn=1f92daa88d ...

  3. Elasitcsearch7.X集群/索引备份与恢复实战

    文章转载自:https://mp.weixin.qq.com/s/_0RlojDsE30CeDSyLNP44w 1.问题引出 ES中文社区中,有如下问题: 问题1:存储数据,data目录从一个机器直接 ...

  4. 监控Redis集群--废弃,使用新教程

    prometheus监控redis需要用到redis_exporter. redis_exporter 项目地址:https://github.com/oliver006/redis_exporter ...

  5. golang channel底层结构和实现

    一.介绍 Golang 设计模式: 不要通过共享内存来通信,而要通过通信实现内存共享 channel是基于通信顺序模型(communication sequential processes, CSP) ...

  6. 关于aws-Global区的新账户的一些限制坑点

    在使用global-aws的时候,遇到几个限制坑点记录如下(都是需要发请求找aws服务支持才能提高) 1.关于Elastic IPs的限制,默认为 5,这样在ec2下的Elastic IPs中最多只能 ...

  7. P6189 [NOI Online #1 入门组] 跑步 (DP/根号分治)

    (才了解到根号分治这样的妙方法......) 将每个数当成一种物品,最终要凑成n,这就是一个完全背包问题,复杂度O(n2),可以得80分(在考场上貌似足够了......) 1 #include < ...

  8. 华为云ubunbu部署.NetCore3.1项目(DDD商城)

    提前项目打包发布,文件传输工具Filezilla,注意是选择sftp协议,将publish文件传到/home文件夹下 第一步  .NetCoreSDK安装 微软官方的文档https://docs.mi ...

  9. virtualbox的Linux虚拟磁盘大小调整及注意事项

    virtualBox 调整磁盘分区 起因 起初安装centos6.3 时,没有修改默认的硬盘空间.只有8G,导致后面安装完zookeeper,jdk之后,在安装mysql发现磁盘空间不足 扩容步骤 1 ...

  10. 常用RE对照表——敬请期待!!!

    .* #任意长度任意字符