SpringBoot異步接口實現：提高系統的吞吐量
前言
Servlet 3.0之前：每一次Http請求都由一個線程從頭到尾處理。
Servlet 3.0之后，提供了異步處理請求：可以先釋放容器分配給請求的線程與相關資源，減輕系統負擔，從而增加服務的吞吐量。
在springboot應用中，可以有4種方式實現異步接口（至于ResponseBodyEmitter、SseEmitter、StreamingResponseBody，不在本文介紹內，之后新寫文章介紹）：
- 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的工作線程，讓釋放的工作線程可以處理其他的請求，從而提高吞吐量。
由于異步請求增加了更多的線程切換（同步請求是同一個工作線程一直處理），所以理論上會增加接口的耗時。但，這個耗時很短很短。
