Tomcat請(qǐng)求處理流程與源碼淺析

一丶Connector

在tomcat中，Connector負(fù)責(zé)開(kāi)啟socket并且監(jiān)聽(tīng)客戶(hù)端請(qǐng)求，返回響應(yīng)數(shù)據(jù)。

其中：

• Endpoint：tomcat中沒(méi)有這個(gè)接口，只有AbstractEndpoint,它負(fù)責(zé)啟動(dòng)線程來(lái)監(jiān)聽(tīng)服務(wù)器端口，并且在接受到數(shù)據(jù)后交給Processor處理
• Processor：Processor讀取到客戶(hù)端請(qǐng)求后按照請(qǐng)求地址映射到具體的容器進(jìn)行處理，這個(gè)過(guò)程請(qǐng)求映射，Processor實(shí)現(xiàn)請(qǐng)求映射依賴(lài)于Mapper對(duì)象，在容器發(fā)生注冊(cè)和注銷(xiāo)的時(shí)候，MapperListener會(huì)監(jiān)聽(tīng)到對(duì)應(yīng)的事件，從而來(lái)變更Mapper中維護(hù)的請(qǐng)求映射信息。
• ProtocolHandler：協(xié)議處理器，針對(duì)不同的IO方式（NIO，BIO等）和不同的協(xié)議（Http，AJP）具備不同的實(shí)現(xiàn)，ProtocolHandler包含一個(gè)Endpoint來(lái)開(kāi)啟端口監(jiān)聽(tīng)，并且包含一個(gè)Processor用于按照協(xié)議讀取數(shù)據(jù)并將請(qǐng)求交給容器處理。
• Acceptor：Acceptor實(shí)現(xiàn)了Runnable接口，可以作為一個(gè)線程啟動(dòng)，使用Socket API監(jiān)聽(tīng)指定端口，用于接收用戶(hù)請(qǐng)求。
• Poller：主要用于監(jiān)測(cè)注冊(cè)在原始 scoket 上的事件是否發(fā)生，Acceptor接受到請(qǐng)求后，會(huì)注冊(cè)到Poller的隊(duì)列中。

二丶NioEndpoint 初始化ServerSocketChannel

springboot內(nèi)嵌tomcat，一般默認(rèn)使用NioEndpoint，在NioEndpoint#start方法中，會(huì)觸發(fā)NioEndpoint#bind

三丶NioEndpoint 啟動(dòng)Poller和Acceptor線程

NioEndpoint#start方法最后會(huì)觸發(fā)Poller線程和Acceptor線程的啟動(dòng)

可以看到NioEndpoint內(nèi)部的Poller，和Acceptor都是單獨(dú)使用一個(gè)守護(hù)線程來(lái)運(yùn)行。

四丶Acceptor接收請(qǐng)求

1.endpoint.countUpOrAwaitConnection()限制連接數(shù)

其內(nèi)部使用LimitLatch#countUpOrAwait方法限制連接數(shù)，如果連接數(shù)達(dá)到了上限，那將掛起當(dāng)前線程，也就是掛起Acceptor線程，從而導(dǎo)致無(wú)法有更多的請(qǐng)求連接上來(lái)，最大連接數(shù)默認(rèn)為8*1024。

LimitLatch 內(nèi)部持有一個(gè)AbstractQueuedSynchronizer，限制連接數(shù)將調(diào)用其acquireSharedInterruptibly(1)，然后會(huì)調(diào)用到AQS的tryAcquireShared，其內(nèi)部使用AtomicLong來(lái)進(jìn)行連接的計(jì)數(shù)。

2.NioEndpoint#serverSocketAccept 接收Socket連接

由于NioEndpoint前面調(diào)用了ServerSocketChannel#configureBlocking(true)，所以serverSock#accept，在沒(méi)有連接上來(lái)時(shí)，不會(huì)立馬返回null，而是阻塞直到連接來(lái)到。

3.NioEndpoint#setSocketOptions將SocketChannel注冊(cè)到Poller

在Acceptor線程接收到SocketChannel后，會(huì)調(diào)用Poller#register方法進(jìn)行注冊(cè)，Acceptor只負(fù)責(zé)接受請(qǐng)求，請(qǐng)求后續(xù)的處理由Poller線程負(fù)責(zé)

最終請(qǐng)求被包裝為PollerEvent丟到Poller的事件隊(duì)列SynchronizedQueue中，SynchronizedQueue使用synchronized保證線程安全。

wakeupCounter 是AtomicLong類(lèi)型，Acceptor接受到請(qǐng)求，將請(qǐng)求封裝為PollerEvent后會(huì)調(diào)用wakeupCounter#incrementAndGet方法，進(jìn)行+1操作

Poller在使用Selector，進(jìn)行IO多路復(fù)用的時(shí)候，會(huì)進(jìn)行如下操作

可以看到，如果wakeupCounter大于0,Poller會(huì)調(diào)用 selector.selectNow()（非阻塞立馬返回），反之調(diào)用selector.select(selectorTimeout)(超時(shí)并阻塞)。

也就說(shuō)Acceptor接受到請(qǐng)求越多，wakeupCounter越大，越會(huì)讓Poller調(diào)用selector.selectNow()減少阻塞，從而讓Poller更快的檢查事件是否就緒，從而讓請(qǐng)求更及時(shí)的被處理。

