SpringMVC多線程下無法獲取請求的原因和解決方法
前言
眾所周知,在SpringMVC
中如果我們期待獲取當(dāng)前請求的HttpServletRequest
對象,通常有如下幾種方式:
- 通過方法參數(shù)注入:在
Controller
的方法中,可以直接聲明HttpServletRequest
類型的參數(shù),Spring MVC
會自動將當(dāng)前請求的HttpServletRequest
對象注入進來。例如:
@Controller public class MyController { @RequestMapping("/example") public String handleRequest(HttpServletRequest request) { // 使用request對象 return "example"; } }
- 通過
RequestContextHolder
:Spring MVC
提供了一個RequestContextHolder
類,例如:
HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();
而本次我們重點分析當(dāng)使用RequestContextHolder
在多線程環(huán)境下獲取請求所可能導(dǎo)致的一些問題。
(注:在獲取當(dāng)前請求的HttpServletRequest
我們會利用RequestContextHolder
先獲取到ServletRequestAttributes
后,再通過ServletRequestAttributes
來獲取對應(yīng)的httpServletRequest
對象)
問題復(fù)現(xiàn)
為了直觀的理解RequestContextHolder
在多線程使用下所導(dǎo)致的問題,我們先來通過一個業(yè)務(wù)中的真實場景來進行分析。
在國際化功能開發(fā)中,我們通常會將用戶當(dāng)前的語言信息存放在Request
請求中,這樣后端通過獲取請求頭的中的語言信息就能成功獲取到用戶所支持的語言。
進一步,對于一些涉及到國際化的導(dǎo)入,導(dǎo)出的耗時操作來說,我們通常會將其放在異步線程中進行執(zhí)行,以提升程序性能。代碼邏輯大致如下:
@GetMapping("/missing-request-header") public String getMissingRequestHeader() { // 主線程獲取請求頭信息 String mainThreadLanguages = ServletUtils.getLanguagesExistProblem(); log.info("主線程獲取請求頭信息:{}", mainThreadLanguages); new Thread(() -> { // 子線程獲取請求頭信息 模擬執(zhí)行耗時操作 String subThreadLanguages = ServletUtils.getLanguagesExistProblem(); log.info("子線程獲取請求頭信息:{}", subThreadLanguages); }).start(); return "success"; }
上述程序的邏輯相對來說比較簡單,唯一可能讓你困惑的可能在于ServletUtils.getLanguagesExistProblem()
方法的調(diào)用。
該方法是筆者
所寫的一個工具類,其主要作用就是獲取當(dāng)前請求頭中的Lang
屬性,方法內(nèi)部具體邏輯如下所示:
/** * 獲取客戶端請求頭中的語言信息。 * 其會從當(dāng)前的HTTP請求中提取客戶端所設(shè)置的語言信息。 * 主要通過讀取請求頭中的"X_CLIENT_LANG"字段來獲取客戶端語言偏好。 * * @return String 客戶端請求頭中指定的語言信息。 * 如果不存在該字段則返回默認的zh-cn。 */ public static String getLanguagesExistProblem() { HttpServletRequest request = getRequest(); Assert.notNull(request); String lang = request.getHeader(X_CLIENT_LANG); if (StrUtil.isNotBlank(lang)) { return lang; } return "zh-cn"; }
可以看到,在getLanguagesExistProblem
方法內(nèi)部又會通過getRequest
獲取到當(dāng)前請求的HttpServletRequest
信息,而getRequest
內(nèi)部邏輯如下所示:
public static HttpServletRequest getRequest() { HttpServletRequest httpServletRequest = null; try { RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes(); if (requestAttributes instanceof ServletRequestAttributes) { ServletRequestAttributes servletRequestAttributes = (ServletRequestAttributes) requestAttributes; httpServletRequest = servletRequestAttributes.getRequest(); } } catch (Exception e) { // 記錄異常,但不向外拋出,以避免可能的業(yè)務(wù)邏輯中斷 log.error("獲取HttpServletRequest時發(fā)生異常:", e); } // 返回獲取到的請求對象,如果失敗則返回null return httpServletRequest; }
整體來看上述代碼調(diào)用邏輯如下:
至此,相信你對于示例代碼的邏輯其實已經(jīng)清楚了。其無非就是會首先會在主線程中獲取當(dāng)前請求頭中的語言信息,接著,又會新建一個子線程嘗試去獲取到請求頭中的語言信息??雌饋硭坪醮a似乎沒什么問題,嘗試執(zhí)行代碼,你會發(fā)現(xiàn)有如下提示:
追蹤溯源
通過錯誤提示不難發(fā)現(xiàn)是子線程在調(diào)用getLanguagesExistProblem()
方法時所提示的錯誤。具體來看,是因為其內(nèi)部Assert.notNull(request);
斷言所提示的錯誤,而導(dǎo)致問題發(fā)生的原因是因為傳入的request
對象為null
,進而導(dǎo)致不滿足斷言條件notNull
從而提示異常信息。
正如我們前面所說,我們的request
對象是通過RequestContextHolder
來獲取的。具體我們的代碼來看,其本質(zhì)是通過ServletRequestAttributes
的getRequest
來完成這一操作。那為什么會在多線程情況下有這樣的問題呢?初看這一問題你可能會有點摸不到頭腦,不知該如何下手。沒有思路也別慌,接下來,不妨聽一聽筆者是如何對這一問題進行分析的。
首先,既然RequestContextHolder
可以實現(xiàn)獲取當(dāng)前請求的功能,其一定會把請求進行一層緩存
,以確保我們無論在程序的任何位置都能獲取到請求,順著這一思路,如果要你來實現(xiàn)這一需求,你會如何設(shè)計呢?
我想你大概率會將此處的邏輯設(shè)計在程序公共的入口位置,那SpringMVC
中請求第一次進入時公共的會首先在哪處理呢?顯示是Servlet
中的service
方法。具體到DispatcherServlet
來看,其內(nèi)部邏輯如下所示:
@Override protected void service(HttpServletRequest request, HttpServletResponse response) { // ... 省略其他無關(guān)代碼 // 處理請求核心代碼,點擊該方法進入 processRequest(request, response); }
(Ps: 這里需要讀者有一點Servlet
相關(guān)知識,簡單來看,所有請求進入Servlet
后都會先通過Service
方法的處理~~~)
不難發(fā)現(xiàn),service
方法其內(nèi)部的核心邏輯會委托processRequest
進行處理,而processRequest
其內(nèi)部邏輯如下:
protected final void processRequest(HttpServletRequest request, // ... 省略其他無關(guān)邏輯 // 初始化ContextHolders, 便于訪問上下文信息 initContextHolders(request, localeContext, requestAttributes); doService(request, response); }
通過initContextHolders
方法的名稱我們不難猜出,其大概的作用微在于初始化一個ContextHolder
相關(guān)屬性。事實上,在該方法內(nèi)其會將 requestAttributes
與當(dāng)前線程進行綁定。具體邏輯如下:
private void initContextHolders(HttpServletRequest request, @Nullable LocaleContext localeContext, @Nullable RequestAttributes requestAttributes) { // 將參數(shù)localeContext設(shè)置為當(dāng)前線程的LocaleContext,并設(shè)置參數(shù)threadContextInheritable為true,表示上下文對象可以在子線程中繼承 if (localeContext != null) { LocaleContextHolder.setLocaleContext(localeContext, this.threadContextInheritable); } // 將參數(shù)requestAttributes設(shè)置為當(dāng)前線程的RequestAttributes,并設(shè)置參數(shù)threadContextInheritable為true,表示上下文對象可以在子線程中繼承 if (requestAttributes != null) { RequestContextHolder.setRequestAttributes(requestAttributes, this.threadContextInheritable); } }
(Ps:RequestAttributes
是Spring
框架中的一個接口,用于表示一個請求的屬性集合。它允許應(yīng)用程序在線程中存儲和訪問請求的屬性,這些屬性可以用于在請求的不同階段共享數(shù)據(jù)或傳遞數(shù)據(jù)。)
而在RequestContextHolder
內(nèi)部的setRequestAttributes
方法中,其會根據(jù)inheritable
屬性的不同來將request
屬性選擇性的放入requestAttributesHolder
和inheritableRequestAttributesHolder
兩個不同的ThreadLocal
。
而兩者的區(qū)別在于子線程是否可以共享父線程屬性。而默認情況下inheritable
的取值為false
,也就是說在SpringMVC
默認情況下requestAttributes
是不會線程共享的。
(Ps:此處的RequestAttributes
是我們之前提及ServletRequestAttributes
的父接口)
進一步,setRequestAttributes
的內(nèi)部邏輯如下:
public static void setRequestAttributes(@Nullable RequestAttributes attributes, boolean inheritable) { if (attributes == null) { resetRequestAttributes(); } else { if (inheritable) { inheritableRequestAttributesHolder.set(attributes); requestAttributesHolder.remove(); } else { requestAttributesHolder.set(attributes); inheritableRequestAttributesHolder.remove(); } } }
總結(jié)
回到我們之前的問題,我們以多線程下無法從從請求頭中獲取相關(guān)屬性為入口,逐步深入剖析了其在多線程情況下無法失效的原因。具體來看,在SpringMVC
中,如果我們想獲取當(dāng)前請求的Request
對象,通常我們會通過RequestContextHolder
進行獲取。進一步RequestContextHolder
獲取Request
對象需要先獲取ServletRequestAttributes
對象,進而通過其getRequest
方法來獲取到當(dāng)前的請求信息。
換言之,如果想獲取當(dāng)前請求的Request
對象,我們首先需要確保能獲取到ServletRequestAttributes
這一中間信息,因為其內(nèi)部會維護相關(guān)的請求對象。而在SpringMVC
內(nèi)部ServletRequestAttributes
在保存在RequestContextHolder
中的ThreadLocal
。
而默認情況下,其實不支持父子線程間傳遞的,所以在多線程環(huán)境下當(dāng)我們通過RequestContextHolder
獲取請求時會出現(xiàn)請求無法獲取的現(xiàn)象,而導(dǎo)致這一問題本質(zhì)發(fā)生的本質(zhì)原因在于ServletRequestAttributes
并未實現(xiàn)父子線程間的共享!
以上就是SpringMVC多線程下無法獲取請求的原因和解決方法的詳細內(nèi)容,更多關(guān)于SpringMVC無法獲取請求的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
SpringBoot利用jpa連接MySQL數(shù)據(jù)庫的方法
這篇文章主要介紹了SpringBoot利用jpa連接MySQL數(shù)據(jù)庫的方法,本文通過示例代碼給大家介紹的非常詳細,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-10-10SpringMVC實現(xiàn)注解式權(quán)限驗證的實例
本篇文章主要介紹了SpringMVC實現(xiàn)注解式權(quán)限驗證的實例,可以使用Spring MVC中的action攔截器來實現(xiàn),具有一定的參考價值,有興趣的可以了解下。2017-02-02Spring?Security內(nèi)置過濾器的維護方法
這篇文章主要介紹了Spring?Security的內(nèi)置過濾器是如何維護的,本文給我們分析一下HttpSecurity維護過濾器的幾個方法,需要的朋友可以參考下2022-02-02StackTraceElement獲取方法調(diào)用棧信息實例詳解
這篇文章主要介紹了StackTraceElement獲取方法調(diào)用棧信息實例詳解,分享了相關(guān)代碼示例,小編覺得還是挺不錯的,具有一定借鑒價值,需要的朋友可以參考下2018-02-02SpringCloud?Eureka服務(wù)治理之服務(wù)注冊服務(wù)發(fā)現(xiàn)
這篇文章主要介紹了SpringCloud?Eureka服務(wù)治理服務(wù)注冊和服務(wù)發(fā)現(xiàn)概念詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-08-08SpringBoot2實現(xiàn)MessageQueue消息隊列
本文主要介紹了 SpringBoot2實現(xiàn)MessageQueue消息隊列,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-04-04IntelliJ IDEA優(yōu)化配置的實現(xiàn)
這篇文章主要介紹了IntelliJ IDEA優(yōu)化配置的實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-07-07