Servlet 3.0之前：每一次Http請求都由一個線程從頭到尾處理。

Servlet 3.0之后，提供了異步處理請求：可以先釋放容器分配給請求的線程與相關資源，減輕系統負擔，從而增加服務的吞吐量。

在springboot應用中，可以有4種方式實現異步接口：

• AsyncContext
• Callable
• WebAsyncTask
• DeferredResult

第一中AsyncContext是Servlet層級的，比較原生的方式，本文不對此介紹（一般都不使用它，太麻煩了）。本文著重介紹后面三種方式。

特別說明：服務端的異步或同步對于客戶端而言是不可見的。不會因為服務端使用了異步，接口的結果就和同步不一樣了。另外，對于單個請求而言，使用異步接口會導致響應時間比同步大，但不特別明顯。具體后文分析。

基于Callable實現

Controller中，返回一個java.util.concurrent.Callable包裝的任何值，都表示該接口是一個異步接口：

@GetMapping("/testCallAble")
public Callable<String> testCallAble() {
    return () -> {
        Thread.sleep(40000);
        return "hello";
    };
}

服務器端的異步處理對客戶端來說是不可見的。例如，上述接口，最終返回的客戶端的是一個String，和同步接口中，直接返回String的效果是一樣的。

Callable 處理過程如下：

• 控制器返回一個 Callable。
• Spring MVC 調用 request.startAsync() 并將 Callable 提交給 AsyncTaskExecutor 以在單獨的線程中進行處理。
• 同時， DispatcherServlet 和所有過濾器退出 Servlet 容器線程，但response保持打開狀態。
• 最終 Callable 產生結果，Spring MVC將請求分派回Servlet容器以完成處理。
• 再次調用 DispatcherServlet，并使用 Callable 異步生成的返回值繼續處理。

Callable默認使用SimpleAsyncTaskExecutor類來執行，這個類非常簡單而且沒有重用線程。在實踐中，需要使用AsyncTaskExecutor類來對線程進行配置。

基于WebAsyncTask實現

Spring提供的WebAsyncTask是對Callable的包裝，提供了更強大的功能，比如：處理超時回調、錯誤回調、完成回調等。本質上，和Callable區別不大，但是由于它額外封裝了一些事件的回調，所有，通常都使用WebAsyncTask而不是Callable：

@GetMapping("/webAsyncTask")
public WebAsyncTask<String> webAsyncTask() {
    WebAsyncTask<String> result = new WebAsyncTask<>(30003, () -> {
        return "success";
    });
    result.onTimeout(() -> {
        log.info("timeout callback");
        return "timeout callback";
    });
    result.onCompletion(() -> log.info("finish callback"));
    return result;
}

這里額外提一下，WebAsyncTask可以配置一個超時時間，這里配置的超時時間比全局配置的超時時間優先級都高（會覆蓋全局配置的超時時間）。

基于DeferredResult實現

DeferredResult使用方式與Callable類似，但在返回結果時不一樣，它返回的時實際結果可能沒有生成，實際的結果可能會在另外的線程里面設置到DeferredResult中去。

//定義一個全局的變量，用來存儲DeferredResult對象
private Map<String, DeferredResult<String>> deferredResultMap = new ConcurrentHashMap<>();

@GetMapping("/testDeferredResult")
public DeferredResult<String> testDeferredResult(){
    DeferredResult<String> deferredResult = new DeferredResult<>();
    deferredResultMap.put("test", deferredResult);
    return deferredResult;
}

如果調用以上接口，會發現客戶端的請求一直是在pending狀態——等待后端響應。這里，我簡單的將該接口返回的DeferredResult對象存放在了一個Map集合中，實際應用中可以設計一個對象管理器來統一管理這些個對象。

注意：要考慮定時輪詢（或其他方式）這些對象，將已經處理過或無效的DeferredResult對象清理掉（DeferredResult.isSetOrExpired方法可以判斷是否還有效），避免內存泄露。

這里我又寫了一個接口，模擬：

@GetMapping("/testSetDeferredResult")
public String testSetDeferredResult() throws InterruptedException {
    DeferredResult<String> deferredResult = deferredResultMap.get("test");
    boolean flag = deferredResult.setResult("testSetDeferredResult");
    if(!flag){
        log.info("結果已經被處理，此次操作無效");
    }
    return "ok";
}

