欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

關于Spring MVC在Controller層中注入request的坑詳解

 更新時間:2018年04月10日 09:56:36   作者:sluggarddd  
這篇文章主要給大家介紹了關于Spring MVC在Controller層中注入request的坑的相關資料,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧。

前言

記一次為了節(jié)省代碼沒有在方法體中聲明HttpServletRequest,而用autowire直接注入所鉆的坑

結論:給心急的人。 直接在Controller的成員變量上使用@Autowire聲明HttpServletRequest,這是線程安全的!

@Controller
public class TestController{
 @Autowire
 HttpServletRequest request;
 @RequestMapping("/")
 public void test(){
  request.getAttribute("uid"); 
 }
}

結論如上。

背景

是這樣的,由于項目中我在Request的頭部加入身份驗證信息,而我在攔截器截獲信息并且驗證通過后,會將當前用戶的身份加到request的Attribute中,方便在Controller層拿出來復用。

疑問:為什么不直接在Controller上使用@RequestHeader取出來呢? 因為header里面是加密后的數(shù)據(jù),且要經(jīng)過一些復雜的身份驗證判斷,所以直接將這一步直接丟在了攔截器執(zhí)行。

所以當解密后,我將用戶信息(如uid)用request.setAttribute()設入request中在Controller提取。

而如果需要使用request,一般需要在方法上聲明,如:

public Result save(HttpServletRequest request){
 // dosomething();
}

那么我每個方法都要用到uid的豈不是每個方法都要聲明一個request參數(shù),為了節(jié)省著個冗余步驟。我寫了一個基類。

public class CommonController{
 @Autowire
 HttpServletReqeust request;
 public String getUid(){
  return (String)request.getAttribute("uid");
 }
}

后來我就擔心,因為controller是單例的,這么寫會不會導致后面的reqeust覆蓋前面的request,在并發(fā)條件下有線程安全問題。 于是我就到segmentFault上提問,大部分網(wǎng)友說到,確實有線程問題!segmentFault問題地址 ###驗證過程 因為網(wǎng)友大部分的觀點是只能在方法上聲明,我自然不想就此放棄多寫那么多代碼,于是開始我的驗證過程。 熱心的程序員們給我提供了好幾種解決方案,我既然花力氣證明了,就把結果放在這里,分享給大家。

方法1

第一個方法就是在controller的方法中顯示聲明HttpServletReqeust,代碼如下:

@RequestMapping("/test")
@RestController
public class CTest {
 Logger logger = LoggerFactory.getLogger(getClass());
 @RequestMapping("/iiii")
 public String test(HttpServletRequest request) {
  logger.info(request.hashCode() + "");
  return null;
 }
}

在瀏覽器狂按F5

輸出

當時我是懵逼的,**說好的線程安全呢!**這特么不是同一個request嗎!特么的在逗我! 為此我還找了很久request是不是重寫了hashcode()!

啊,事實是這樣的,因為我用瀏覽器狂按F5,再怎么按他也是模擬不了并發(fā)的。那么就相當于,服務器一直在用同一個線程處理我的請求就足夠了,至于這個request的hashcode,按照jdk的說法是根據(jù)obj在jvm的虛擬地址計算的,后面的事情是我猜的,如果有知道真正真想的還望告知!

猜測

服務器中每個thread所申請的request的內(nèi)存空間在這個服務器啟動的時候就是固定的,那么我每次請求,他都會在他所申請到的內(nèi)存空間(可能是類似數(shù)組這樣的結構)中新建一個request,(類似于數(shù)組的起點總是同一個內(nèi)存地址),那么我發(fā)起一個請求,他就會在起始位置新建一個Request傳遞給Servlet并開始處理,處理結束后就會銷毀,那么他下一個請求所新建的Request,因為之前的request銷毀了,所以又從起始地址開始創(chuàng)建,這樣一切就解釋得通了!

猜測完畢

驗證猜想:

