如何理解Tomcat高并發(fā)之連接池、線程池

本篇內(nèi)容介紹了“如何理解Tomcat高并發(fā)之連接池、線程池”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

1

Tomcat處理用戶請(qǐng)求的入口組件叫做Connector，其有兩個(gè)主要的實(shí)現(xiàn)：BIO（blocking io）和NIO（non-blocking io）。

簡(jiǎn)單講，BIO的實(shí)現(xiàn)就是對(duì)上面多線程版本的一個(gè)改進(jìn)，主要點(diǎn)在于把“每來一個(gè)連接啟動(dòng)一個(gè)線程處理”改成“每來一個(gè)連接都提交給線程池處理”。雖然線程池根據(jù)不同的配置，其工作行為會(huì)有所不同，但一般來講，使用線程池的原則是：只需創(chuàng)建少量的線程就可以完成大量任務(wù)的執(zhí)行，由于同時(shí)至多只有固定量的線程執(zhí)行，剩余的任務(wù)會(huì)被放進(jìn)queue里面緩沖起來，從這個(gè)角度看，這是一個(gè)典型的生產(chǎn)者-消費(fèi)者模型。回到tomcat BIO，acceptor不斷的接收連接，然后提交給線程池執(zhí)行，acceptor就是生產(chǎn)者；線程池的每一個(gè)線程就是消費(fèi)者，負(fù)責(zé)處理請(qǐng)求。

由于socket連接是長(zhǎng)連接，連接的創(chuàng)建銷毀也是很耗資源的，于是http協(xié)議增加了一個(gè)keep-alive header，這個(gè)header的意思是提示服務(wù)器端，在返回http response之后，不要斷開socket，繼續(xù)處理后續(xù)http請(qǐng)求，這樣做的目的就是為了提高資源的可重用性。那么，對(duì)于tomcat BIO的實(shí)現(xiàn)，在keep-alive場(chǎng)景下，會(huì)有什么問題呢？如果一個(gè)線程處理的socket需要保持keep-alive，其在執(zhí)行完一個(gè)http請(qǐng)求之后，需要阻塞在那里以等待下一個(gè)http請(qǐng)求，不能馬上結(jié)束（直到timeout）；在某些情況下，這樣就可能存在大量的阻塞線程，新的連接不能被處理。

基于此，NIO就可以解決這個(gè)問題。NIO和BIO在請(qǐng)求處理部分的實(shí)現(xiàn)是一致的，都是基于線程池；不同的地方是：NIO的acceptor基于jdk nio實(shí)現(xiàn)，在收到一個(gè)連接之后，會(huì)把socketChannel注冊(cè)到poller的selector上面，當(dāng)socketChannel有數(shù)據(jù)可讀時(shí)，poller就把此連接提交給線程池處理?；氐缴厦鎘eep-alive的場(chǎng)景，當(dāng)一個(gè)線程處理完一個(gè)http請(qǐng)求之后，就可以馬上結(jié)束，當(dāng)前連接則回到selector繼續(xù)監(jiān)聽接下來的http請(qǐng)求。所以，基于NIO的執(zhí)行線程就不會(huì)出現(xiàn)基于BIO的阻塞情況。

NIO的核心在于selector，selector可以識(shí)別到已經(jīng)ready的連接和沒有ready的連接；在之前的一篇多線程文章（對(duì)比Java和.NET多線程編程）里面提到過，jdk的concurrency API有一個(gè)CompletionService類，就有點(diǎn)類似于nio的原理。

由于NIO天生的優(yōu)勢(shì)，tomcat從8.0版本開始就把NIO設(shè)成默認(rèn)的Connector，而從8.5版本開始直接就把BIO去掉了。

2

在tomcat的官網(wǎng)有下面一段關(guān)于如何高并發(fā)處理請(qǐng)求的描述：

Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute). If still more simultaneous requests are received, they are stacked up inside the server socket created by the Connector, up to the configured maximum (the value of the acceptCount attribute). Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them.

- https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

個(gè)人覺得其沒有反映出maxConnections這個(gè)參數(shù)的作用，所以應(yīng)該是：如果maxConnections小于maxThreads，最大創(chuàng)建的線程數(shù)就是maxConnections的值，最大連接數(shù)也是maxConnections的值；但是如果maxConnections大于maxThreads，最大創(chuàng)建的線程數(shù)就是maxThreads的值，最大連接數(shù)則是maxConnections的值。

由于BIO和NIO底層實(shí)現(xiàn)的區(qū)別，配置maxConnections的值也需要區(qū)別考慮，這在maxConnections的默認(rèn)值中就有所體現(xiàn)（對(duì)于BIO，maxConnections的默認(rèn)值是maxThreads的值；而對(duì)于NIO，maxConnections的默認(rèn)值則是10000）：

3

上面有提到，tomcat接收處理請(qǐng)求的過程其實(shí)就是一個(gè)生產(chǎn)者-消費(fèi)者模型，影響tomcat高并發(fā)的配置也可以首先分別從這兩個(gè)方面考慮：

生產(chǎn)者

消費(fèi)者

Queue

4

小結(jié)一下：

• 線程池的本質(zhì)就是節(jié)省了不斷創(chuàng)建銷毀線程的開銷；加上queue的使用，增加了一層緩沖，一定程度緩解了計(jì)算機(jī)的壓力。當(dāng)然線程池的配置，需要根據(jù)要處理的任務(wù)（CPU密集型還是io密集型）來仔細(xì)的考慮。

• Tomcat里面BIO和NIO的最大區(qū)別在于讀取下一個(gè)請(qǐng)求時(shí)是否需要阻塞，這對(duì)于keep-alive的場(chǎng)景尤其重要，NIO可以大大提高吞吐量。

• 基于queue的生成者-消費(fèi)者模型，也常常應(yīng)用在系統(tǒng)架構(gòu)層面，以緩沖生產(chǎn)者和消費(fèi)者之間處理速度的gap，比如秒殺系統(tǒng)。
  

“如何理解Tomcat高并發(fā)之連接池、線程池”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！