這篇文章主要為大家展示了“如何解決Spring框架下向異步線程傳遞HttpServletRequest參數(shù)的坑”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“如何解決Spring框架下向異步線程傳遞HttpServletRequest參數(shù)的坑”這篇文章吧。
忠縣網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,忠縣網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為忠縣成百上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的忠縣做網(wǎng)站的公司定做！
在spring的注解 @RequestMapping 之下可以直接獲取 HttpServletRequest 來(lái)獲得諸如request header等重要的請(qǐng)求信息：
重慶分公司
重慶分公司
@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);
}
}往往，這些重要的信息也會(huì)在異步線程中被使用到。于是，一個(gè)很自然的想法是，那不如直接把這里獲取到的request當(dāng)做參數(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中設(shè)置"app-version"為1.0.1后發(fā)送
Main thread: 1.0.1
Child thread: 1.0.1
但是，坑，也就此出現(xiàn)了。
由于 HttpServletRequest 不是線程安全的（后知后覺(jué)），當(dāng)主線程完成自己的工作返回response后，相應(yīng)的諸如 HttpServletRequest 等對(duì)象就會(huì)被銷毀。為了看到這個(gè)現(xiàn)象，我們可以在子線程中多等待一段時(shí)間來(lái)保證主線程先于子線程結(jié)束。
@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中設(shè)置"app-version"為1.0.1后發(fā)送 請(qǐng)求，可以看到結(jié)果：
Main thread: 1.0.1
Child thread: null
顯然，誰(shuí)也沒(méi)辦法保證自己spawn出來(lái)的子線程會(huì)先于主線程結(jié)束，所以直接傳遞 HttpServletRequest 參數(shù)給子線程是不可行的。
網(wǎng)上有一種方法是通過(guò)spring框架自帶的 RequestContextHolder 來(lái)獲取request，這對(duì)異步線程來(lái)講是不可行的。因?yàn)橹挥性谪?fù)責(zé)request處理的線程才能調(diào)用到 RequestContextHolder 對(duì)象，其它線程中它會(huì)直接為空。
那么，一個(gè)可以想到的笨辦法是將request的值取出來(lái)，注入到自定義的對(duì)象中，然后將這個(gè)對(duì)象作為參數(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ā)送請(qǐng)求后得到：
Main thread: 1.0.1
Child thread: null, testVo = 1.0.1
嗯，終于成功了。
故事似乎到此就結(jié)束了，但如果仔細(xì)考察細(xì)節(jié)的話，有幾個(gè)問(wèn)題是值得思考的：
如果child thread中的request已經(jīng)被銷毀了，為什么沒(méi)有報(bào)null exception，而只是獲取到空的"app-version"的值？
如果request被銷毀了，TestVo這個(gè)同樣在主線程中創(chuàng)建的object為什么沒(méi)有被銷毀？
主線程真的可以銷毀對(duì)象嗎？銷毀對(duì)象不是GC負(fù)責(zé)的嗎，為什么總是可以在child thread中得到null的結(jié)果？
一個(gè)合理的推理是：主線程結(jié)束時(shí)，調(diào)用了一個(gè) destroy() 方法，這個(gè)方法主動(dòng)將 HttpServletRequest 中的資源釋放，例如調(diào)用了存放header的map對(duì)應(yīng)的 clear() 方法。如此，在子線程中便無(wú)法獲得之前的"app-version"所對(duì)應(yīng)的value了。而TestVo由于是用戶自己創(chuàng)建，必然不可能實(shí)現(xiàn)在 destroy() 方法中寫出釋放資源的代碼。它的值也就保存下來(lái)了。
另外，無(wú)論主線程是否調(diào)用了 destroy() 方法，真正回收的時(shí)候還是GC的工作，這也就解釋了在子線程中不是報(bào)null exception，而只是取不到特定的key所對(duì)應(yīng)的值。
進(jìn)一步，我們還可以思考的問(wèn)題是，為什么在主線程的 destoy() 方法中，不直接將request對(duì)象賦值為null呢？
這個(gè)問(wèn)題看似有些蹊蹺，而實(shí)則根本不成立。因?yàn)榫退隳惆阎骶€程的request變量賦值為null時(shí)，子線程中的另一個(gè)變量已經(jīng)指向了這個(gè)request對(duì)應(yīng)的內(nèi)存，依舊可以拿到相應(yīng)的值。例如：
@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ā)送請(qǐng)求后得到：
Main thread: 1.0.1
Child thread: 1.0.1
這里讓子線程等待3秒，以便主線程有充分的時(shí)間將request賦值為null。但child線程依舊可以拿到對(duì)應(yīng)的值。
所以，將request變量賦值為null根本無(wú)法做到釋放資源。所以對(duì)request里保存header的map來(lái)講，將變量賦值為null無(wú)法保證其它地方的引用也會(huì)一并消失。最直接有效的方法是調(diào)用 clear() 讓map中的每一個(gè)元素失效。
所以總結(jié)起來(lái)是：
主線程的request和testVo，由于都有子線程的變量指向，也即是兩個(gè)對(duì)象上的reference count不為0，GC便不會(huì)真正回收這兩部分對(duì)應(yīng)的內(nèi)存。
但是，由于request很可能在主線程中在 destroy() 方法被調(diào)用了內(nèi)部map的 clear() 方法，導(dǎo)致無(wú)法獲取到header的值。
testVo是用戶創(chuàng)建的對(duì)象，無(wú)法事先被放到 destroy() 方法中被釋放，所以還能繼續(xù)保持原有的值。
以上是“如何解決Spring框架下向異步線程傳遞HttpServletRequest參數(shù)的坑”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
