详解Spring框架下向异步线程传递HttpServletRequest参数的坑

时间:2022-12-05 09:08:59

在spring的注解 @requestmapping 之下可以直接获取 httpservletrequest 来获得诸如request header等重要的请求信息:

?
1
2
3
4
5
6
7
8
9
10
11
12
@slf4j
@restcontroller
@requestmapping("/test")
public class testcontroller {
 
  private static final string header = "app-version";
 
  @requestmapping(value = "/async", method = requestmethod.get)
  public void test(httpservletrequest request) {
        request.getheader(header);
  }
}

往往,这些重要的信息也会在异步线程中被使用到。于是,一个很自然的想法是,那不如直接把这里获取到的request当做参数传到其它spawn出的子线程里,比如:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@slf4j
@restcontroller
@requestmapping("/test")
public class testcontroller {
 
  private static final string header = "app-version";
 
  @requestmapping(value = "/async", method = requestmethod.get)
  public void test(httpservletrequest request) {
    log.info("main thread: " + request.getheader(header));  
    new thread(() -> {
      log.info("child thread: " + request.getheader(header));
    }).start();
  }
}

在header中设置"app-version"为1.0.1后发送 <base_url>/test/async 请求,可以看到结果:

main thread: 1.0.1
child thread: 1.0.1

但是,坑,也就此出现了。

由于 httpservletrequest 不是线程安全的(后知后觉),当主线程完成自己的工作返回response后,相应的诸如 httpservletrequest 等对象就会被销毁。为了看到这个现象,我们可以在子线程中多等待一段时间来保证主线程先于子线程结束。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@slf4j
@restcontroller
@requestmapping("/test")
public class testcontroller {
 
  private static final string header = "app-version";
  private static final long child_thread_wait_time = 5000;
 
  @requestmapping(value = "/async", method = requestmethod.get)
  public void test(httpservletrequest request) {
    log.info("main thread: " + request.getheader(header));
 
    new thread(() -> {
      try {
        thread.sleep(child_thread_wait_time);
      } catch (throwable e) {
 
      }
      log.info("child thread: " + request.getheader(header));
    }).start();
  }
}

在header中设置"app-version"为1.0.1后发送 <base_url>/test/async 请求,可以看到结果:

main thread: 1.0.1
child thread: null

显然,谁也没办法保证自己spawn出来的子线程会先于主线程结束,所以直接传递 httpservletrequest 参数给子线程是不可行的。

网上有一种方法是通过spring框架自带的 requestcontextholder 来获取request,这对异步线程来讲是不可行的。因为只有在负责request处理的线程才能调用到 requestcontextholder 对象,其它线程中它会直接为空。

那么,一个可以想到的笨办法是将request的值取出来,注入到自定义的对象中,然后将这个对象作为参数传递给子线程:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
@slf4j
@restcontroller
@requestmapping("/test")
public class testcontroller {
 
  private static final string header = "app-version";
  private static final long main_thread_wait_time = 0;
  private static final long child_thread_wait_time = 5000;
 
  @requestmapping(value = "/async", method = requestmethod.get)
  public void test(httpservletrequest request) {
    log.info("main thread: " + request.getheader(header));
    testvo testvo = new testvo(request.getheader(header));
 
    new thread(() -> {
      try {
        thread.sleep(child_thread_wait_time);
      } catch (throwable e) {
 
      }
      log.info("child thread: " + request.getheader(header) + ", testvo = " + testvo.getappversion());
    }).start();
 
    try {
      thread.sleep(main_thread_wait_time);
    } catch (throwable e) {
 
    }
  }
 
  @data
  @allargsconstructor
  public static class testvo {
    private string appversion;
  }
}

再按照"app-version"为1.0.1发送请求后得到:

main thread: 1.0.1
child thread: null, testvo = 1.0.1

嗯,终于成功了。

故事似乎到此就结束了,但如果仔细考察细节的话,有几个问题是值得思考的:

  • 如果child thread中的request已经被销毁了,为什么没有报null exception,而只是获取到空的"app-version"的值?
  • 如果request被销毁了,testvo这个同样在主线程中创建的object为什么没有被销毁?
  • 主线程真的可以销毁对象吗?销毁对象不是gc负责的吗,为什么总是可以在child thread中得到null的结果?

一个合理的推理是:主线程结束时,调用了一个 destroy() 方法,这个方法主动将 httpservletrequest 中的资源释放,例如调用了存放header的map对应的 clear() 方法。如此,在子线程中便无法获得之前的"app-version"所对应的value了。而testvo由于是用户自己创建,必然不可能实现在 destroy() 方法中写出释放资源的代码。它的值也就保存下来了。

另外,无论主线程是否调用了 destroy() 方法,真正回收的时候还是gc的工作,这也就解释了在子线程中不是报null exception,而只是取不到特定的key所对应的值。

进一步,我们还可以思考的问题是,为什么在主线程的 destoy() 方法中,不直接将request对象赋值为null呢?

这个问题看似有些蹊跷,而实则根本不成立。因为就算你把主线程的request变量赋值为null时,子线程中的另一个变量已经指向了这个request对应的内存,依旧可以拿到相应的值。例如:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
@slf4j
@restcontroller
@requestmapping("/test")
public class testcontroller {
 
  private static final string header = "app-version";
  private static final long main_thread_wait_time = 5000;
  private static final long child_thread_wait_time = 3000;
 
  @requestmapping(value = "/async", method = requestmethod.get)
  public void test(httpservletrequest request) {
    log.info("main thread: " + request.getheader(header));
    testvo testvo = new testvo(request);
 
    new thread(() -> {
      try {
        thread.sleep(child_thread_wait_time);
      } catch (throwable e) {
 
      }
      log.info("child thread: " + testvo.getrequest().getheader(header));
    }).start();
 
    request = null;
 
    try {
      thread.sleep(main_thread_wait_time);
    } catch (throwable e) {
 
    }
  }
 
  @data
  @allargsconstructor
  public static class testvo {
    private httpservletrequest request;
  }
}

按照"app-version"为1.0.1发送请求后得到:

main thread: 1.0.1
child thread: 1.0.1

这里让子线程等待3秒,以便主线程有充分的时间将request赋值为null。但child线程依旧可以拿到对应的值。

所以,将request变量赋值为null根本无法做到释放资源。所以对request里保存header的map来讲,将变量赋值为null无法保证其它地方的引用也会一并消失。最直接有效的方法是调用 clear() 让map中的每一个元素失效。

所以总结起来是:

  • 主线程的request和testvo,由于都有子线程的变量指向,也即是两个对象上的reference count不为0,gc便不会真正回收这两部分对应的内存。
  • 但是,由于request很可能在主线程中在 destroy() 方法被调用了内部map的 clear() 方法,导致无法获取到header的值。
  • testvo是用户创建的对象,无法事先被放到 destroy() 方法中被释放,所以还能继续保持原有的值。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持服务器之家。

原文链接:https://segmentfault.com/a/1190000018593620