我不讓他有銷毀的時間不就可以了嗎 測試代碼

@RequestMapping("/test")
@RestController
public class CTest {
 Logger logger = LoggerFactory.getLogger(getClass());
 @RequestMapping("/oooo")
 public String testA(HttpServletRequest request) throws Exception {
  Thread.sleep(3000);
  logger.info(request.hashCode() + "");
  logger.info(reqeust.getHeader("uid");
  return null;
 }
 @RequestMapping("/iiii")
 public String test(HttpServletRequest request) {
  logger.info(request.hashCode() + "");
  logger.info(reqeust.getHeader("uid");
  return null;
 }
}

如上,我在接口/oooo中休眠3秒,如果他是共用一個reqeust的話,那么后面的請求將覆蓋這個休眠中的reqeust,所傳入的uid即為接口地址。先發(fā)起/oooo后發(fā)起/iiii

輸出

controller.CTest:33 - 364716268
controller.CTest:34 - iiii
controller.CTest:26 - 1892130707
controller.CTest:27 - oooo

結論: 1、后發(fā)起的/iiii沒有覆蓋前面/oooo的數(shù)據(jù),沒有線程安全問題。 2、request的hashcode不一樣,因為/oooo的阻塞,導致另一個線程需要去處理,所以他新建了request,而不是向之前一樣全部hashcode相同。

二輪驗證

public class HttpTest {
 public static void main(String[] args) throws Exception {
  for (int i = 300; i > 0; i--) {
   final int finalI = i;
   new Thread() {
    @Override
    public void run() {
     System.out.println("v###" + finalI);
     HttpRequest.get("http://localhost:8080/test/iiii?").header("uid", "v###" + finalI).send();
    }
   }.start();
  }
 }
}

在模擬并發(fā)條件下,header中的uid300個完全接受,沒有覆蓋

所以這種方式,沒有線程安全問題。

方法2

在CommonController中,使用@ModelAttribute處理。

public class CommonController {

// @Autowired
 protected HttpServletRequest request;
 @ModelAttribute
 public void bindreq(HttpServletRequest request) {
  this.request = request;
 }
 protected String getUid() {
  System.out.println(request.toString());
  return request.getAttribute("uid") == null ? null : (String) request.getAttribute("uid");
 }
}

這樣子是有線程安全問題的!后面的request有可能覆蓋掉之前的!

驗證代碼

@RestController
@RequestMapping("/test")
public class CTest extends CommonController {
 Logger logger = LoggerFactory.getLogger(getClass());
 @RequestMapping("/iiii")
 public String test() {
  logger.info(request.getHeader("uid"));
  return null;
 }
}
public class HttpTest {
 public static void main(String[] args) throws Exception {
  for (int i = 100; i > 0; i--) {
   final int finalI = i;
   new Thread() {
    @Override
    public void run() {
     System.out.println("v###" + finalI);
     HttpRequest.get("http://localhost:8080/test/iiii").header("uid", "v###" + finalI).send();
    }
   }.start();
  }
 }
}

截取了部分輸出結果

controller.CTest:26 - v###52
controller.CTest:26 - v###13
controller.CTest:26 - v###57
controller.CTest:26 - v###57
controller.CTest:26 - v###21
controller.CTest:26 - v###10
controller.CTest:26 - v###82
controller.CTest:26 - v###82
controller.CTest:26 - v###93
controller.CTest:26 - v###71
controller.CTest:26 - v###71
controller.CTest:26 - v###85
controller.CTest:26 - v###85
controller.CTest:26 - v###14
controller.CTest:26 - v###47
controller.CTest:26 - v###47
controller.CTest:26 - v###69
controller.CTest:26 - v###22
controller.CTest:26 - v###55
controller.CTest:26 - v###61

可以看到57、71、85、47被覆蓋了,丟失了部分request!

這么做是線程不安全的!

方法3

使用CommonController作為基類,將request Autowire。

public class CommonController {
 @Autowired
 protected HttpServletRequest request;
 protected String getUid() {
  System.out.println(request.toString());
  return request.getAttribute("uid") == null ? null : (String) request.getAttribute("uid");
 }
}

測試接口同上,結果喜人! 100個request沒有任何覆蓋,我加大范圍測了五六次,上千次請求沒一個覆蓋,可以證明這種寫法沒有線程安全問題了!

另外還有一點有趣的是,無論使用多少并發(fā),request的hashcode始終是相同的,而且,測試同一個Controller中不同的接口,他也相同,使用sleep強行阻塞,hashcode也是相同。但是訪問不同的controller,hashcode卻是不同的,具體里面如何實現(xiàn)我也就沒有繼續(xù)深挖了。

但是結論是出來的,就如文章最開始所說一樣。

總結

以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。

相關文章

  • 淺析SpringBoot統(tǒng)一返回結果的實現(xiàn)

    淺析SpringBoot統(tǒng)一返回結果的實現(xiàn)

    前后端開發(fā)過程中數(shù)據(jù)交互規(guī)范化是一件非常重要的事情,不僅可以減少前后端交互過程中出現(xiàn)的問題,也讓代碼邏輯更加具有條理,下面小編就和大家講講SpringBoot如何統(tǒng)一返回結果的吧
    2023-07-07
  • ToStringBuilder類的一些心得

    ToStringBuilder類的一些心得

    ToStringBuilder類的一些心得,需要的朋友可以參考一下
    2013-02-02
  • java實現(xiàn)波雷費密碼算法示例代碼

    java實現(xiàn)波雷費密碼算法示例代碼

    這篇文章主要介紹了java實現(xiàn)波雷費密碼算法示例代碼,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2020-01-01
  • Spring?Bean中的六種作用域你了解嗎

    Spring?Bean中的六種作用域你了解嗎

    Bean的作用域是指Bean實例的生命周期及可見性范圍,Spring框架定義了6種作用域,本文就來和大家聊聊這6種作用域的定義與使用,希望對大家有所幫助
    2023-09-09
  • Java經(jīng)典設計模式之模板方法模式定義與用法示例

    Java經(jīng)典設計模式之模板方法模式定義與用法示例

    這篇文章主要介紹了Java經(jīng)典設計模式之模板方法模式,簡單說明了模板方法模式的原理、定義,并結合實例形式分析了java模板方法模式的具體使用方法,需要的朋友可以參考下
    2017-08-08
  • java導出Excel通用方法實例

    java導出Excel通用方法實例

    這篇文章主要介紹了java導出Excel方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2019-05-05
  • Java實現(xiàn)推箱子游戲

    Java實現(xiàn)推箱子游戲

    這篇文章主要為大家詳細介紹了Java實現(xiàn)推箱子游戲,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2020-05-05
  • Mybatis基于MapperScan注解的動態(tài)代理加載機制詳解

    Mybatis基于MapperScan注解的動態(tài)代理加載機制詳解

    這篇文章主要介紹了Mybatis基于MapperScan注解的動態(tài)代理加載機制,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習吧
    2023-01-01
  • Spring容器的創(chuàng)建過程之如何注冊BeanPostProcessor詳解

    Spring容器的創(chuàng)建過程之如何注冊BeanPostProcessor詳解

    關于BeanPostProcessor 各位一定不陌生,今天整理的這篇文章總結了如何注冊BeanPostProcessor,文中有非常詳細的圖文示例,需要的朋友可以參考下
    2021-06-06
  • 6種Java創(chuàng)建對象的方式總結

    6種Java創(chuàng)建對象的方式總結

    在Java中,創(chuàng)建對象可以使用多種方式,本文將詳細介紹以下六種創(chuàng)建對象的方式,文中的示例代碼講解詳細,感興趣的小伙伴可以跟隨小編一起了解一下
    2023-04-04

最新評論