原文：http://www.importnew.com/21051.html
要知道什么是異步模式，就先要知道什么是同步模式，先看最典型的同步模式：
(圖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);
}
});
}
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;
}