遇到一個(gè)奇怪的問題，測試環(huán)境沒有出現(xiàn)，本地連正式數(shù)據(jù)庫也沒復(fù)現(xiàn)。

主要業(yè)務(wù)邏輯是通過篩選條件從數(shù)據(jù)庫導(dǎo)出一批數(shù)據(jù)。異常情況是，選擇的篩選條件失效了，導(dǎo)致導(dǎo)出了全量數(shù)據(jù)，這搞不好會(huì)有數(shù)據(jù)泄露風(fēng)險(xiǎn)。

已知列表分頁查詢是沒有問題的，篩選條件都能生效，代碼如下：

但是導(dǎo)出時(shí)卻沒起作用，導(dǎo)出代碼：

觀察可知，他們都調(diào)用的getSqlMap方法，該方法具體作用就是從HttpServletRequest中獲取相關(guān)條件參數(shù)，并放到Map中，供后續(xù)查詢代碼使用，如下：

按常理推斷，輸入和代碼一致，得到的結(jié)果應(yīng)該是一致的，但是卻不是這樣

使用jvm神器arthas，watch一下getSqlMap方法，然后分別調(diào)用列表查詢和導(dǎo)出接口，得到如下兩條記錄

對比可知，上面有的很多參數(shù)，下面一條都沒有，那么參數(shù)怎么會(huì)消失呢？數(shù)據(jù)都是從HttpServletRequest對象中獲取的，那么這個(gè)對象里面的數(shù)據(jù)怎么消失了呢？

細(xì)心的網(wǎng)友可能注意到了，我們導(dǎo)出方式是異步的，關(guān)鍵在@Async注解

難道莫非，HttpServletRequest被回收了，果然網(wǎng)上搜一下，很多案例

比較官方的說明，不推薦在異步中使用request，會(huì)得到不確定的結(jié)果

因此，我們需要在異步方法前提取參數(shù)，再傳入

小小的問題，大大的疑惑。花了不少時(shí)間定位問題，好在爬出了坑。