热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

关于SpringMVC在Controller层中注入request的坑详解

前言记一次为了节省代码没有在方法体中声明HttpServletRequest,而用autowire直接注入所钻的坑结论:给心急的人。直接在Controller的成员变量上使用@

前言

记一次为了节省代码没有在方法体中声明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里面是加密后的数据,且要经过一些复杂的身份验证判断,所以直接将这一步直接丢在了拦截器执行。

所以当解密后,我将用户信息(如uid)用request.setAttribute()设入request中在Controller提取。

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

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

那么我每个方法都要用到uid的岂不是每个方法都要声明一个request参数,为了节省着个冗余步骤。我写了一个基类。

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

后来我就担心,因为controller是单例的,这么写会不会导致后面的reqeust覆盖前面的request,在并发条件下有线程安全问题。 于是我就到segmentFault上提问,大部分网友说到,确实有线程问题!segmentFault问题地址 ###验证过程 因为网友大部分的观点是只能在方法上声明,我自然不想就此放弃多写那么多代码,于是开始我的验证过程。 热心的程序员们给我提供了好几种解决方案,我既然花力气证明了,就把结果放在这里,分享给大家。

方法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

输出

关于Spring MVC在Controller层中注入request的坑详解

当时我是懵逼的,**说好的线程安全呢!**这特么不是同一个request吗!特么的在逗我! 为此我还找了很久request是不是重写了hashcode()!

啊,事实是这样的,因为我用浏览器狂按F5,再怎么按他也是模拟不了并发的。那么就相当于,服务器一直在用同一个线程处理我的请求就足够了,至于这个request的hashcode,按照jdk的说法是根据obj在jvm的虚拟地址计算的,后面的事情是我猜的,如果有知道真正真想的还望告知!

猜测

服务器中每个thread所申请的request的内存空间在这个服务器启动的时候就是固定的,那么我每次请求,他都会在他所申请到的内存空间(可能是类似数组这样的结构)中新建一个request,(类似于数组的起点总是同一个内存地址),那么我发起一个请求,他就会在起始位置新建一个Request传递给Servlet并开始处理,处理结束后就会销毁,那么他下一个请求所新建的Request,因为之前的request销毁了,所以又从起始地址开始创建,这样一切就解释得通了!

猜测完毕

验证猜想:

我不让他有销毁的时间不就可以了吗 测试代码

@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即为接口地址。先发起/oooo后发起/iiii

输出

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

结论: 1、后发起的/iiii没有覆盖前面/oooo的数据,没有线程安全问题。 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();
  }
 }
}

在模拟并发条件下,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没有任何覆盖,我加大范围测了五六次,上千次请求没一个覆盖,可以证明这种写法没有线程安全问题了!

另外还有一点有趣的是,无论使用多少并发,request的hashcode始终是相同的,而且,测试同一个Controller中不同的接口,他也相同,使用sleep强行阻塞,hashcode也是相同。但是访问不同的controller,hashcode却是不同的,具体里面如何实现我也就没有继续深挖了。

但是结论是出来的,就如文章最开始所说一样。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对编程笔记的支持。


推荐阅读
  • 模板引擎StringTemplate的使用方法和特点
    本文介绍了模板引擎StringTemplate的使用方法和特点,包括强制Model和View的分离、Lazy-Evaluation、Recursive enable等。同时,还介绍了StringTemplate语法中的属性和普通字符的使用方法,并提供了向模板填充属性的示例代码。 ... [详细]
  • Iamtryingtomakeaclassthatwillreadatextfileofnamesintoanarray,thenreturnthatarra ... [详细]
  • 本文介绍了Redis的基础数据结构string的应用场景,并以面试的形式进行问答讲解,帮助读者更好地理解和应用Redis。同时,描述了一位面试者的心理状态和面试官的行为。 ... [详细]
  • Java容器中的compareto方法排序原理解析
    本文从源码解析Java容器中的compareto方法的排序原理,讲解了在使用数组存储数据时的限制以及存储效率的问题。同时提到了Redis的五大数据结构和list、set等知识点,回忆了作者大学时代的Java学习经历。文章以作者做的思维导图作为目录,展示了整个讲解过程。 ... [详细]
  • 阿,里,云,物,联网,net,core,客户端,czgl,aliiotclient, ... [详细]
  • Spring特性实现接口多类的动态调用详解
    本文详细介绍了如何使用Spring特性实现接口多类的动态调用。通过对Spring IoC容器的基础类BeanFactory和ApplicationContext的介绍,以及getBeansOfType方法的应用,解决了在实际工作中遇到的接口及多个实现类的问题。同时,文章还提到了SPI使用的不便之处,并介绍了借助ApplicationContext实现需求的方法。阅读本文,你将了解到Spring特性的实现原理和实际应用方式。 ... [详细]
  • 1,关于死锁的理解死锁,我们可以简单的理解为是两个线程同时使用同一资源,两个线程又得不到相应的资源而造成永无相互等待的情况。 2,模拟死锁背景介绍:我们创建一个朋友 ... [详细]
  • 个人学习使用:谨慎参考1Client类importcom.thoughtworks.gauge.Step;importcom.thoughtworks.gauge.T ... [详细]
  • 前景:当UI一个查询条件为多项选择,或录入多个条件的时候,比如查询所有名称里面包含以下动态条件,需要模糊查询里面每一项时比如是这样一个数组条件:newstring[]{兴业银行, ... [详细]
  • JDK源码学习之HashTable(附带面试题)的学习笔记
    本文介绍了JDK源码学习之HashTable(附带面试题)的学习笔记,包括HashTable的定义、数据类型、与HashMap的关系和区别。文章提供了干货,并附带了其他相关主题的学习笔记。 ... [详细]
  • GreenDAO快速入门
    前言之前在自己做项目的时候,用到了GreenDAO数据库,其实对于数据库辅助工具库从OrmLite,到litePal再到GreenDAO,总是在不停的切换,但是没有真正去了解他们的 ... [详细]
  • 如何在php文件中添加图片?
    本文详细解答了如何在php文件中添加图片的问题,包括插入图片的代码、使用PHPword在载入模板中插入图片的方法,以及使用gd库生成不同类型的图像文件的示例。同时还介绍了如何生成一个正方形文件的步骤。希望对大家有所帮助。 ... [详细]
  • HashMap的相关问题及其底层数据结构和操作流程
    本文介绍了关于HashMap的相关问题,包括其底层数据结构、JDK1.7和JDK1.8的差异、红黑树的使用、扩容和树化的条件、退化为链表的情况、索引的计算方法、hashcode和hash()方法的作用、数组容量的选择、Put方法的流程以及并发问题下的操作。文章还提到了扩容死链和数据错乱的问题,并探讨了key的设计要求。对于对Java面试中的HashMap问题感兴趣的读者,本文将为您提供一些有用的技术和经验。 ... [详细]
  • Ihaveaworkfolderdirectory.我有一个工作文件夹目录。holderDir.glob(*)>holder[ProjectOne, ... [详细]
  • 从相邻元素对还原数组的解题思路和代码
    本文介绍了从相邻元素对还原数组的解题思路和代码。思路是使用HashMap存放邻接关系,并找出起始点,然后依次取。代码使用了HashMap来存放起始点所在的adjacentPairs中的位置,并对重复的起始点进行处理。 ... [详细]
author-avatar
刺客狙侠者
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有