在Servlet 3.0之前：
請求的同步處理的問題是，它會導(dǎo)致線程(執(zhí)行繁重的任務(wù))在響應(yīng)發(fā)出之前運(yùn)行很長時(shí)間。如果這種情況大規(guī)模發(fā)生，servlet容器最終會耗盡線程（長時(shí)間運(yùn)行的線程會導(dǎo)致線程耗盡）。
在Servlet 3.0之前，對于這些長時(shí)間運(yùn)行的線程，有一些特定于容器的解決方案，我們可以生成單獨(dú)的工作線程來執(zhí)行繁重的任務(wù)，然后將響應(yīng)返回給客戶端。啟動工作線程后，Servlet線程返回到Servlet線程池。Tomcat的Comet，WebLogic的FutureResponseServlet和WebSphere的異步請求分派器是異步處理實(shí)現(xiàn)的一些示例。
Servlet 3.0 Async：
實(shí)際工作可以委托給線程池實(shí)現(xiàn)（獨(dú)立于特定于容器的解決方案）。Runnable實(shí)現(xiàn)將執(zhí)行實(shí)際的處理，并將使用AsyncContext將該請求分派到另一個(gè)資源或?qū)懭腠憫?yīng)。我們還可以向AsyncContext對象添加AsyncListener實(shí)現(xiàn)來實(shí)現(xiàn)回調(diào)方法。
Servlet 3.1 NIO：
如上所述，Servlet 3.0允許異步請求處理，但僅允許傳統(tǒng)的I/O（與NIO相對）。為什么傳統(tǒng)的I/O是一個(gè)問題？
在傳統(tǒng)的I/O中，有兩種情況需要考慮：
- 如果進(jìn)入服務(wù)器（I/O）的數(shù)據(jù)阻塞或流傳輸?shù)乃俣缺确?wù)器讀取的速度慢，則嘗試讀取此數(shù)據(jù)的服務(wù)器線程必須等待該數(shù)據(jù)。
- 另一方面，如果從服務(wù)器寫入
ServletOutputStream的響應(yīng)數(shù)據(jù)很慢，則客戶端線程必須等待。在這兩種情況下，服務(wù)器線程都執(zhí)行傳統(tǒng)的I/O（用于請求/響應(yīng)）塊。
換句話說，使用Servlet 3.0，只有請求處理的部分變?yōu)楫惒?，而沒有用于服務(wù)請求和響應(yīng)的I/O。如果有足夠的線程阻塞，這將導(dǎo)致線程耗盡，并影響性能。
在Servlet 3.1 NIO中，這個(gè)問題通過ReadListener和WriteListener接口解決。它們在ServletInputStream和ServletOutputStream中注冊。偵聽器具有回調(diào)方法，當(dāng)內(nèi)容可讀或可寫時(shí)調(diào)用，而不需要servlet容器阻塞I/O線程。因此，這些I/O線程被釋放，現(xiàn)在可以為其他請求提供服務(wù)，從而提高性能。
