多年以後，PageHelper 又深深給我上了一課！

2024-03-05碼農

大家好，我是鵬磊！

多年不用PageHelper了，最近新入職的公司，采用了此工具整合的框架，作為一個獨立緊急計畫開發的基礎。計畫開發起來，還是手到擒來的，但是沒想到，最終測試的時候，深深的給我上了一課。

我的計畫發生了哪些奇葩現象?

一切的問題都要從我接受的計畫開始說起, 在開發這個計畫的過程中,發生了各種奇葩的事情, 下面我簡單說給你們聽聽:

帳號重復註冊?

你肯定在想這是什麽意思? 就是字面意思,已經註冊的帳號,可以再次註冊成功!!!

elseif (UserConstants.NOT_UNIQUE.equals(userService.checkUserNameUnique(username)) ||"匿名使用者".equals(username)){ // 註冊使用者已存在 msg = "註冊使用者'" + username + "'失敗"; }

如上所示: checkUserNameUnique(username) 用來驗證資料庫是否存在使用者名稱:

<selectid="checkUserNameUnique"parameterType="String"resultType="int"> select count(1) from sys_user where user_name = #{userName} limit 1 </select>

正常來說,是不會有問題的,那麽原因我們後面講,接著看下一個問題。

查詢全部份類的下拉選單只能查出5條數據？

如上所示,明明有十多個結果,怎麽只能返回5個?我也沒有添加分頁參數啊？

相信用過PageHelper的同學已經知道問題出在哪裏了。

修改使用者密碼報錯?

當管理員在後台界面重設使用者的密碼的時候，居然報錯了？

報錯資訊清晰的告訴了我：sql語句異常,update語句不認識「Limit 5」

到此為止，報錯資訊已經告訴了我，我的sql被拼接了該死的「limit」分頁參數。

小結

上面提到的幾個只是冰山一角，在我使用的過程中，還有各種涉及到sql的地方，會因為這個分頁參數導致的問題，我可以分為兩種：

1）直接導致報錯的：明確報錯原因的

比如insert、update語句等，不支持limit，會直接報錯。

2）導致業務邏輯錯誤，但是程式碼沒有錯誤提示

如我上面提到的使用者可以重復註冊，卻沒有報錯，實際在程式碼當中是有報錯的，但是當前方法對異常進行了throw，最終被全域異常捕獲了。

不分頁的sql被拼接了limit，導致沒有報錯，但是數據返回量錯誤。

異常不是每次出現，是有一定紀律的，但是觸發機率較高，原因在後面會逐漸脫出。

PageHelper是怎麽做到上面的問題的？

PageHelper使用

我這裏只講解計畫基於的框架的使用方式。

程式碼如下：

@GetMapping("/cms/cmsEssayList") public TableDataInfo cmsEssayList(CmsBlog cmsBlog){ //狀態為釋出 cmsBlog.setStatus("1"); startPage(); List<CmsBlog> list = cmsBlogService.selectCmsBlogList(cmsBlog); return getDataTable(list); }

使用起來還是很簡單的，透過 startPage() 指定分頁參數，透過 getDataTable(list) 對結果數據封裝成分頁的格式。

有些同學會問，這也沒沒傳分頁參數啊，並且實體類當中也沒有，這就是比較有意思的點，下一小結就來聊聊源碼。

startPage()幹啥了？

protectedvoidstartPage(){ // 透過request去獲取前端傳遞的分頁參數，不需控制器要顯示接收 PageDomain pageDomain = TableSupport.buildPageRequest(); Integer pageNum = pageDomain.getPageNum(); Integer pageSize = pageDomain.getPageSize(); if (StringUtils.isNotNull(pageNum) && StringUtils.isNotNull(pageSize)) { String orderBy = SqlUtil.escapeOrderBySql(pageDomain.getOrderBy()); Boolean reasonable = pageDomain.getReasonable(); // 真正使用pageHelper進行分頁的位置 PageHelper.startPage(pageNum, pageSize, orderBy).setReasonable(reasonable); } }

PageHelper.startPage(pageNum, pageSize, orderBy).setReasonable(reasonable) 的參數分別是：

pageNum ：頁數

pageSize ：每頁數據量

orderBy ：排序

reasonable ：分頁合理化，對於不合理的分頁參數自動處理，比如傳遞pageNum是小於0，會預設設定為1.

繼續跟蹤，連續點選 startpage 構造方法到達如下位置：

/** * 開始分頁 * * @param pageNum 頁碼 * @param pageSize 每頁顯示數量 * @param count 是否進行count查詢 * @param reasonable 分頁合理化,null時用預設配置 * @param pageSizeZero true且pageSize=0時返回全部結果，false分時頁,null時用預設配置 */ publicstatic <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); // 1、獲取本地分頁 Page<E> oldPage = getLocalPage(); if (oldPage != null && oldPage.isOrderByOnly()) { page.setOrderBy(oldPage.getOrderBy()); } // 2、設定本地分頁 setLocalPage(page); return page; }

到達終點位置了，分別是： getLocalPage() 和 setLocalPage(page) ，分別來看下：

getLocalPage()

進入方法：

/** * 獲取 Page 參數 * * @return */ publicstatic <T> Page<T> getLocalPage(){ return LOCAL_PAGE.get(); }

看看常量 LOCAL_PAGE 是個什麽路數？

protectedstaticfinal ThreadLocal<Page> LOCAL_PAGE = new ThreadLocal<Page>();

好家夥，是ThreadLocal，學過java基礎的都知道吧，獨屬於每個執行緒的本地緩存物件。

當一個請求來的時候，會獲取持有當前請求的執行緒的ThreadLocal，呼叫 LOCAL_PAGE.get() ，檢視當前執行緒是否有未執行的分頁配置。

setLocalPage(page)

此方法顯而易見，設定執行緒的分頁配置：

protectedstaticvoidsetLocalPage(Page page){ LOCAL_PAGE.set(page); }

小結

經過前面的分析，我們發現，問題似乎就是這個ThreadLocal導致的。

是否在使用完之後沒有進行清理？導致下一次此執行緒再次處理請求時，還在使用之前的配置？

我們帶著疑問，看看mybatis時如何使用pageHelper的。

mybatis使用pageHelper分析

我們需要關註的就是mybatis在何時使用的這個ThreadLocal，也就是何時將分頁餐數獲取到的。

前面提到過，透過PageHelper的 startPage() 方法進行page緩存的設定，當程式執行sql介面mapper的方法時，就會被攔截器 PageInterceptor 攔截到。

PageHelper其實就是mybatis的分頁外掛程式，其實作原理就是透過攔截器的方式，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(); //對 boundSql 的攔截處理 if (dialect instanceof BoundSqlInterceptor.Chain) { boundSql = ((BoundSqlInterceptor.Chain) dialect).doBoundSql(BoundSqlInterceptor.Type.ORIGINAL, boundSql, cacheKey); } List resultList; //呼叫方法判斷是否需要進行分頁，如果不需要，直接返回結果 if (!dialect.skip(ms, parameter, rowBounds)) { //判斷是否需要進行 count 查詢 if (dialect.beforeCount(ms, parameter, rowBounds)) { //查詢總數 Long count = count(executor, ms, parameter, rowBounds, null, 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(); } } }

如上所示是intecept的全部程式碼，我們下面只關註幾個終點位置：

設定分頁：dialect.skip(ms, parameter, rowBounds)

此處的skip方法進行設定分頁參數，內部呼叫方法：

Page page = pageParams.getPage(parameterObject, rowBounds);

繼續跟蹤 getPage() ，發現此方法的第一行就獲取了ThreadLocal的值：

Page page = PageHelper.getLocalPage();

統計數量：dialect.beforeCount(ms, parameter, rowBounds)

我們都知道，分頁需要獲取記錄總數，所以，這個攔截器會在分頁前先進行count操作。

如果count為0，則直接返回，不進行分頁：

//處理查詢總數，返回 true 時繼續分頁查詢，false 時直接返回 if (!dialect.afterCount(count, parameter, rowBounds)) { //當查詢總數為 0 時，直接返回空的結果 return dialect.afterPage(new ArrayList(), parameter, rowBounds); }

afterPage其實是對分頁結果的封裝方法，即使不分頁，也會執行，只不過返回空列表。

分頁：ExecutorUtil.pageQuery

在處理完count方法後，就是真正的進行分頁了：

resultList = ExecutorUtil.pageQuery(dialect, executor, ms, parameter, rowBounds, resultHandler, boundSql, cacheKey);

此方法在執行分頁之前，會判斷是否執行分頁，依據就是前面我們透過ThreadLocal的獲取的page。

當然，不分頁的查詢，以及新增和更新不會走到這個方法當中。

非分頁：executor.query

而是會走到下面的這個分支：

resultList = executor.query(ms, parameter, rowBounds, resultHandler, cacheKey, boundSql);

我們可以思考一下，如果ThreadLoad在使用後沒有被清除，當執行非分頁的方法時，那麽就會將Limit拼接到sql後面。

為什麽不分也得也會拼接？我們回頭看下前面提到的 dialect.skip(ms, parameter, rowBounds) :

如上所示，只要page被獲取到了，那麽這個sql，就會走前面提到的 ExecutorUtil.pageQuery 分頁邏輯，最終導致出現不可預料的情況。

其實PageHelper對於分頁後的ThreaLocal是有清除處理的。

清除TheadLocal

在intercept方法的最後，會在sql方法執行完成後，清理page緩存：

finally { if(dialect != null){ dialect.afterAll(); } }

看看這個 afterAll() 方法:

@Override publicvoidafterAll(){ //這個方法即使不分頁也會被執行，所以要判斷 null AbstractHelperDialect delegate = autoDialect.getDelegate(); if (delegate != null) { delegate.afterAll(); autoDialect.clearDelegate(); } clearPage(); }