在使用tomcat時，經常會遇到連接配接數、線程數之類的配置問題，要真正了解這些概念，必須先了解Tomcat的連接配接器（Connector）。
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
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等包。
Connector使用哪種protocol，可以通過<connector>元素中的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）。
無論是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自帶的線程池，如果通過<Executor>配置了其他線程池，原理與Worker類似。
在NIO實作的Connector中，處理請求的主要實體是NIoEndpoint對象。NIoEndpoint中除了包含Acceptor和Worker外，還是用了Poller，處理流程如下圖所示（圖檔來源：http://gearever.iteye.com/blog/1844203）。
Acceptor接收socket後，不是直接使用Worker中的線程處理請求，而是先将請求發送給了Poller，而Poller是實作NIO的關鍵。Acceptor向Poller發送請求通過隊列實作，使用了典型的生産者-消費者模式。在Poller中，維護了一個Selector對象；當Poller從隊列中取出socket後，注冊到該Selector中；然後通過周遊Selector，找出其中可讀的socket，并使用Worker中的線程處理相應請求。與BIO類似，Worker也可以被自定義的線程池代替。
通過上述過程可以看出，在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中的幾個參數功能如下：
accept隊列的長度；當accept隊列中連接配接的個數達到acceptCount時，隊列滿，進來的請求一律被拒絕。預設值是100。
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。
請求處理線程的最大數量。預設值是200（Tomcat7和8都是的）。如果該Connector綁定了Executor，這個值會被忽略，因為該Connector将使用綁定的Executor，而不是内置的線程池來執行任務。
maxThreads規定的是最大的線程數目，并不是實際running的CPU數量；實際上，maxThreads的大小比CPU核心數量要大得多。這是因為，處理請求的線程真正用于計算的時間可能很少，大多數時間可能在阻塞，如等待資料庫傳回資料、等待硬碟讀寫資料等。是以，在某一時刻，隻有少數的線程真正的在使用實體CPU，大多數線程都在等待；是以線程數遠大于實體核心數才是合理的。
換句話說，Tomcat通過使用比CPU核心數量多得多的線程數，可以使CPU忙碌起來，大大提高CPU的使用率。
（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檢視線程資訊的界面：
下面說一下如何通過Linux指令行，檢視伺服器中的連接配接數和線程數。
假設Tomcat接收http請求的端口是8083，則可以使用如下語句檢視連接配接情況：
結果如下所示：
可以看出，有一個連接配接處于listen狀态，監聽請求；除此之外，還有4個已經建立的連接配接（ESTABLISHED）和2個等待關閉的連接配接（CLOSE_WAIT）。
ps指令可以檢視程序狀态，如執行如下指令：
結果如下圖：
可以看到，隻列印了一個程序的資訊；27989是線程id，java是指執行的java指令。這是因為啟動一個tomcat，内部所有的工作都在這一個程序裡完成，包括主線程、垃圾回收線程、Acceptor線程、請求處理線程等等。
通過如下指令，可以看到該程序内有多少個線程；其中，nlwp含義是number of light-weight process。
可以看到，該程序内部有73個線程；但是73并沒有排除處于idle狀态的線程。要想獲得真正在running的線程數量，可以通過以下語句完成：
其中ps -eLo pid ,stat可以找出所有線程，并列印其所在的程序号和線程目前的狀态；兩個grep指令分别篩選程序号和線程狀态；wc統計個數。其中，ps -eLo pid ,stat | grep 27989輸出的結果如下：
圖中隻截圖了部分結果；Sl表示大多數線程都處于空閑狀态。