原文：http://blog.csdn.net/he90227/article/details/52262163
什么是異步模式
如何在Spring MVC中使用異步提高性能？
一個普通 Servlet 的主要工作流程大致如下：
用戶查詢開始到返回結果到頁面，此處是一個同步的過程，如果做成異步的能提高系統響應的性能
以下3個步驟都在同一個線程中完成 --- 同步阻塞 --- 請求等待
首先，Servlet 接收到請求之后，可能需要對請求攜帶的數據進行一些預處理；
接着，調用業務接口的某些方法，以完成業務處理；
最后，根據處理的結果提交響應，Servlet 線程結束。
其中第二步的業務處理通常是最耗時的，這主要體現在數據庫操作，以及其它的跨網絡調用等，在此過程中，Servlet 線程一直處於阻塞狀態，直到業務方法執行完畢,
在處理業務的過程中，請求的連接線程數是有限的， Servlet 資源一直被占用而得不到釋放，對於並發較大的應用，這有可能造成性能的瓶頸
使用異步處理：
首先，Servlet 接收到請求之后，可能首先需要對請求攜帶的數據進行一些預處理；
接着，Servlet 線程將請求轉交給一個異步線程來執行業務處理，線程本身返回至容器(線程池)
此時 Servlet 還沒有生成響應數據，異步線程處理完業務以后，可以直接生成響應數據（異步線程擁有 ServletRequest 和 ServletResponse 對象的引用），或者將請求繼續轉發給其它 Servlet。
如此一來， Servlet 線程不再是一直處於阻塞狀態以等待業務邏輯的處理，而是啟動異步線程之后可以立即返回， Servlet request請求線程可以被快速釋放回Web容器，從而提高並發性
Spring MVC 3.2 開始引入Servlet 3中的基於異步的處理request.往常是返回一個值,而現在是一個Controller方法可以返回一個java.util.concurrent.Callable對象和從Spring MVC的托管線程生產返回值.
同時Servlet容器的主線程退出和釋放,允許處理其他請求(處理Http請求的線程是有限的，這里提前釋放，可以大大提高並發性)。Spring MVC通過TaskExecutor的幫助調用Callable在一個單獨的線程。
並且當這個Callable返回時,這個rquest被分配回Servlet容器使用由Callable的返回值繼續處理。
Spring MVC 異步調用 原理：
Spring返回的Callable被RequestMappingHandlerAdapter攔截，使用SimpleAsyncTaskExecutor線程池處理，
每當任務被提交到此“線程池（這里就交線程池了）”時，線程池產生一個新的線程去執行Callable中的代碼，
每次都產生新的線程而且沒有上上限(默認沒有上限的，可以設置concurrencyLimit屬性來設置線程數的大小)
但：SimpleAsyncTaskExecutor 線程池性能不好，可使用自定義的線程池來代替
1.使用ThreadPoolTaskExecutor --- 該線程池可設置線程大小，有緩沖隊列，空閑線程存活時間等
2.封裝Guava的線程池 --- 效率高
eg:
ThreadPoolTaskExecutor --- org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor
配置：
1.設置ThreadPoolTaskExecutor線程池屬性
<bean id="myThreadPool"
class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="corePoolSize" value="5" /><!--最小線程數 -->
<property name="maxPoolSize" value="10" /><!--最大線程數 -->
<property name="queueCapacity" value="50" /><!--緩沖隊列大小 -->
<property name="threadNamePrefix" value="abc-" /><!--線程池中產生的線程名字前綴 -->
<property name="keepAliveSeconds" value="30" /><!--線程池中空閑線程的存活時間單位秒 -->
</bean>
2.在Spring MVC的 <mvc:annotation-driven>中配置，使用該線程池替換默認的 SimpleAsyncTaskExecutor 線程池
<mvc:annotation-driven>
<mvc:async-support task-executor="myThreadPool"
default-timeout="600">
<mvc:callable-interceptors>
<bean class="com.jay.springmvc.async.MyCallableInterceptor" />
</mvc:callable-interceptors>
</mvc:async-support>
</mvc:annotation-driven>
說明：
Callable任務的超時處理 --- 自定義攔截器實現
MyCallableInterceptor implements CallableProcessingInterceptor --- 自定義Callable攔截器 ， 可在這里處理Callable任務的超時問題
public <T> Object handleTimeout(NativeWebRequest request, Callable<T> task)
throws Exception {
HttpServletResponse servletResponse = request.getNativeResponse(HttpServletResponse.class);
if (!servletResponse.isCommitted()) {
servletResponse.setContentType("text/plain;charset=utf-8");
servletResponse.getWriter().write("超時了");
servletResponse.getWriter().close();
}
return null;
}
可優化地方：
由於ThreadPoolTaskExecutor內部緩沖隊列采用的是阻塞隊列LinkedBlockingDeque，如果隊列滿了，外部線程會繼續等待，需要設置HTTP請求的超時時間
線程池的大小配置
Spring MVC對異步處理的支持： ---- Servlet 3.0或以上的版本 + Spring 3.2以上版本
maven： 最新的依賴
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.3.2.RELEASE</version>
</dependency>
3種方式：
Callable<T> --- Spring MVC中線程池調用新線程完成處理，把最耗時的業務邏輯放到Callable
對於Callable來說會默認使用SimpleAsyncTaskExecutor類來執行
eg: --- 這里有主線程和Callable子線程同時執行， 子線程運行完將結果返回， 比單線程(僅：主線程)要快
@RequestMapping("/response-body")
public @ResponseBody Callable<String> callable(final @RequestParam(required=false, defaultValue="true") boolean handled) {
//進行一些與處理之后，把最耗時的業務邏輯部分放到Callable中，注意，如果你需要在new Callable中用到從頁面傳入的參數，需要在參數前加入final
return new Callable<String>() {
@Override
public String call() throws Exception {
if(handled){
Thread.sleep(2000);
}else{
Thread.sleep(2000*2);
}
return "Callable result";
}
};
}
WebAsyncTask
1.在servlet中timeout是一個很重要的問題，servlet容器會嘗試重用request和response對象，
對於一個timeout但是實際上沒有結束的異步請求來說，使用同一個request和response對象影響將無法估量
eg:
使用WebAsyncTask指定超時時間 --- 如果Callable子線程在超時時間內未完成，則拋出自定義異常
@RequestMapping("/custom-timeout-handling")
public @ResponseBody WebAsyncTask<String> callableWithCustomTimeoutHandling() {
System.out.println("Thread - name -" + Thread.currentThread().getName());
Callable<String> callable = new Callable<String>() {
@Override
public String call() throws Exception {
// Thread.sleep(5000);
Thread.sleep(3000);
System.out.println("Thread - name -" + Thread.currentThread().getName());
return "Callable result";
}
};
System.out.println("Thread - name -" + Thread.currentThread().getName());
// 這里設置Callable的超時時間為3s，超時則拋出超時異常，通過自定義的攔截器來處理該超時異常
// 對於Callable子線程的超時的處理，在springContext.xml中配置(這里：采取的處理是，拋出自定義的超時異常)
// 即：如果在3s內，Callable子線程未完成，則拋出自定義的超時異常
return new WebAsyncTask<String>(3000, callable);
}
DeferredResult<?> --- DeferredResult<?> 允許程序從一個線程中返回，而合適返回則由線程決定
要知道什么是異步模式，就先要知道什么是同步模式，先看最典型的同步模式：
(圖1)
瀏覽器發起請求，Web服務器開一個線程處理，處理完把處理結果返回瀏覽器。好像沒什么好說的了，絕大多數Web服務器都如此般處理。現在想想如果處理的過程中需要調用后端的一個業務邏輯服務器，會是怎樣呢？
(圖2)
調就調吧，上圖所示，請求處理線程會在Call了之后等待Return，自身處於阻塞狀態。這也是絕大多數Web服務器的做法，一般來說這樣做也夠了，為啥？一來“長時間處理服務”調用通常不多，二來請求數其實也不多。要不是這樣的話，這種模式會出現什么問題呢？——會出現的問題就是請求處理線程的短缺！因為請求處理線程的總數是有限的，如果類似的請求多了，所有的處理線程處於阻塞的狀態，那新的請求也就無法處理了，也就所謂影響了服務器的吞吐能力。要更加好地發揮服務器的全部性能，就要使用異步，這也是標題上所說的“高性能的關鍵”。接下來我們來看看異步是怎么一回事：
(圖3)
最大的不同在於請求處理線程對后台處理的調用使用了“invoke”的方式，就是說調了之后直接返回，而不等待，這樣請求處理線程就“自由”了，它可以接着去處理別的請求，當后端處理完成后，會鈎起一個回調處理線程來處理調用的結果，這個回調處理線程跟請求處理線程也許都是線程池中的某個線程，相互間可以完全沒有關系，由這個回調處理線程向瀏覽器返回內容。這就是異步的過程。
帶來的改進是顯而易見的，請求處理線程不需要阻塞了，它的能力得到了更充分的使用，帶來了服務器吞吐能力的提升。
Spring MVC的使用——DefferedResult
要使用spring MVC的異步功能，你得先確保你用的是Servlet 3.0或以上的版本，Maven中如此配置：
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>4.2.3.RELEASE</version>
</dependency>
我這里使用的Servlet版本是3.1.0，Spring MVC版本是4.2.3，建議使用最新的版本。
由於Spring MVC的良好封裝，異步功能使用起來出奇的簡單。傳統的同步模式的Controller是返回ModelAndView，而異步模式則是返回DeferredResult<ModelAndView>。
看這個例子：
@RequestMapping(value="/asynctask", method = RequestMethod.GET)
public DeferredResult<ModelAndView> asyncTask(){
DeferredResult<ModelAndView> deferredResult = new DeferredResult<ModelAndView>();
System.out.println("/asynctask 調用！thread id is : " + Thread.currentThread().getId());
longTimeAsyncCallService.makeRemoteCallAndUnknownWhenFinish(new LongTermTaskCallback() {
@Override
public void callback(Object result) {
System.out.println("異步調用執行完成, thread id is : " + Thread.currentThread().getId());
ModelAndView mav = new ModelAndView("remotecalltask");
mav.addObject("result", result);
deferredResult.setResult(mav);
}
});
}
longTimeAsyncCallService是我寫的一個模擬長時間異步調用的服務類，調用之，立即返回，當它處理完成時候，就鈎起一個線程調用我們提供的回調函數，這跟“圖3”描述的一樣，它的代碼如下：
public interface LongTermTaskCallback {
void callback(Object result);
}
public class LongTimeAsyncCallService {
private final int CorePoolSize = 4;
private final int NeedSeconds = 3;
private Random random = new Random();
private ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(CorePoolSize);
public void makeRemoteCallAndUnknownWhenFinish(LongTermTaskCallback callback){
System.out.println("完成此任務需要 : " + NeedSeconds + " 秒");
scheduler.schedule(new Runnable() {
@Override
public void run() {
callback.callback("長時間異步調用完成.");
}
}, "這是處理結果:)", TimeUnit.SECONDS);
}
}
輸出的結果是：
/asynctask 調用！thread id is : 46
完成此任務需要 : 3 秒
異步調用執行完成, thread id is : 47
由此可見返回結果的線程和請求處理線程不是同一線程。
還有個叫WebAsyncTask
返回DefferedResult<ModelAndView>並非唯一做法，還可以返回WebAsyncTask來實現“異步”，但略有不同，不同之處在於返回WebAsyncTask的話是不需要我們主動去調用Callback的，看例子：
@RequestMapping(value="/longtimetask", method = RequestMethod.GET)
public WebAsyncTask longTimeTask(){
System.out.println("/longtimetask被調用 thread id is : " + Thread.currentThread().getId());
Callable<ModelAndView> callable = new Callable<ModelAndView>() {
public ModelAndView call() throws Exception {
Thread.sleep(3000); //假設是一些長時間任務
ModelAndView mav = new ModelAndView("longtimetask");
mav.addObject("result", "執行成功");
System.out.println("執行成功 thread id is : " + Thread.currentThread().getId());
return mav;
}
};
return new WebAsyncTask(callable);
}
其核心是一個Callable<ModelAndView>，事實上，直接返回Callable<ModelAndView>都是可以的，但我們這里包裝了一層，以便做后面提到的“超時處理”。和前一個方案的差別在於這個Callable的call方法並不是我們直接調用的，而是在longTimeTask返回后，由Spring MVC用一個工作線程來調用，執行，打印出來的結果：
/longtimetask被調用 thread id is : 56
執行成功 thread id is : 57
可見確實由不同線程執行的，但這個WebAsyncTask可不太符合“圖3”所描述的技術規格，它僅僅是簡單地把請求處理線程的任務轉交給另一工作線程而已。
處理超時
如果“長時間處理任務”一直沒返回，那我們也不應該讓客戶端無限等下去啊，總歸要弄個“超時”出來。如圖：
(圖4)
其實“超時處理線程”和“回調處理線程”可能都是線程池中的某個線程，我為了清晰點把它們分開畫而已。增加這個超時處理在Spring MVC中非常簡單，先拿WebAsyncTask那段代碼來改一下：
@RequestMapping(value="/longtimetask", method = RequestMethod.GET)
public WebAsyncTask longTimeTask(){
System.out.println("/longtimetask被調用 thread id is : " + Thread.currentThread().getId());
Callable<ModelAndView> callable = new Callable<ModelAndView>() {
public ModelAndView call() throws Exception {
Thread.sleep(3000); //假設是一些長時間任務
ModelAndView mav = new ModelAndView("longtimetask");
mav.addObject("result", "執行成功");
System.out.println("執行成功 thread id is : " + Thread.currentThread().getId());
return mav;
}
};
WebAsyncTask asyncTask = new WebAsyncTask(2000, callable);
asyncTask.onTimeout(
new Callable<ModelAndView>() {
public ModelAndView call() throws Exception {
ModelAndView mav = new ModelAndView("longtimetask");
mav.addObject("result", "執行超時");
System.out.println("執行超時 thread id is ：" + Thread.currentThread().getId());
return mav;
}
}
);
return new WebAsyncTask(3000, callable);
}
注意看紅色字體部分代碼，這就是前面提到的為什么Callable還要外包一層的緣故，給WebAsyncTask設置一個超時回調，即可實現超時處理，在這個例子中，正常處理需要3秒鍾，而超時設置為2秒，所以肯定會出現超時，執行打印log如下：
/longtimetask被調用 thread id is : 59
執行超時 thread id is ：61
執行成功 thread id is : 80
嗯？明明超時了，怎么還會“執行成功”呢？超時歸超時，超時並不會打斷正常執行流程，但注意，出現超時后我們給客戶端返回了“超時”的結果，那接下來即便正常處理流程成功，客戶端也收不到正常處理成功所產生的結果了，這帶來的問題就是：客戶端看到了“超時”，實際上操作到底有沒有成功，客戶端並不知道，但通常這也不是什么大問題，因為用戶在瀏覽器上再刷新一下就好了。:D
好，再來看DefferedResult方式的超時處理：
@RequestMapping(value = "/asynctask", method = RequestMethod.GET)
public DeferredResult<ModelAndView> asyncTask() {
DeferredResult<ModelAndView> deferredResult = new DeferredResult<ModelAndView>(2000L);
System.out.println("/asynctask 調用！thread id is : " + Thread.currentThread().getId());
longTimeAsyncCallService.makeRemoteCallAndUnknownWhenFinish(new LongTermTaskCallback() {
@Override
public void callback(Object result) {
System.out.println("異步調用執行完成, thread id is : " + Thread.currentThread().getId());
ModelAndView mav = new ModelAndView("remotecalltask");
mav.addObject("result", result);
deferredResult.setResult(mav);
}
});
deferredResult.onTimeout(new Runnable() {
@Override
public void run() {
System.out.println("異步調用執行超時！thread id is : " + Thread.currentThread().getId());
ModelAndView mav = new ModelAndView("remotecalltask");
mav.addObject("result", "異步調用執行超時");
deferredResult.setResult(mav);
}
});
return deferredResult;
}
非常類似，對吧，我把超時設置為2秒，而正常處理需要3秒，一定會超時，執行結果如下：
/asynctask 調用！thread id is : 48
完成此任務需要 : 3 秒
異步調用執行超時！thread id is : 51
異步調用執行完成, thread id is : 49
完全在我們預料之中。
異常處理
貌似沒什么差別，在Controller中的處理和之前同步模式的處理是一樣一樣的：
@ExceptionHandler(Exception.class)
public ModelAndView handleAllException(Exception ex) {
ModelAndView model = new ModelAndView("error");
model.addObject("result", ex.getMessage());
return model;
}
還要再弄個全局的異常處理啥的，和過去的做法都一樣，在此不表了。