其他線程修改DeferredResult的值：首先是從之前存放DeferredResult的map中拿到DeferredResult的值，然后設置它的返回值。當執行deferredResult.setResult之后，可以看到之前pending狀態的接口完成了響應，得到的結果，就是這里設置的值。

這里也額外說下：在返回DeferredResult時也可以設置超時時間，這個時間的優先級也是大于全局設置的。另外，判斷DeferredResult是否有效，只是一個簡單的判斷，實際中判斷有效的并不一定是有效的（比如：客戶端取消了請求，服務端是不知道的），但是一般判斷為無效的，那肯定是無效了。

DeferredResult 處理過程如下：

• 控制器返回一個 DeferredResult 并將其保存在可以訪問的內存隊列或列表中。
• Spring MVC 調用 request.startAsync() 。
• 同時，DispatcherServlet 和所有配置的過濾器退出請求處理線程，但響應保持打開狀態。
• 應用程序從某個線程設置 DeferredResult，Spring MVC 將請求分派回 Servlet 容器。
• 再次調用 DispatcherServlet，并使用異步生成的返回值繼續處理。

提供一個線程池

異步請求，不會一直占用請求的主線程（tomcat容器中處理請求的線程），而是通過一個其他的線程來處理異步任務。也正是如此，在相同的最大請求數配置下，異步請求由于迅速的釋放了主線程，所以才能提高吞吐量。

這里提到一個其他線程，那么這個其他線程我們一般都不適用默認的，都是根據自身情況提供一個線程池供異步請求使用：（我給的參數都是測試用的，實際中不可照搬）

@Bean("mvcAsyncTaskExecutor")
public AsyncTaskExecutor asyncTaskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    // 線程池維護線程的最少數量
    // asyncServiceExecutor.setCorePoolSize(Runtime.getRuntime().availableProcessors() + 1);
    executor.setCorePoolSize(5);
    // 線程池維護線程的最大數量
    executor.setMaxPoolSize(10);
    // 線程池所使用的緩沖隊列
    executor.setQueueCapacity(10);
    //   asyncServiceExecutor.prefersShortLivedTasks();
    executor.setThreadNamePrefix("fyk-mvcAsyncTask-Thread-");
//      asyncServiceExecutor.setBeanName("TaskId" + taskId);
    //  asyncServiceExecutor.setKeepAliveSeconds(20);
    //調用者執行
    //   asyncServiceExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy());
    // 線程全部結束才關閉線程池
    executor.setWaitForTasksToCompleteOnShutdown(true);
    // 如果超過60s還沒有銷毀就強制銷毀，以確保應用最后能夠被關閉，而不是阻塞住
    executor.setAwaitTerminationSeconds(30);
    executor.initialize();

    return executor;
}

把這個線程池配置設置到異步請求配置中：

@Configuration
public class FykWebMvcConfigurer implements WebMvcConfigurer {

    @Autowired
    @Qualifier("mvcAsyncTaskExecutor")
    private AsyncTaskExecutor asyncTaskExecutor;

    @Override
    public void configureAsyncSupport(AsyncSupportConfigurer configurer) {
        //異步操作的超時時間，值為0或者更小，表示永不超時
        configurer.setDefaultTimeout(60001);
        configurer.setTaskExecutor(asyncTaskExecutor);
    }
}

什么時候使用異步請求

異步請求能提高吞吐量，這個是建立在相同配置（這里的配置指的是：最大連接數、最大工作線程數）的情況下。因此并不是說任何接口都可以使用異步請求。

比如：一個請求是進行大量的計算（總之就是在處理這個請求的業務方法時CPU是沒有休息的），這種情況使用異步請求就沒有多大意義了，因為這時的異步請求只是把一個任務從tomcat的工作線程搬到了另一個線程罷了。直接調大最大工作線程數配置也能到達要求。

所以，真正使用異步請求的場景應該是該請求的業務代碼中，大量的時間CPU是休息的（比如：在業務代碼中請求其他系統的接口，在其他系統響應之前，CPU是阻塞等待的），這個時候使用異步請求，就可以釋放tomcat的工作線程，讓釋放的工作線程可以處理其他的請求，從而提高吞吐量。

由于異步請求增加了更多的線程切換（同步請求是同一個工作線程一直處理），所以理論上會增加接口的耗時。但，這個耗時很短很短。