說過了伺服器啟動，最後來看一下請求處理過程，
伺服器啟動好後，處於待命狀態，請求來了，請求處理過程由分兩個建階段：
前面有提到，從執行緒池中固定分配了乙個執行緒專門用於等待新連線，就是上圖的監聽執行緒，沒有請求來時，該執行緒是阻塞在
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。...