1. 问题现象偶现的菜单数据丢失那天早上客服反馈了一个奇怪的问题新开通租户的用户在系统中只能看到部分菜单而实际上套餐对应的功能菜单应该有100多个。经过排查发现系统初始化时只插入了50个菜单记录。更诡异的是测试环境复现时一切正常菜单数据完整同步。这个问题只在生产环境偶现而且每次丢失的数据量都精准地卡在50条。作为开发人员我立刻意识到这个数字很眼熟——这不正是我们系统中分页插件的默认每页记录数吗2. PageHelper分页机制解析2.1 PageHelper的基本工作原理PageHelper是MyBatis的一个分页插件它的核心实现原理是通过拦截器机制。具体来说当调用PageHelper.startPage()方法时会在当前线程的ThreadLocal中设置分页参数后续执行的SQL语句会被PageInterceptor拦截拦截器检查ThreadLocal中是否存在分页参数如果存在就会在原始SQL后自动拼接LIMIT子句实现分页这种设计的好处是开发者无需在每个DAO方法中重复编写分页逻辑只需在Service层调用startPage()后续的查询就会自动分页。2.2 ThreadLocal的使用与风险PageHelper使用ThreadLocal来存储分页参数这种设计带来了便利但也埋下了隐患protected static final ThreadLocalPage LOCAL_PAGE new ThreadLocalPage(); public static E PageE startPage(int pageNum, int pageSize) { PageE page new PageE(pageNum, pageSize); setLocalPage(page); return page; } protected static void setLocalPage(Page page) { LOCAL_PAGE.set(page); }ThreadLocal的特性是线程隔离的这意味着每个线程有自己的分页参数副本参数在线程生命周期内持续有效如果不清除参数会被后续操作继承3. 问题根因分析3.1 异常分页的场景还原在我们的案例中问题代码是这样的PostMapping(/findListByMenuIds) public ResultVOListMenuFunVO findListByMenuIds(RequestBody ListString menuIds){ ListMenuFunVO menuFunList this.menuFunService.findListByMenuIds(menuIds); return RV.success(menuFunList); }表面看这只是一个普通的查询没有分页逻辑。但问题出在框架的基类中protected T PageT startPage(){ int pageNumInt CharacterUtils.parseInt(request.getParameter(pageNum),1); int pageSizeInt CharacterUtils.parseInt(request.getParameter(pageSize),50); return PageHelper.startPage(pageNumInt, pageSizeInt); }某些情况下这个startPage()方法被意外调用了但没有紧跟MyBatis查询导致分页参数被设置到ThreadLocal中没有执行SQL查询所以拦截器的清理逻辑未触发线程回到线程池时仍带着分页参数当下一个请求复用这个线程时非分页查询也被强制分页3.2 为什么问题偶现这个问题不是每次都会出现原因在于Tomcat等容器使用线程池处理请求只有复用了被污染的线程时才会出现问题在低并发时线程复用率低问题不易出现高并发时线程频繁复用问题出现概率增大4. PageHelper源码深度解析4.1 拦截器核心逻辑PageInterceptor是PageHelper的核心其intercept方法主要流程public Object intercept(Invocation invocation) throws Throwable { try { // 获取分页参数 Page page getLocalPage(); if(page ! null) { // 执行分页逻辑 resultList ExecutorUtil.pageQuery(...); } else { // 普通查询 resultList executor.query(...); } return resultList; } finally { clearPage(); // 清理ThreadLocal } }关键点在于只有在正常执行到finally块时才会清理ThreadLocal。4.2 典型的问题场景以下情况会导致ThreadLocal未被清理远程调用分页Page page startPage(); // 设置了分页参数 remoteService.query(data); // 实际是HTTP调用不走MyBatis拦截器 // ThreadLocal未被清除MongoDB等非MyBatis查询Page page startPage(); // 设置了分页参数 mongoTemplate.find(query, Entity.class); // 不走MyBatis // ThreadLocal未被清除异常提前退出Page page startPage(); if(someCheck) throw new Exception(); // 抛出异常 mapper.selectList(); // 未执行 // ThreadLocal未被清除5. 解决方案与最佳实践5.1 立即修复方案对于已经出现的问题可以采取以下临时解决方案手动清除ThreadLocalPostMapping(/findListByMenuIds) public ResultVOListMenuFunVO findListByMenuIds(RequestBody ListString menuIds){ PageHelper.clearPage(); // 手动清除 ListMenuFunVO menuFunList this.menuFunService.findListByMenuIds(menuIds); return RV.success(menuFunList); }禁用自动分页Bean public PageInterceptor pageInterceptor() { PageInterceptor interceptor new PageInterceptor(); Properties properties new Properties(); properties.setProperty(autoRuntimeDialect, false); interceptor.setProperties(properties); return interceptor; }5.2 长期最佳实践严格遵循使用规范startPage()后必须紧跟MyBatis查询不要将startPage()放在基类或AOP中非MyBatis查询使用显式分页参数改造远程调用分页// 改造前 Page page startPage(); remoteService.query(data); // 改造后 PageParam param new PageParam(); param.setPageNum(1); param.setPageSize(50); remoteService.query(data, param);添加监控告警Aspect Component public class PageHelperMonitorAspect { AfterReturning(execution(* com..mapper.*.*(..))) public void afterQuery() { if(PageHelper.getLocalPage() ! null) { log.warn(分页参数未清理: {}, Thread.currentThread().getName()); PageHelper.clearPage(); } } }6. 扩展思考分页设计的演进6.1 物理分页 vs 逻辑分页物理分页(如PageHelper)优点性能好数据库压力小缺点实现复杂有线程安全问题逻辑分页(内存分页)优点实现简单无线程安全问题缺点数据量大时性能差6.2 新一代分页方案MyBatis-Plus的分页采用更安全的ThreadLocal设计支持多种数据库方言提供IPage接口规范分页结果PageUser page new Page(1, 10); userMapper.selectPage(page, queryWrapper);Spring Data的Pageable与Spring生态深度集成支持Reactive编程模型统一的接口规范PageUser findAll(Pageable pageable);7. 经验总结与避坑指南在实际项目中使用PageHelper时我总结了以下血泪教训线程池环境要特别注意不只是Tomcat任何线程池场景都可能出问题包括异步任务、定时任务、消息队列消费者等测试很难覆盖开发环境线程复用率低问题不易暴露必须进行高并发测试才能发现问题框架整合时要小心某些框架会包装或复用线程比如Hystrix的线程隔离、Feign的调用等监控是关键添加ThreadLocal泄漏检测监控异常分页情况升级注意事项新版PageHelper有改进但不完全解决问题升级后仍需遵循最佳实践这个案例告诉我们任何便捷的工具都有其适用边界。作为开发者不仅要会用工具更要理解其实现原理和潜在风险。特别是在并发环境下线程安全问题往往最容易被忽视却可能造成最严重的生产事故。
1. 问题现象偶现的菜单数据丢失那天早上客服反馈了一个奇怪的问题新开通租户的用户在系统中只能看到部分菜单而实际上套餐对应的功能菜单应该有100多个。经过排查发现系统初始化时只插入了50个菜单记录。更诡异的是测试环境复现时一切正常菜单数据完整同步。这个问题只在生产环境偶现而且每次丢失的数据量都精准地卡在50条。作为开发人员我立刻意识到这个数字很眼熟——这不正是我们系统中分页插件的默认每页记录数吗2. PageHelper分页机制解析2.1 PageHelper的基本工作原理PageHelper是MyBatis的一个分页插件它的核心实现原理是通过拦截器机制。具体来说当调用PageHelper.startPage()方法时会在当前线程的ThreadLocal中设置分页参数后续执行的SQL语句会被PageInterceptor拦截拦截器检查ThreadLocal中是否存在分页参数如果存在就会在原始SQL后自动拼接LIMIT子句实现分页这种设计的好处是开发者无需在每个DAO方法中重复编写分页逻辑只需在Service层调用startPage()后续的查询就会自动分页。2.2 ThreadLocal的使用与风险PageHelper使用ThreadLocal来存储分页参数这种设计带来了便利但也埋下了隐患protected static final ThreadLocalPage LOCAL_PAGE new ThreadLocalPage(); public static E PageE startPage(int pageNum, int pageSize) { PageE page new PageE(pageNum, pageSize); setLocalPage(page); return page; } protected static void setLocalPage(Page page) { LOCAL_PAGE.set(page); }ThreadLocal的特性是线程隔离的这意味着每个线程有自己的分页参数副本参数在线程生命周期内持续有效如果不清除参数会被后续操作继承3. 问题根因分析3.1 异常分页的场景还原在我们的案例中问题代码是这样的PostMapping(/findListByMenuIds) public ResultVOListMenuFunVO findListByMenuIds(RequestBody ListString menuIds){ ListMenuFunVO menuFunList this.menuFunService.findListByMenuIds(menuIds); return RV.success(menuFunList); }表面看这只是一个普通的查询没有分页逻辑。但问题出在框架的基类中protected T PageT startPage(){ int pageNumInt CharacterUtils.parseInt(request.getParameter(pageNum),1); int pageSizeInt CharacterUtils.parseInt(request.getParameter(pageSize),50); return PageHelper.startPage(pageNumInt, pageSizeInt); }某些情况下这个startPage()方法被意外调用了但没有紧跟MyBatis查询导致分页参数被设置到ThreadLocal中没有执行SQL查询所以拦截器的清理逻辑未触发线程回到线程池时仍带着分页参数当下一个请求复用这个线程时非分页查询也被强制分页3.2 为什么问题偶现这个问题不是每次都会出现原因在于Tomcat等容器使用线程池处理请求只有复用了被污染的线程时才会出现问题在低并发时线程复用率低问题不易出现高并发时线程频繁复用问题出现概率增大4. PageHelper源码深度解析4.1 拦截器核心逻辑PageInterceptor是PageHelper的核心其intercept方法主要流程public Object intercept(Invocation invocation) throws Throwable { try { // 获取分页参数 Page page getLocalPage(); if(page ! null) { // 执行分页逻辑 resultList ExecutorUtil.pageQuery(...); } else { // 普通查询 resultList executor.query(...); } return resultList; } finally { clearPage(); // 清理ThreadLocal } }关键点在于只有在正常执行到finally块时才会清理ThreadLocal。4.2 典型的问题场景以下情况会导致ThreadLocal未被清理远程调用分页Page page startPage(); // 设置了分页参数 remoteService.query(data); // 实际是HTTP调用不走MyBatis拦截器 // ThreadLocal未被清除MongoDB等非MyBatis查询Page page startPage(); // 设置了分页参数 mongoTemplate.find(query, Entity.class); // 不走MyBatis // ThreadLocal未被清除异常提前退出Page page startPage(); if(someCheck) throw new Exception(); // 抛出异常 mapper.selectList(); // 未执行 // ThreadLocal未被清除5. 解决方案与最佳实践5.1 立即修复方案对于已经出现的问题可以采取以下临时解决方案手动清除ThreadLocalPostMapping(/findListByMenuIds) public ResultVOListMenuFunVO findListByMenuIds(RequestBody ListString menuIds){ PageHelper.clearPage(); // 手动清除 ListMenuFunVO menuFunList this.menuFunService.findListByMenuIds(menuIds); return RV.success(menuFunList); }禁用自动分页Bean public PageInterceptor pageInterceptor() { PageInterceptor interceptor new PageInterceptor(); Properties properties new Properties(); properties.setProperty(autoRuntimeDialect, false); interceptor.setProperties(properties); return interceptor; }5.2 长期最佳实践严格遵循使用规范startPage()后必须紧跟MyBatis查询不要将startPage()放在基类或AOP中非MyBatis查询使用显式分页参数改造远程调用分页// 改造前 Page page startPage(); remoteService.query(data); // 改造后 PageParam param new PageParam(); param.setPageNum(1); param.setPageSize(50); remoteService.query(data, param);添加监控告警Aspect Component public class PageHelperMonitorAspect { AfterReturning(execution(* com..mapper.*.*(..))) public void afterQuery() { if(PageHelper.getLocalPage() ! null) { log.warn(分页参数未清理: {}, Thread.currentThread().getName()); PageHelper.clearPage(); } } }6. 扩展思考分页设计的演进6.1 物理分页 vs 逻辑分页物理分页(如PageHelper)优点性能好数据库压力小缺点实现复杂有线程安全问题逻辑分页(内存分页)优点实现简单无线程安全问题缺点数据量大时性能差6.2 新一代分页方案MyBatis-Plus的分页采用更安全的ThreadLocal设计支持多种数据库方言提供IPage接口规范分页结果PageUser page new Page(1, 10); userMapper.selectPage(page, queryWrapper);Spring Data的Pageable与Spring生态深度集成支持Reactive编程模型统一的接口规范PageUser findAll(Pageable pageable);7. 经验总结与避坑指南在实际项目中使用PageHelper时我总结了以下血泪教训线程池环境要特别注意不只是Tomcat任何线程池场景都可能出问题包括异步任务、定时任务、消息队列消费者等测试很难覆盖开发环境线程复用率低问题不易暴露必须进行高并发测试才能发现问题框架整合时要小心某些框架会包装或复用线程比如Hystrix的线程隔离、Feign的调用等监控是关键添加ThreadLocal泄漏检测监控异常分页情况升级注意事项新版PageHelper有改进但不完全解决问题升级后仍需遵循最佳实践这个案例告诉我们任何便捷的工具都有其适用边界。作为开发者不仅要会用工具更要理解其实现原理和潜在风险。特别是在并发环境下线程安全问题往往最容易被忽视却可能造成最严重的生产事故。
