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