某天我正在工位上听着 Vicotry，愉快地敲着 hello world ，这感觉就像我写的代码能征服世界。突然运维给我打了一个电话，说我们某台服务器 OOM 了，要我过去看下，这感觉就像 xxx，你懂的。
去运维室、登录服务器、查看日志、....一顿操作猛如虎，看到一个 List 对象 600MB +（原谅我们服务器 low，运维比较小气，就给 1C2G 的服务器），检查当时的 SQL 语句，一看，我的乖乖，将近 4000w + 条数据。我的第一感觉就是，难道又是哪个业务在导出大批量数据？但是我们所有的 Excel 导出数据都做了校验，数据量大于 5w 条就后台分批次导出（所以有时候你要庆幸服务器 low，因为服务器 low，你就需要进行各种各样的优化，所有大数据量的操作都需要想办法优化，所以我们这个应用就有了各种有意思的骚操作，后面有机会分享下）。难道没有控制住？看了日志并没有发现大数据量的 Excel 导出，所以可以断定是分页的地方没有分页。看代码在一个 <code>if</code> 语句里面找到了坑，如下：
<code>isWitchFlag()</code> :
对 PageHelper 不是很熟悉的人一定不知道这个坑在哪里！在 PageHelper 使用文档（https://pagehelper.github.io/faq/）中第一句就阐述了：
只有紧跟在 PageHelper.startPage 方法后的第一个 Mybatis 的查询（Select）方法会被分页。。请注意关键词紧跟。为什么要紧跟呢？因为 PageHelper 的分页原理使用了 ThreadLocal，他的分页参数和线程是绑定在一起的，当我们执行 <code>PageHelper.startPage()</code> 语句时，他会将分页参数绑定到 ThreadLocal 中：
<code>setLocalPage()</code>：
在拦截器 <code>PageInterceptor</code> 中，最后的 finally 会将 Page 分页信息给 remove 掉：
所以，上面那段代码的分页信息被 if 语句中的 select 查询语句给消耗掉了，下面真正需要分页的语句当然就不会执行分页信息啦。怎么解决？两种方案：
治标不治本：将 <code>PageHelper.startPage()</code> 挪到 if 语句里面，让真正的查询语句紧挨着它。这种方案不治本的原因在于，如果又有小伙伴不知道这个坑，有可能又会踩。
治标治本：使用 Function Lamdba 表达式。
使用 Function Lamdba 来将 <code>PageHelper.startPage()</code> 与分页查询语句紧挨在一起，规避掉这个坑
首先我们需要定义一个 PageHelperTool，该 PageHelperTool 是封装了分页语句：
然后将分页的地方全部替换为 PageHelperTool 就可以了：
这样就可以彻底解决因误用 PageHelper 导致分页失效的问题了。
最后一句话：注意看文档啊！！！！！！
PS:如果你觉得文章对你有所帮助，别忘了推荐或者分享，因为有你的支持，才是我续写下篇的动力和源泉！
作者：chenssy。一个专注于【死磕 Java】系列创作的男人
出处：https://www.cnblogs.com/chenssy/p/15171314.html
作者个人网站：https://www.cmsblogs.com/。专注于 Java 优质系列文章分享，提供一站式 Java 学习资料
目前死磕系列包括：
1. 【死磕 Java 并发】：https://www.cmsblogs.com/category/1391296887813967872（已完成）
2.【死磕 Spring 之 IOC】：https://www.cmsblogs.com/category/1391374860344758272（已完成）
3.【死磕 Redis】：https://www.cmsblogs.com/category/1391389927996002304（已完成）
4.【死磕 Java 基础】：https://www.cmsblogs.com/category/1411518540095295488
5.【死磕 NIO】：https://www.cmsblogs.com/article/1435620402348036096
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。