五丶Poller處理事件

1.events方法查看事件隊(duì)列是否具備事件

上面我們說(shuō)到Acceptor在建立連接后，將SocketChannel包裝成NioSocketWrapper塞到了Poller的事件隊(duì)列中。而Poller線程則會(huì)一直輪詢(xún)這個(gè)隊(duì)列進(jìn)行事件的獲取

2.Poller 使用Selector進(jìn)行select

通過(guò)Selector獲取獲取當(dāng)前就緒的IO，keyCount記錄就緒數(shù)目。

3.Poller 處理就緒IO

processKey會(huì)調(diào)用到processSocket，最終使用tomcat線程池中的線程進(jìn)行異步處理

最終會(huì)找到Processor進(jìn)行處理（默認(rèn)使用緩存的，避免重復(fù)new對(duì)象，頻繁gc，如果緩存沒(méi)有那么使用ProtocolHandler 創(chuàng)建出一個(gè)），這里的Processor就是Http11Processor

然后根據(jù)事件類(lèi)型進(jìn)行不同的處理，如果是讀事件那么會(huì)調(diào)用Http11Processor#service進(jìn)行處理，然后會(huì)繼續(xù)交給CoyoteAdapter調(diào)用其service進(jìn)行處理。

六丶CoyoteAdapter處理請(qǐng)求

1.使用Mapper找到請(qǐng)求對(duì)應(yīng)的Host，Context，Wrapper

下圖是的模型，如果使用了SpringMVC，這里的Wrapper會(huì)存在DispatchServlet

如下是Mapper找到的MappingData

2.Pipeline執(zhí)行

上面說(shuō)到，Mapper會(huì)找到當(dāng)前請(qǐng)求所屬的host，context和對(duì)應(yīng)的Wrapper，緊接著會(huì)進(jìn)行Pipeline的執(zhí)行。

為了增強(qiáng)擴(kuò)展性，tomcat定義了Pipeline（管道）和Valve（閥），Pipeline使用職責(zé)鏈的方式串聯(lián)多個(gè)Valve——來(lái)自客戶(hù)端的請(qǐng)求如同流水一樣流淌在管道中，受到每一個(gè)閥的作用。

Pipeline中維護(hù)了基礎(chǔ)的Valve，始終位于Pipeline末端，通過(guò)Pipeline#addValve添加的Valve違約基礎(chǔ)的Valve之前。

在Tomcat中Engine，Host，Context，Wrapper都有對(duì)應(yīng)的Valve實(shí)現(xiàn)，同時(shí)維護(hù)了一個(gè)Pipeline，從而讓我們可以對(duì)請(qǐng)求的處理進(jìn)行擴(kuò)展。

下面是比較重要的Valve

StandardEngineValve ：Engine對(duì)應(yīng)的Valve，負(fù)責(zé)請(qǐng)求是否通過(guò)mapper找到了對(duì)應(yīng)的Host，并觸發(fā)Host對(duì)應(yīng)的Valve

ErrorReportValve： 錯(cuò)誤報(bào)告Valve讓后續(xù)的Valve繼續(xù)執(zhí)行，如果執(zhí)行出現(xiàn)錯(cuò)誤那么會(huì)刷新響應(yīng)流，讓客戶(hù)端收到響應(yīng)

StandardHostValve：Host對(duì)應(yīng)的Valve，如果請(qǐng)求沒(méi)有匹配的context返回404，反之調(diào)用Context對(duì)應(yīng)的Valve

StandardContextValve：Context對(duì)應(yīng)的Valve，如果請(qǐng)求路徑以/META-INF/，或者/WEB-INF/開(kāi)頭，會(huì)直接返回404，反之繼續(xù)調(diào)用Wrapper對(duì)應(yīng)的

StandardWrapperValve：Wrapper對(duì)應(yīng)的Valve，會(huì)負(fù)責(zé)組裝Servlet和Filter，并執(zhí)行FilterChain#doFilter方法

Filter的匹配主要通過(guò)DispatchType和Filter設(shè)置的路徑，

在SpringBoot項(xiàng)目中可以使用FilterRegistrationBean#setDispatcherTypes,和addUrlPatterns進(jìn)行指定。

3.FilterChain執(zhí)行

在Tomcat中ApplicationFilterChain實(shí)現(xiàn)了Java Servlet規(guī)范中的FilterChain。

其中使用ApplicationFilterConfig是對(duì)FilterConfig的實(shí)現(xiàn)，內(nèi)部持有一個(gè)Filter。

ApplicationFilterChain包含多個(gè)ApplicationFilterConfig，使用數(shù)組和pos屬性記錄當(dāng)前執(zhí)行到第幾個(gè)Filter

Filter都執(zhí)行結(jié)束后，將執(zhí)行Servlet#service方法

在SpringMVC項(xiàng)目中，會(huì)調(diào)用到DispatcherServlet#service，最終調(diào)用到Controller。

到此這篇關(guān)于Tomcat請(qǐng)求處理流程與源碼淺析的文章就介紹到這了,更多相關(guān)Tomcat請(qǐng)求處理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！