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

在大悟等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站建設(shè)、網(wǎng)站設(shè)計 網(wǎng)站設(shè)計制作按需開發(fā)網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè),大悟網(wǎng)站建設(shè)費用合理。

1

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

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

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

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

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

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

2

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

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

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

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

3

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

生產(chǎn)者

消費者

Queue

4

小結(jié)一下：

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

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

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

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