說過了伺服器啟動，最後來看一下請求處理過程，
伺服器啟動好後，處於待命狀態，請求來了，請求處理過程由分兩個建階段：
前面有提到，從執行緒池中固定分配了乙個執行緒專門用於等待新連線，就是上圖的監聽執行緒，沒有請求來時，該執行緒是阻塞在 accept () 方法上的，當新連線來建立連線時， accept 方法分配了乙個 socket ，並將其設定為 nonblocking, 最後要做的就是將該 socket 丟給某個 acceptor 執行緒 ( 基本上機會均等 ) 處理，然後立馬返回繼續處於接受狀態，可以這個執行緒的工作是相當的簡單的，效率那也是相當的高。
acceptor 執行緒有很多個 ( 全部來自於執行緒池，並且固定分配出來，基於 jetty.xml 配置中的 acceptors 配置數量 ) ，每個執行緒都維護了乙個 selectset, 每個 selectset 又對應了乙個 selector, 這些執行緒會檢測當前是否有任務來，例如檢測 changes 佇列中是否有任務，有並且是新連線，那麼就迅速建立乙個 endpoint 點負責管理這個 socket ，並註冊 read 事件，後續該 selector 就會負責該連線的 read 事件監聽。
對於連線很多的情況，這裡分很多個 selector 來分別監聽，提高了效率。
當資料傳送過來時， selector 檢測到 read 事件，會立馬呼叫 endpoint 的 schedule() 方法，該方法目的就是從執行緒池分配乙個 worker 執行緒專門來處理這個 read 事件，而自己卻立馬返回繼續監聽，可見，這裡也是乙個高效的處理方式。
業務執行緒分配成功後，負責請求的讀取以及解析，如果請求是完整的，那麼就開始呼叫 server 的 handle 方法 (server 本身就是乙個 handler) ，開始 handler 的處理，最後呼叫到 serlvethandler ，最終交給 servlet 、 filter ，開始了我們的自己應用。
1、 jetty 的模組化做得非常好，可以隨時替換其中的絕大部分關鍵部件，也可以拆掉，例如不需要處理 session ，可以簡單配置一下即可搞定，不需要處理 servlet, 可以不用配置 servlethandler. 2、
jetty 採用非阻塞 io 時，我們可以看到從頭到尾的幾次執行緒池分配情況，第一次 分配乙個固定執行緒監聽新連線，第二次 分配 n 個固定執行緒監聽 read 事件（這裡的 n 個執行緒在 7.3 版本中配置檔案中配置 acceptors 數量即可，也就是說會從執行緒池固定分配 n 個執行緒出來），第三次 分配執行緒就是 read 事件到來之後，立即分配乙個業務執行緒 ( 這個是臨時的，用了要** ) 處理資料直到我們應用返回結果。最後有乙個地方 上面都沒有說到，那就是超時等原因要關閉連線時，是分配了臨時執行緒來處理這些事情 3、
模組化、切分 task 4、
小，真的很小
延伸閱讀
1、 jetty continuations
2、 tomcat comet
Jetty 伺服器架構分析 下
說過了伺服器啟動，最後來看一下請求處理過程，伺服器啟動好後，處於待命狀態，請求來了，請求處理過程由分兩個建階段 前面有提到，從執行緒池中固定分配了乙個執行緒專門用於等待新連線，就是上圖的監聽執行緒，沒有請求來時，該執行緒是阻塞在 accept 方法上的，當新連線來建立連線時，accept 方法分配了...
Jetty 伺服器架構分析 下
說過了伺服器啟動，最後來看一下請求處理過程，伺服器啟動好後，處於待命狀態，請求來了，請求處理過程由分兩個建階段 前面有提到，從執行緒池中固定分配了乙個執行緒專門用於等待新連線，就是上圖的監聽執行緒，沒有請求來時，該執行緒是阻塞在 accept 方法上的，當新連線來建立連線時，accept 方法分配了...
jetty搭建http伺服器
以前習慣於tomcat，相對而言，jetty也有很多優點，操作簡單，搭建http服務也很容易。最近因為專案需要，需要直接啟動乙個http server，供其它模組來調。具體如下 3 新建乙個sever類，如下 public class servermain api.3.1.0.jar即可 結果ok。...