詳解 Tomcat 的連線數與執行緒池

詩意偶然發表於2017-11-16

前言

在使用tomcat時，經常會遇到連線數、執行緒數之類的配置問題，要真正理解這些概念，必須先了解Tomcat的聯結器（Connector）。

在前面的文章詳解Tomcat配置檔案server.xml 中寫到過：Connector的主要功能，是接收連線請求，建立Request和Response物件用於和請求端交換資料；然後分配執行緒讓Engine（也就是Servlet容器）來處理這個請求，並把產生的Request和Response物件傳給Engine。當Engine處理完請求後，也會通過Connector將響應返回給客戶端。

可以說，Servlet容器處理請求，是需要Connector進行排程和控制的，Connector是Tomcat處理請求的主幹，因此Connector的配置和使用對Tomcat的效能有著重要的影響。這篇文章將從Connector入手，討論一些與Connector有關的重要問題，包括NIO/BIO模式、執行緒池、連線數等。

根據協議的不同，Connector可以分為HTTP Connector、AJP Connector等，本文只討論HTTP Connector。

一、Nio、Bio、APR

1、Connector的protocol

Connector在處理HTTP請求時，會使用不同的protocol。不同的Tomcat版本支援的protocol不同，其中最典型的protocol包括BIO、NIO和APR（Tomcat7中支援這3種，Tomcat8增加了對NIO2的支援，而到了Tomcat8.5和Tomcat9.0，則去掉了對BIO的支援）。

BIO是Blocking IO，顧名思義是阻塞的IO；NIO是Non-blocking IO，則是非阻塞的IO。而APR是Apache Portable Runtime，是Apache可移植執行庫，利用本地庫可以實現高可擴充套件性、高效能；Apr是在Tomcat上執行高併發應用的首選模式，但是需要安裝apr、apr-utils、tomcat-native等包。學習交流群：521479582

2、如何指定protocol

Connector使用哪種protocol，可以通過元素中的protocol屬性進行指定，也可以使用預設值。

指定的protocol取值及對應的協議如下：

HTTP/1.1：預設值，使用的協議與Tomcat版本有關
org.apache.coyote.http11.Http11Protocol：BIO
org.apache.coyote.http11.Http11NioProtocol：NIO
org.apache.coyote.http11.Http11Nio2Protocol：NIO2
org.apache.coyote.http11.Http11AprProtocol：APR

如果沒有指定protocol，則使用預設值HTTP/1.1，其含義如下：在Tomcat7中，自動選取使用BIO或APR（如果找到APR需要的本地庫，則使用APR，否則使用BIO）；在Tomcat8中，自動選取使用NIO或APR（如果找到APR需要的本地庫，則使用APR，否則使用NIO）。

3、BIO/NIO有何不同

無論是BIO，還是NIO，Connector處理請求的大致流程是一樣的：

在accept佇列中接收連線（當客戶端向伺服器傳送請求時，如果客戶端與OS完成三次握手建立了連線，則OS將該連線放入accept佇列）；在連線中獲取請求的資料，生成request；呼叫servlet容器處理請求；返回response。為了便於後面的說明，首先明確一下連線與請求的關係：連線是TCP層面的（傳輸層），對應socket；請求是HTTP層面的（應用層），必須依賴於TCP的連線實現；一個TCP連線中可能傳輸多個HTTP請求。

在BIO實現的Connector中，處理請求的主要實體是JIoEndpoint物件。JIoEndpoint維護了Acceptor和Worker：Acceptor接收socket，然後從Worker執行緒池中找出空閒的執行緒處理socket，如果worker執行緒池沒有空閒執行緒，則Acceptor將阻塞。其中Worker是Tomcat自帶的執行緒池，如果通過配置了其他執行緒池，原理與Worker類似。

在NIO實現的Connector中，處理請求的主要實體是NIoEndpoint物件。NIoEndpoint中除了包含Acceptor和Worker外，還是用了Poller，處理流程如下圖所示（圖片來源：gearever.iteye.com/blog/184420…

Acceptor接收socket後，不是直接使用Worker中的執行緒處理請求，而是先將請求傳送給了Poller，而Poller是實現NIO的關鍵。Acceptor向Poller傳送請求通過佇列實現，使用了典型的生產者-消費者模式。在Poller中，維護了一個Selector物件；當Poller從佇列中取出socket後，註冊到該Selector中；然後通過遍歷Selector，找出其中可讀的socket，並使用Worker中的執行緒處理相應請求。與BIO類似，Worker也可以被自定義的執行緒池代替。學習交流群：521479582。

通過上述過程可以看出，在NIoEndpoint處理請求的過程中，無論是Acceptor接收socket，還是執行緒處理請求，使用的仍然是阻塞方式；但在“讀取socket並交給Worker中的執行緒”的這個過程中，使用非阻塞的NIO實現，這是NIO模式與BIO模式的最主要區別（其他區別對效能影響較小，暫時略去不提）。而這個區別，在併發量較大的情形下可以帶來Tomcat效率的顯著提升：

