在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
