服务器之家:专注于服务器技术及软件下载分享
分类导航

PHP教程|ASP.NET教程|Java教程|ASP教程|编程技术|正则表达式|C/C++|IOS|C#|Swift|Android|VB|R语言|JavaScript|易语言|vb.net|

服务器之家 - 编程语言 - Java教程 - 关于Spring MVC在Controller层中注入request的坑详解

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

2021-04-21 14:30sluggarddd Java教程

这篇文章主要给大家介绍了关于Spring MVC在Controller层中注入request的坑的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧。

前言

记一次为了节省代码没有在方法体中声明httpservletrequest,而用autowire直接注入所钻的坑

结论:给心急的人。 直接在controller的成员变量上使用@autowire声明httpservletrequest,这是线程安全的!

?
1
2
3
4
5
6
7
8
9
@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,一般需要在方法上声明,如:

?
1
2
3
public result save(httpservletrequest request){
 // dosomething();
}

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

?
1
2
3
4
5
6
7
public class commoncontroller{
 @autowire
 httpservletreqeust request;
 public string getuid(){
  return (string)request.getattribute("uid");
 }
}

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

方法1

第一个方法就是在controller的方法中显示声明httpservletreqeust,代码如下:

?
1
2
3
4
5
6
7
8
9
10
@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销毁了,所以又从起始地址开始创建,这样一切就解释得通了!

猜测完毕

验证猜想:

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

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@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

输出

?
1
2
3
4
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相同。

二轮验证

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
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处理。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
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有可能覆盖掉之前的!

验证代码

?
1
2
3
4
5
6
7
8
9
10
@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;
 }
}
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
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();
  }
 }
}

截取了部分输出结果

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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。

?
1
2
3
4
5
6
7
8
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却是不同的,具体里面如何实现我也就没有继续深挖了。

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

总结

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

原文链接:https://my.oschina.net/sluggarddd/blog/678603?fromerr=XhvpvVTi

延伸 · 阅读

精彩推荐