目前大多數HTTP請求使用的是長連線（HTTP/1.1預設keep-alive為true），而長連線意味著，一個TCP的socket在當前請求結束後，如果沒有新的請求到來，socket不會立馬釋放，而是等timeout後再釋放。如果使用BIO，“讀取socket並交給Worker中的執行緒”這個過程是阻塞的，也就意味著在socket等待下一個請求或等待釋放的過程中，處理這個socket的工作執行緒會一直被佔用，無法釋放；因此Tomcat可以同時處理的socket數目不能超過最大執行緒數，效能受到了極大限制。而使用NIO，“讀取socket並交給Worker中的執行緒”這個過程是非阻塞的，當socket在等待下一個請求或等待釋放時，並不會佔用工作執行緒，因此Tomcat可以同時處理的socket數目遠大於最大執行緒數，併發效能大大提高。

二、3個引數：acceptCount、maxConnections、maxThreads

再回顧一下Tomcat處理請求的過程：在accept佇列中接收連線（當客戶端向伺服器傳送請求時，如果客戶端與OS完成三次握手建立了連線，則OS將該連線放入accept佇列）；在連線中獲取請求的資料，生成request；呼叫servlet容器處理請求；返回response。

相對應的，Connector中的幾個引數功能如下：

1、acceptCount

accept佇列的長度；當accept佇列中連線的個數達到acceptCount時，佇列滿，進來的請求一律被拒絕。預設值是100。

2、maxConnections

Tomcat在任意時刻接收和處理的最大連線數。當Tomcat接收的連線數達到maxConnections時，Acceptor執行緒不會讀取accept佇列中的連線；這時accept佇列中的執行緒會一直阻塞著，直到Tomcat接收的連線數小於maxConnections。如果設定為-1，則連線數不受限制。

預設值與聯結器使用的協議有關：NIO的預設值是10000，APR/native的預設值是8192，而BIO的預設值為maxThreads（如果配置了Executor，則預設值是Executor的maxThreads）。

在windows下，APR/native的maxConnections值會自動調整為設定值以下最大的1024的整數倍；如設定為2000，則最大值實際是1024。

3、maxThreads

請求處理執行緒的最大數量。預設值是200（Tomcat7和8都是的）。如果該Connector繫結了Executor，這個值會被忽略，因為該Connector將使用繫結的Executor，而不是內建的執行緒池來執行任務。

maxThreads規定的是最大的執行緒數目，並不是實際running的CPU數量；實際上，maxThreads的大小比CPU核心數量要大得多。這是因為，處理請求的執行緒真正用於計算的時間可能很少，大多數時間可能在阻塞，如等待資料庫返回資料、等待硬碟讀寫資料等。因此，在某一時刻，只有少數的執行緒真正的在使用物理CPU，大多數執行緒都在等待；因此執行緒數遠大於物理核心數才是合理的。

換句話說，Tomcat通過使用比CPU核心數量多得多的執行緒數，可以使CPU忙碌起來，大大提高CPU的利用率。

4、引數設定

（1）maxThreads的設定既與應用的特點有關，也與伺服器的CPU核心數量有關。通過前面介紹可以知道，maxThreads數量應該遠大於CPU核心數量；而且CPU核心數越大，maxThreads應該越大；應用中CPU越不密集（IO越密集），maxThreads應該越大，以便能夠充分利用CPU。當然，maxThreads的值並不是越大越好，如果maxThreads過大，那麼CPU會花費大量的時間用於執行緒的切換，整體效率會降低。

（2）maxConnections的設定與Tomcat的執行模式有關。如果tomcat使用的是BIO，那麼maxConnections的值應該與maxThreads一致；如果tomcat使用的是NIO，那麼類似於Tomcat的預設值，maxConnections值應該遠大於maxThreads。

（3）通過前面的介紹可以知道，雖然tomcat同時可以處理的連線數目是maxConnections，但伺服器中可以同時接收的連線數為maxConnections+acceptCount 。acceptCount的設定，與應用在連線過高情況下希望做出什麼反應有關係。如果設定過大，後面進入的請求等待時間會很長；如果設定過小，後面進入的請求立馬返回connection refused。

三、執行緒池Executor

Executor元素代表Tomcat中的執行緒池，可以由其他元件共享使用；要使用該執行緒池，元件需要通過executor屬性指定該執行緒池。

Executor是Service元素的內嵌元素。一般來說，使用執行緒池的是Connector元件；為了使Connector能使用執行緒池，Executor元素應該放在Connector前面。Executor與Connector的配置舉例如下：

Executor的主要屬性包括：

name：該執行緒池的標記
maxThreads：執行緒池中最大活躍執行緒數，預設值200（Tomcat7和8都是）
minSpareThreads：執行緒池中保持的最小執行緒數，最小值是25
maxIdleTime：執行緒空閒的最大時間，當空閒超過該值時關閉執行緒（除非執行緒數小於minSpareThreads），單位是ms，預設值60000（1分鐘）
daemon：是否後臺執行緒，預設值true
threadPriority：執行緒優先順序，預設值5
namePrefix：執行緒名字的字首，執行緒池中執行緒名字為：namePrefix+執行緒編號

四、檢視當前狀態

上面介紹了Tomcat連線數、執行緒數的概念以及如何設定，下面說明如何檢視伺服器中的連線數和執行緒數。

檢視伺服器的狀態，大致分為兩種方案：（1）使用現成的工具，（2）直接使用Linux的命令檢視。

現成的工具，如JDK自帶的jconsole工具可以方便的檢視執行緒資訊（此外還可以檢視CPU、記憶體、類、JVM基本資訊等），Tomcat自帶的manager，收費工具New Relic等。下圖是jconsole檢視執行緒資訊的介面：