Tomcat請求處理流程與源碼淺析(最新推薦)
在tomcat中，Connector負責開啟socket并且監聽客戶端請求，返回響應數據。
其中：
Endpoint：tomcat中沒有這個接口，只有AbstractEndpoint,它負責啟動線程來監聽服務器端口，并且在接受到數據后交給Processor處理Processor：Processor讀取到客戶端請求后按照請求地址映射到具體的容器進行處理，這個過程請求映射，Processor實現請求映射依賴于Mapper對象，在容器發生注冊和注銷的時候，MapperListener會監聽到對應的事件，從而來變更Mapper中維護的請求映射信息。ProtocolHandler：協議處理器，針對不同的IO方式（NIO，BIO等）和不同的協議（Http，AJP）具備不同的實現，ProtocolHandler包含一個Endpoint來開啟端口監聽，并且包含一個Processor用于按照協議讀取數據并將請求交給容器處理。Acceptor：Acceptor實現了Runnable接口，可以作為一個線程啟動，使用Socket API監聽指定端口，用于接收用戶請求。Poller：主要用于監測注冊在原始 scoket 上的事件是否發生，Acceptor接受到請求后，會注冊到Poller的隊列中。二丶NioEndpoint 初始化ServerSocketChannelspringboot內嵌tomcat，一般默認使用NioEndpoint，在NioEndpoint#start方法中，會觸發NioEndpoint#bind
NioEndpoint#start方法最后會觸發Poller線程和Acceptor線程的啟動
可以看到NioEndpoint內部的Poller，和Acceptor都是單獨使用一個守護線程來運行。
四丶Acceptor接收請求
其內部使用LimitLatch#countUpOrAwait方法限制連接數，如果連接數達到了上限，那將掛起當前線程，也就是掛起Acceptor線程，從而導致無法有更多的請求連接上來，最大連接數默認為8*1024。
LimitLatch 內部持有一個AbstractQueuedSynchronizer，限制連接數將調用其acquireSharedInterruptibly(1)，然后會調用到AQS的tryAcquireShared，其內部使用AtomicLong來進行連接的計數。
由于NioEndpoint前面調用了ServerSocketChannel#configureBlocking(true)，所以serverSock#accept，在沒有連接上來時，不會立馬返回null，而是阻塞直到連接來到。
3.NioEndpoint#setSocketOptions將SocketChannel注冊到Poller
在Acceptor線程接收到SocketChannel后，會調用Poller#register方法進行注冊，Acceptor只負責接受請求，請求后續的處理由Poller線程負責
最終請求被包裝為PollerEvent丟到Poller的事件隊列SynchronizedQueue中，SynchronizedQueue使用synchronized保證線程安全。
wakeupCounter 是AtomicLong類型，Acceptor接受到請求，將請求封裝為PollerEvent后會調用wakeupCounter#incrementAndGet方法，進行+1操作
Poller在使用Selector，進行IO多路復用的時候，會進行如下操作
可以看到，如果wakeupCounter大于0,Poller會調用 selector.selectNow()（非阻塞立馬返回），反之調用selector.select(selectorTimeout)(超時并阻塞)。
也就說Acceptor接受到請求越多，wakeupCounter越大，越會讓Poller調用selector.selectNow()減少阻塞，從而讓Poller更快的檢查事件是否就緒，從而讓請求更及時的被處理。
五丶Poller處理事件1.events方法查看事件隊列是否具備事件上面我們說到Acceptor在建立連接后，將SocketChannel包裝成NioSocketWrapper塞到了Poller的事件隊列中。而Poller線程則會一直輪詢這個隊列進行事件的獲取
通過Selector獲取獲取當前就緒的IO，keyCount記錄就緒數目。
3.Poller 處理就緒IO
processKey會調用到processSocket，最終使用tomcat線程池中的線程進行異步處理
最終會找到Processor進行處理（默認使用緩存的，避免重復new對象，頻繁gc，如果緩存沒有那么使用ProtocolHandler 創建出一個），這里的Processor就是Http11Processor
然后根據事件類型進行不同的處理，如果是讀事件那么會調用Http11Processor#service進行處理，然后會繼續交給CoyoteAdapter調用其service進行處理。
六丶CoyoteAdapter處理請求1.使用Mapper找到請求對應的Host，Context，Wrapper
下圖是的模型，如果使用了SpringMVC，這里的Wrapper會存在DispatchServlet
如下是Mapper找到的MappingData
上面說到，Mapper會找到當前請求所屬的host，context和對應的Wrapper，緊接著會進行Pipeline的執行。
為了增強擴展性，tomcat定義了Pipeline（管道）和Valve（閥），Pipeline使用職責鏈的方式串聯多個Valve——來自客戶端的請求如同流水一樣流淌在管道中，受到每一個閥的作用。
Pipeline中維護了基礎的Valve，始終位于Pipeline末端，通過Pipeline#addValve添加的Valve違約基礎的Valve之前。
在Tomcat中Engine，Host，Context，Wrapper都有對應的Valve實現，同時維護了一個Pipeline，從而讓我們可以對請求的處理進行擴展。
下面是比較重要的Valve
StandardEngineValve ：Engine對應的Valve，負責請求是否通過mapper找到了對應的Host，并觸發Host對應的Valve
ErrorReportValve： 錯誤報告Valve讓后續的Valve繼續執行，如果執行出現錯誤那么會刷新響應流，讓客戶端收到響應
StandardHostValve：Host對應的Valve，如果請求沒有匹配的context返回404，反之調用Context對應的Valve
StandardContextValve：Context對應的Valve，如果請求路徑以/META-INF/，或者/WEB-INF/開頭，會直接返回404，反之繼續調用Wrapper對應的
StandardWrapperValve：Wrapper對應的Valve，會負責組裝Servlet和Filter，并執行FilterChain#doFilter方法
Filter的匹配主要通過DispatchType和Filter設置的路徑，
在SpringBoot項目中可以使用FilterRegistrationBean#setDispatcherTypes,和addUrlPatterns進行指定。
3.FilterChain執行在Tomcat中ApplicationFilterChain實現了Java Servlet規范中的FilterChain。
其中使用ApplicationFilterConfig是對FilterConfig的實現，內部持有一個Filter。
ApplicationFilterChain包含多個ApplicationFilterConfig，使用數組和pos屬性記錄當前執行到第幾個Filter
Filter都執行結束后，將執行Servlet#service方法
在SpringMVC項目中，會調用到DispatcherServlet#service，最終調用到Controller。
到此這篇關于Tomcat請求處理流程與源碼淺析的文章就介紹到這了,更多相關Tomcat請求處理內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！
網公網安備