Spring框架下向異步線程傳遞HttpServletRequest參數的坑

在spring的註解 @RequestMapping 之下能夠直接獲取 HttpServletRequest 來得到諸如request header等重要的請求信息:java

@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出的子線程裏,好比:spring

@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.1app

可是,坑,也就此出現了。框架

因爲 HttpServletRequest 不是線程安全的(後知後覺),當主線程完成本身的工做返回response後,相應的諸如 HttpServletRequest 等對象就會被銷燬。爲了看到這個現象,咱們能夠在子線程中多等待一段時間來保證主線程先於子線程結束。異步

@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 請求,能夠看到結果:async

Main thread: 1.0.1

Child thread: nullurl

顯然,誰也沒辦法保證本身spawn出來的子線程會先於主線程結束,因此直接傳遞 HttpServletRequest 參數給子線程是不可行的。spa

網上有一種方法是經過spring框架自帶的 RequestContextHolder 來獲取request,這對異步線程來說是不可行的。由於只有在負責request處理的線程才能調用到 RequestContextHolder 對象,其它線程中它會直接爲空。線程

那麼,一個能夠想到的笨辦法是將request的值取出來,注入到自定義的對象中,而後將這個對象做爲參數傳遞給子線程:

@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對應的內存,依舊能夠拿到相應的值。例如:

@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() 方法中被釋放,因此還能繼續保持原有的值。
相關文章
相關標籤/搜索