詳解Spring框架下向異步線程傳遞HttpServletRequest參數(shù)的坑
在spring的注解 @RequestMapping 之下可以直接獲取 HttpServletRequest 來獲得諸如request header等重要的請求信息:
@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當做參數(shù)傳到其它spawn出的子線程里,比如:
@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后發(fā)送 <base_url>/test/async 請求,可以看到結果:
Main thread: 1.0.1
Child thread: 1.0.1
但是,坑,也就此出現(xiàn)了。
由于 HttpServletRequest 不是線程安全的(后知后覺),當主線程完成自己的工作返回response后,相應的諸如 HttpServletRequest 等對象就會被銷毀。為了看到這個現(xiàn)象,我們可以在子線程中多等待一段時間來保證主線程先于子線程結束。
@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后發(fā)送 <base_url>/test/async
請求,可以看到結果:
Main thread: 1.0.1
Child thread: null
顯然,誰也沒辦法保證自己spawn出來的子線程會先于主線程結束,所以直接傳遞 HttpServletRequest
參數(shù)給子線程是不可行的。
網(wǎng)上有一種方法是通過spring框架自帶的 RequestContextHolder
來獲取request,這對異步線程來講是不可行的。因為只有在負責request處理的線程才能調用到 RequestContextHolder
對象,其它線程中它會直接為空。
那么,一個可以想到的笨辦法是將request的值取出來,注入到自定義的對象中,然后將這個對象作為參數(shù)傳遞給子線程:
@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發(fā)送請求后得到:
Main thread: 1.0.1
Child thread: null, testVo = 1.0.1
嗯,終于成功了。
故事似乎到此就結束了,但如果仔細考察細節(jié)的話,有幾個問題是值得思考的:
- 如果child thread中的request已經(jīng)被銷毀了,為什么沒有報null exception,而只是獲取到空的"app-version"的值?
- 如果request被銷毀了,TestVo這個同樣在主線程中創(chuàng)建的object為什么沒有被銷毀?
- 主線程真的可以銷毀對象嗎?銷毀對象不是GC負責的嗎,為什么總是可以在child thread中得到null的結果?
一個合理的推理是:主線程結束時,調用了一個 destroy() 方法,這個方法主動將 HttpServletRequest 中的資源釋放,例如調用了存放header的map對應的 clear() 方法。如此,在子線程中便無法獲得之前的"app-version"所對應的value了。而TestVo由于是用戶自己創(chuàng)建,必然不可能實現(xiàn)在 destroy() 方法中寫出釋放資源的代碼。它的值也就保存下來了。
另外,無論主線程是否調用了 destroy() 方法,真正回收的時候還是GC的工作,這也就解釋了在子線程中不是報null exception,而只是取不到特定的key所對應的值。
進一步,我們還可以思考的問題是,為什么在主線程的 destoy() 方法中,不直接將request對象賦值為null呢?
這個問題看似有些蹊蹺,而實則根本不成立。因為就算你把主線程的request變量賦值為null時,子線程中的另一個變量已經(jīng)指向了這個request對應的內存,依舊可以拿到相應的值。例如:
@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發(fā)送請求后得到:
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是用戶創(chuàng)建的對象,無法事先被放到 destroy() 方法中被釋放,所以還能繼續(xù)保持原有的值。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關文章
IDEA中Spring Initializr沒有Java8選項的解決辦法
在使用IDEA中的Spring Initializr創(chuàng)建新項目時,Java 版本近可選擇Java17,21 ,不能選擇Java8;SpringBoot 版本也只有 3.x,所以本文給大家介紹了IDEA中Spring Initializr沒有Java8選項的解決辦法,需要的朋友可以參考下2024-06-06SpringSecurity微服務實戰(zhàn)之公共模塊詳解
這篇文章主要為大家介紹了SpringSecurity微服務實戰(zhàn)之公共模塊詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-08-08Jmeter對響應數(shù)據(jù)實現(xiàn)斷言代碼實例
這篇文章主要介紹了Jmeter對響應數(shù)據(jù)實現(xiàn)斷言代碼實例,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-09-09