Servlet 3 0中的非同步處理

在以前的servlet規範化，如果servlet作為控制器呼叫了乙個耗時的業務方法，那麼必須等到業務方法完全返回之後才能生成響應，這將使用servlet對業務方法的呼叫變成一種阻塞式的呼叫，因此效率比較低。

servlet3.0規範引入了非同步處理來解決這個問題，非同步處理允許servlet重新發起一條新執行緒去呼叫耗時業務方法，這樣就可以避免等待。

servlet3.0的非同步處理是通過asynccontext類來處理的，servlet可通過servletrequest的如下兩個方法開啟非同步呼叫，建立asynccontext物件：

startasync(servletrequest, servletresponse)傳入指定的request和response物件，便於在asynccontext中重複使用（這樣被filter、servlet包裝過的請求、相應物件才會在非同步的環境下繼續生效）。

startasync()

呼叫httpservletrequest.startasync()，將servlet置於非同步模式，返回asynccontext物件，且流將不在從servlet.service()返回時提交。

isasyncsupported()和isasyncstarted()

輔助性的方法，用於判斷當前請求是否支援非同步或者非同步已經開始。

getasynccontext()

需要在非同步啟動之後才能夠訪問，否則會報異常。asynccontext.start()

啟動請求 —— 將其指派給工作執行緒。

在asynccontext中分發的方法有三個，不太容易區分：

asynccontext.dispatch()

若當前asynccontext由servletrequest.startasync(servletrequest, servletresponse)方法啟動，返回的位址可以通過httpservletrequest.getrequesturi()得到。

否則，分發的位址則是當前url request物件最後一次分發的位址。

雖有些拗口，兩者分發的位址大部分情況下一致;但盡量使用帶有引數的非同步上下文啟動器。

如本例中請求/asyncdispatch2async?disurl=self，執行dispatch()方法之後，自身會再次分發到自身，包括傳遞的引數。

asynccontext.dispatch(string path)

等同於servletrequest.getrequestdispatcher(string)，算是乙個快捷方法。

可以轉向乙個同步或非同步的servlet，或者jsp，或其它資源位址等。

asynccontext.dispatch(servletcontext context, string path)

請求的位址將在給定的上下文裡面（servletcontext），有有可能傳入的上下文與當前站帶你應用的上下文有所區別。