NIO+異步的方式能讓少量的線程（資源）做大量的事情，這適用於很多應用場景，比如代理服務、api服務、長連接服務等等，這些應用如果用同步方式將耗費大量機器資源。儘管NIO+異步能提高系統吞吐量，但其並不能讓一個請求的等待時間下降，相反可能會增加等待時間。
Jetty Continuation
從jetty7，Continuations API已經擴展成爲一個通用的API，將異步工作在任何servlet-3.0容器中，以及7、8或9的延續，也將阻止任何servlet2.5容器的工作模式的延續，應該被認爲是一種應用抽象上異步servlet實現了可移植層。
Jetty 的 Continuation 機制
Continuation機制是Jetty用於更好的支持異步Servlet的機制。
討論 Jetty 的 Continuation 機制，首先需要提到 Ajax 技術，Ajax 技術是當前開發 Web 應用的非常熱門的技術，也是 Web 2.0 的一個重要的組成部分。Ajax 技術中的一個核心對象是 XMLHttpRequest 對象，這個對象支持異步請求，所謂異步請求即是指當客戶端發送一個請求到服務器的時候，客戶端不必一直等待服務器的響應。這樣就不會造成整個頁面的刷新，給用戶帶來更好的體驗。而當服務器端響應返回時，客戶端利用一個 Javascript 函數對返回值進行處理，以更新頁面上的部分元素的值。但很多時候這種異步事件只是在很小一部分的情況下才會發生，那麼怎麼保證一旦服務器端有了響應之後客戶端馬上就知道呢，我們有兩種方法來解決這個問題，一是讓瀏覽器每隔幾秒請求服務器來獲得更改，我們稱之爲輪詢。二是服務器維持與瀏覽器的長時間的連接來傳遞數據，長連接的技術稱之爲 Comet技術。
大家很容易就能發現輪詢方式的主要缺點是產生了大量的傳輸浪費。因爲可能大部分向服務器的請求是無效的，也就是說客戶端等待發生的事件沒有發生，如果有大量的客戶端的話，那麼這種網絡傳輸的浪費是非常厲害的。特別是對於服務器端很久才更新的應用程序來講，比如郵件程序，這種浪費就更是巨大了。並且對 Server 端處理請求的能力也相應提高了要求。如果很長時間才向 Server 端發送一次請求的話，那麼客戶端就不能的得到及時的響應。
如果使用 Comet 技術的話，客戶端和服務器端必須保持一個長連接，一般情況下，服務器端每一個 Servlet 都會獨佔一個線程，這樣就會使得服務器端有很多線程同時存在，這在客戶端非常多的情況下也會對服務器端的處理能力帶來很大的挑戰。
Jetty 利用 Java 語言的非堵塞 I/O 技術來處理併發的大量連接。 Jetty 有一個處理長連接的機制：一個被稱爲 Continuations 的特性。利用 Continuation 機制，Jetty 可以使得一個線程能夠用來同時處理多個從客戶端發送過來的異步請求，以達到jetty高性能的特點。具體說來，Jetty實現了一個 基於java.nio API 的SelectChannelConnector，允許它維持每個連接開放而不用消耗一個線程。當連接掛起時，Connector將請求維持在未決 Continuations隊列裏，用來服務請求的線程返回給TheadPool，這樣，該線程又可以服務於其他請求。暫停的請求停留在未決 Continuations 隊列裏直到指定的過期時間，或者在它的Continuation上調用resume()方法。詳情
核心就是把三件不同的事情隔離開，並用不同的線程去處理，最大限度地提高了利用NIO的異步和通知特性。
總結就一句：分而治之，將任務拆分開來，由專門的人負責專門的任務。
