Tomcat入门
1.Tomcat基礎入門
1.1 tomcat是什么
Tomcat 是由 Apache 開發的一個 Servlet 容器，實現了對 Servlet 和 JSP 的支持，并提供了作為Web服務器的一些特有功能，如Tomcat管理和控制平臺、安全域管理和Tomcat閥等。
由于 Tomcat 本身也內含了一個 HTTP 服務器，它也可以被視作一個單獨的 Web 服務器
1.2 基礎目錄
-
/bin - Tomcat 腳本存放目錄（如啟動、關閉腳本）。 *.sh 文件用于 Unix 系統； *.bat 文件用于 Windows 系統。
-
/conf - Tomcat 配置文件目錄。
-
/logs - Tomcat 默認日志目錄。
-
/webapps - webapp 運行的目錄。在手動拷貝war包到此目錄下啟動時，war包的名稱就是啟動項目的上下文
|-- webapp # 站點根目錄 META-INF 目錄用于存放工程自身相關的一些信息，元文件信息，通常由開發工具，環境自動生成。|-- META-INF # META-INF 目錄| `-- MANIFEST.MF # 配置清單文件|-- WEB-INF # WEB-INF 目錄| |-- classes # class文件目錄| | |-- *.class # 程序需要的 class 文件| | `-- *.xml # 程序需要的 xml 文件| |-- lib # 庫文件夾| | `-- *.jar # 程序需要的 jar 包
1.3 安裝
-
window安裝：tomcat8.5要求JDK1.7以上，進入tomcat官方網站下載，解壓到本地即可使用。
-
linux安裝
# 下載解壓到本地wget http://mirrors.hust.edu.cn/apache/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gztar -zxf apache-tomcat-8.5.24.tar.gz# 啟動 Tomcat./apache-tomcat-8.5.24/bin/startup.sh
啟動后，訪問 http://localhost:8080 ，可以看到 Tomcat 安裝成功的測試頁面
1.4 配置文件解析
./conf/servre.xml是tomcat的主要配置文件，下面對里面的一些主要配置進行解釋：
-
server
server 元素表示整個 Catalina servlet 容器。因此，它必須是 conf/server.xml 配置文件中的根元素。它的屬性代表了整個 servlet 容器的特性。| 屬性 | 描述 | 備注 |
| :------| ------: | :------: |
| className | 這個類必須實現org.apache.catalina.Service接口 | 默認 org.apache.catalina.core.StandardService |
| address | 服務器等待關機命令的TCP / IP地址。如果沒有指定地址，則使用localhost。 | |
| port | 服務器等待關機命令的TCP / IP端口號。設置為-1以禁用關閉端口。|
| shutdown | 必須通過TCP / IP連接接收到指定端口號的命令字符串，以關閉Tomcat| -
service
Service元素表示一個或多個連接器組件的組合，這些組件共享一個用于處理傳入請求的引擎組件。Server 中可以有多個 Service。
其中name表示此服務的顯示名稱，如果您使用標準 Catalina 組件，將包含在日志消息中。與特定服務器關聯的每個服務的名稱必須是唯一的。
- Executor
表示在Tomcat中組件之間共享的線程池。
| className | 這個類必須實現org.apache.catalina.Executor接口 | 默認 org.apache.catalina.core.StandardService |
| name | 線程池名稱 | 要求唯一, 供Connector元素的executor屬性使用 |
| namePrefix | 線程名稱前綴 | |
| maxThreads | 最大活躍線程數 | 默認200 |
| minSpareThreads | 最小活躍線程數 | 默認25 |
| maxIdleTime | 當前活躍線程大于minSpareThreads時,空閑線程關閉的等待最大時間 | 默認60000ms |
| maxQueueSize | 線程池滿情況下的請求排隊大小 | 默認Integer.MAX_VALUE |
- connector
Connector代表連接組件。Tomcat 支持三種協議：HTTP/1.1、HTTP/2.0、AJP。
| asyncTimeout | Servlet3.0規范中的異步請求超時 | 默認30s |
| port | 請求連接的TCP Port | 設置為0,則會隨機選取一個未占用的端口號 |
| protocol | 協議. 一般情況下設置為 HTTP/1.1,這種情況下連接模型會在NIO和APR/native中自動根據配置選擇 | |
| URIEncoding | 對URI的編碼方式 | 如果設置系統變量org.apache.catalina.STRICT_SERVLET_COMPLIANCE為true,使用 ISO-8859-1編碼;如果未設置此系統變量且未設置此屬性, 使用UTF-8編碼 |
| useBodyEncodingForURI | 是否采用指定的contentType而不是URIEncoding來編碼URI中的請求參數 |
以下屬性在標準的Connector(NIO, NIO2 和 APR/native)中有效:
| acceptCount | 當最大請求連接maxConnections滿時的最大排隊大小 | 默認100,注意此屬性和Executor中屬性maxQueueSize的區別.這個指的是請求連接滿時的堆棧大小,Executor的maxQueueSize指的是處理線程滿時的堆棧大小 |
| connectionTimeout | 請求連接超時 | 默認60000ms |
| executor | 指定配置的線程池名稱 | |
| keepAliveTimeout | keeAlive超時時間 | 默認值為connectionTimeout配置值.-1表示不超時 |
| maxConnections | 最大連接數 | 連接滿時后續連接放入最大為acceptCount的隊列中. 對 NIO和NIO2連接,默認值為10000;對 APR/native,默認值為8192 |
| maxThreads | 如果指定了Executor, 此屬性忽略;否則為Connector創建的內部線程池最大值 | 默認200 |
| minSpareThreads | 如果指定了Executor, 此屬性忽略;否則為Connector創建線程池的最小活躍線程數 | 默認10 |
| processorCache | 協議處理器緩存Processor對象的大小 | -1表示不限制.當不使用servlet3.0的異步處理情況下: 如果配置Executor,配置為Executor的maxThreads;否則配置為Connnector的maxThreads. 如果使用Serlvet3.0異步處理, 取maxThreads和maxConnections的最大值 |
1.5 開啟遠程調試模式
我們常常會遇到，本地項目運行一切正常，在測試服務器上出問題，可是日志信息并不能方便的查看出原因。我們可以通過遠程調試模式來查看項目運行信息。現在介紹在tomcat8.5下的開啟遠程調試方式：
- 1.5.1 tomcat開啟遠程調試模式
開啟遠程調試模式需要JDPA方式啟動tomcat，tomcat8.5已經添加JDPA的配置
如圖，默認端口為8000，且只能在本機進行調試，我們可以去掉localhost和修改需要的端口號。
然后在bin目錄下修改startup.bat文件，在最后一行添加jdpa
然后雙擊startup.bat啟動tomcat即可。
- 1.5.2 客戶端遠程連接
我們打開IDE開發工具，選擇remote連接
，然后填寫連接信息即可。
端口號即為上面配置的JPDA_ADDRESS，然后debug啟動，控制臺打印以下信息，說明連接成功。
接下來就可以愉快的打斷點進行調試了。
問題：其中tomcat7需要手動添加JPDA_OPTS設置，非tomcat8.5版本開啟遠程調試模式會與本文有所不同。
還有在idea中通過配置tomcat啟動項目時，無法正確的連接，暫時還沒找到原因，只能通過bin目錄手動雙擊startup.bat啟動tomcat。
1.6 將tomcat注冊成window服務
1.7 tomcat調優
通常tomcat的默認配置在生產環境下不能滿足要求，我們需要修改配置提高性能和穩定性，可以通過以下幾種方式：
1.7.1 修改JVM參數
Tomcat 啟動命令行中的優化參數，就是 JVM 的優化 。Tomcat 首先跑在 JVM 之上的，因為它的啟動其實也只是一個 java 命令行，首先我們需要對這個 JAVA 的啟動命令行進行調優。不管是 YGC 還是 Full GC，GC 過程中都會對導致程序運行中中斷，正確的選擇不同的 GC 策略，調整 JVM、GC 的參數，可以極大的減少由于 GC 工作，而導致的程序運行中斷方面的問題，進而適當的提高 Java 程序的工作效率。
Tomcat 的啟動參數位于安裝目錄 ${JAVA_HOME}/bin目錄下，Linux 操作系統就是 catalina.sh 文件。JAVA_OPTS，就是用來設置 JVM 相關運行參數的變量，還可以在 CATALINA_OPTS 變量中設置。關于這 2 個變量，還是多少有些區別的：
JAVA_OPTS：用于當 Java 運行時選項“start”、“stop”或“run”命令執行。
CATALINA_OPTS：用于當 Java 運行時選項“start”或“run”命令執行。
為什么有兩個不同的變量？它們之間都有什么區別呢？
首先，在啟動 Tomcat 時，任何指定變量的傳遞方式都是相同的，可以傳遞到執行“start”或“run”命令中，但只有設定在 JAVA_OPTS 變量里的參數被傳遞到“stop”命令中。對于 Tomcat 運行過程，可能沒什么區別，影響的是結束程序，而不是啟動程序。
第二個區別是更微妙，其他應用程序也可以使用 JAVA_OPTS 變量，但只有在 Tomcat 中使用 CATALINA_OPTS 變量。如果你設置環境變量為只使用 Tomcat，最好你會建議使用 CATALINA_OPTS 變量，而如果你設置環境變量使用其它的 Java 應用程序，例如 JBoss，你應該把你的設置放在JAVA_OPTS 變量中。
32 位系統下 JVM 對內存的限制：不能突破 2GB ，那么這時你的 Tomcat 要優化，就要講究點技巧了，而在 64 位操作系統上無論是系統內存還是 JVM 都沒有受到 2GB 這樣的限制。
針對于 JMX 遠程監控也是在這里設置，以下為 64 位系統環境下的配置，內存加入的參數如下：
CATALINA_OPTS=" -server -Xms6000M -Xmx6000M -Xss512k -XX:NewSize=2250M -XX:MaxNewSize=2250M -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=31 -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Duser.timezone=Asia/Shanghai -Djava.awt.headless=true"為了看著方便，將每個參數單獨寫一行。上面參數好多啊，可能有人寫到現在都沒見過一個在 Tomcat 的啟動命令里加了這么多參數，當然，這些參數只是我機器上的，不一定適合你，尤其是參數后的 value（值）是需要根據你自己的實際情況來設置的。
上述這樣的配置，基本上可以達到：
系統響應時間增快；
JVM回收速度增快同時又不影響系統的響應率；
JVM內存最大化利用；
線程阻塞情況最小化。
JVM 常用參數詳解：
-server：一定要作為第一個參數，在多個 CPU 時性能佳，還有一種叫 -client 的模式，特點是啟動速度比較快，但運行時性能和內存管理效率不高，通常用于客戶端應用程序或開發調試，在 32 位環境下直接運行 Java 程序默認啟用該模式。Server 模式的特點是啟動速度比較慢，但運行時性能和內存管理效率很高，適用于生產環境，在具有 64 位能力的 JDK 環境下默認啟用該模式，可以不配置該參數。
-Xms：表示 Java 初始化堆的大小，-Xms 與-Xmx 設成一樣的值，避免 JVM 反復重新申請內存，導致性能大起大落，默認值為物理內存的 1/64，默認（MinHeapFreeRatio參數可以調整）空余堆內存小于 40% 時，JVM 就會增大堆直到 -Xmx 的最大限制。
-Xmx：表示最大 Java 堆大小，當應用程序需要的內存超出堆的最大值時虛擬機就會提示內存溢出，并且導致應用服務崩潰，因此一般建議堆的最大值設置為可用內存的最大值的80%。如何知道我的 JVM 能夠使用最大值，使用 java -Xmx512M -version 命令來進行測試，然后逐漸的增大 512 的值,如果執行正常就表示指定的內存大小可用，否則會打印錯誤信息，默認值為物理內存的 1/4，默認（MinHeapFreeRatio參數可以調整）空余堆內存大于 70% 時，JVM 會減少堆直到-Xms 的最小限制。
-Xss：表示每個 Java 線程堆棧大小，JDK 5.0 以后每個線程堆棧大小為 1M，以前每個線程堆棧大小為 256K。根據應用的線程所需內存大小進行調整，在相同物理內存下，減小這個值能生成更多的線程，但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在 3000~5000 左右。一般小的應用， 如果棧不是很深， 應該是128k 夠用的，大的應用建議使用 256k 或 512K，一般不易設置超過 1M，要不然容易出現out ofmemory。這個選項對性能影響比較大，需要嚴格的測試。
-XX:NewSize：設置新生代內存大小。
-XX:MaxNewSize：設置最大新生代新生代內存大小
-XX:PermSize：設置持久代內存大小
-XX:MaxPermSize：設置最大值持久代內存大小，永久代不屬于堆內存，堆內存只包含新生代和老年代。
-XX:+AggressiveOpts：作用如其名（aggressive），啟用這個參數，則每當 JDK 版本升級時，你的 JVM 都會使用最新加入的優化技術（如果有的話）。
-XX:+UseBiasedLocking：啟用一個優化了的線程鎖，我們知道在我們的appserver，每個http請求就是一個線程，有的請求短有的請求長，就會有請求排隊的現象，甚至還會出現線程阻塞，這個優化了的線程鎖使得你的appserver內對線程處理自動進行最優調配。
-XX:+DisableExplicitGC：在 程序代碼中不允許有顯示的調用“System.gc()”。每次在到操作結束時手動調用 System.gc() 一下，付出的代價就是系統響應時間嚴重降低，就和關于 Xms，Xmx 里的解釋的原理一樣，這樣去調用 GC 導致系統的 JVM 大起大落。
-XX:+UseConcMarkSweepGC：設置年老代為并發收集，即 CMS gc，這一特性只有 jdk1.5
后續版本才具有的功能，它使用的是 gc 估算觸發和 heap 占用觸發。我們知道頻頻繁的 GC 會造面 JVM
的大起大落從而影響到系統的效率，因此使用了 CMS GC 后可以在 GC 次數增多的情況下，每次 GC 的響應時間卻很短，比如說使用了 CMS
GC 后經過 jprofiler 的觀察，GC 被觸發次數非常多，而每次 GC 耗時僅為幾毫秒。
-XX:+UseParNewGC：對新生代采用多線程并行回收，這樣收得快，注意最新的 JVM 版本，當使用 -XX:+UseConcMarkSweepGC 時，-XX:UseParNewGC 會自動開啟。因此，如果年輕代的并行 GC 不想開啟，可以通過設置 -XX：-UseParNewGC 來關掉。
-XX:MaxTenuringThreshold：設置垃圾最大年齡。如果設置為0的話，則新生代對象不經過 Survivor 區，直接進入老年代。對于老年代比較多的應用（需要大量常駐內存的應用），可以提高效率。如果將此值設置為一 個較大值，則新生代對象會在 Survivor 區進行多次復制，這樣可以增加對象在新生代的存活時間，增加在新生代即被回收的概率，減少Full GC的頻率，這樣做可以在某種程度上提高服務穩定性。該參數只有在串行 GC 時才有效，這個值的設置是根據本地的 jprofiler 監控后得到的一個理想的值，不能一概而論原搬照抄。
-XX:+CMSParallelRemarkEnabled：在使用 UseParNewGC 的情況下，盡量減少 mark 的時間。
-XX:+UseCMSCompactAtFullCollection：在使用 concurrent gc 的情況下，防止 memoryfragmention，對 live object 進行整理，使 memory 碎片減少。
-XX:LargePageSizeInBytes：指定 Java heap 的分頁頁面大小，內存頁的大小不可設置過大， 會影響 Perm 的大小。
-XX:+UseFastAccessorMethods：使用 get，set 方法轉成本地代碼，原始類型的快速優化。
-XX:+UseCMSInitiatingOccupancyOnly：只有在 oldgeneration 在使用了初始化的比例后 concurrent collector 啟動收集。
-Duser.timezone=Asia/Shanghai：設置用戶所在時區。
-Djava.awt.headless=true：這個參數一般我們都是放在最后使用的，這全參數的作用是這樣的，有時我們會在我們的 J2EE 工程中使用一些圖表工具如：jfreechart，用于在 web 網頁輸出 GIF/JPG 等流，在 winodws 環境下，一般我們的 app server 在輸出圖形時不會碰到什么問題，但是在linux/unix 環境下經常會碰到一個 exception 導致你在 winodws 開發環境下圖片顯示的好好可是在 linux/unix 下卻顯示不出來，因此加上這個參數以免避這樣的情況出現。
-Xmn：新生代的內存空間大小，注意：此處的大小是（eden+ 2 survivor space)。與 jmap -heap 中顯示的 New gen 是不同的。整個堆大小 = 新生代大小 + 老生代大小 + 永久代大小。在保證堆大小不變的情況下，增大新生代后，將會減小老生代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的 3/8。
-XX:CMSInitiatingOccupancyFraction：當堆滿之后，并行收集器便開始進行垃圾收集，例如，當沒有足夠的空間來容納新分配或提升的對象。對于 CMS 收集器，長時間等待是不可取的，因為在并發垃圾收集期間應用持續在運行（并且分配對象）。因此，為了在應用程序使用完內存之前完成垃圾收集周期，CMS 收集器要比并行收集器更先啟動。因為不同的應用會有不同對象分配模式，JVM 會收集實際的對象分配（和釋放）的運行時數據，并且分析這些數據，來決定什么時候啟動一次 CMS 垃圾收集周期。這個參數設置有很大技巧，基本上滿足(Xmx-Xmn)(100-CMSInitiatingOccupancyFraction)/100 >= Xmn 就不會出現 promotion failed。例如在應用中 Xmx 是6000，Xmn 是 512，那么 Xmx-Xmn 是 5488M，也就是老年代有 5488M，CMSInitiatingOccupancyFraction=90 說明老年代到 90% 滿的時候開始執行對老年代的并發垃圾回收（CMS），這時還 剩 10% 的空間是 548810% = 548M，所以即使 Xmn（也就是新生代共512M）里所有對象都搬到老年代里，548M 的空間也足夠了，所以只要滿足上面的公式，就不會出現垃圾回收時的 promotion failed，因此這個參數的設置必須與 Xmn 關聯在一起。
-XX:+CMSIncrementalMode：該標志將開啟 CMS 收集器的增量模式。增量模式經常暫停 CMS 過程，以便對應用程序線程作出完全的讓步。因此，收集器將花更長的時間完成整個收集周期。因此，只有通過測試后發現正常 CMS 周期對應用程序線程干擾太大時，才應該使用增量模式。由于現代服務器有足夠的處理器來適應并發的垃圾收集，所以這種情況發生得很少，用于但 CPU情況。
-XX:NewRatio：年輕代（包括 Eden 和兩個 Survivor 區）與年老代的比值（除去持久代），-XX:NewRatio=4 表示年輕代與年老代所占比值為 1:4，年輕代占整個堆棧的 1/5，Xms=Xmx 并且設置了 Xmn 的情況下，該參數不需要進行設置。
-XX:SurvivorRatio：Eden 區與 Survivor 區的大小比值，設置為 8，表示 2 個 Survivor 區（JVM 堆內存年輕代中默認有 2 個大小相等的 Survivor 區）與 1 個 Eden 區的比值為 2:8，即 1 個 Survivor 區占整個年輕代大小的 1/10。
-XX:+UseSerialGC：設置串行收集器。
-XX:+UseParallelGC：設置為并行收集器。此配置僅對年輕代有效。即年輕代使用并行收集，而年老代仍使用串行收集。
-XX:+UseParallelOldGC：配置年老代垃圾收集方式為并行收集，JDK6.0 開始支持對年老代并行收集。
-XX:ConcGCThreads：早期 JVM 版本也叫-XX:ParallelCMSThreads，定義并發 CMS 過程運行時的線程數。比如 value=4 意味著 CMS 周期的所有階段都以 4 個線程來執行。盡管更多的線程會加快并發 CMS 過程，但其也會帶來額外的同步開銷。因此，對于特定的應用程序，應該通過測試來判斷增加 CMS 線程數是否真的能夠帶來性能的提升。如果還標志未設置，JVM 會根據并行收集器中的 -XX:ParallelGCThreads 參數的值來計算出默認的并行 CMS 線程數。
-XX:ParallelGCThreads：配置并行收集器的線程數，即：同時有多少個線程一起進行垃圾回收，此值建議配置與 CPU 數目相等。
-XX:OldSize：設置 JVM 啟動分配的老年代內存大小，類似于新生代內存的初始大小 -XX:NewSize。
以上就是一些常用的配置參數，有些參數是可以被替代的，配置思路需要考慮的是 Java 提供的垃圾回收機制。虛擬機的堆大小決定了虛擬機花費在收集垃圾上的時間和頻度。收集垃圾能夠接受的速度和應用有關，應該通過分析實際的垃圾收集的時間和頻率來調整。假如堆的大小很大，那么完全垃圾收集就會很慢，但是頻度會降低。假如您把堆的大小和內存的需要一致，完全收集就很快，但是會更加頻繁。調整堆大小的的目的是最小化垃圾收集的時間，以在特定的時間內最大化處理客戶的請求。在基準測試的時候，為確保最好的性能，要把堆的大小設大，確保垃圾收集不在整個基準測試的過程中出現。
假如系統花費很多的時間收集垃圾，請減小堆大小。一次完全的垃圾收集應該不超過 3-5 秒。假如垃圾收集成為瓶頸，那么需要指定代的大小，檢查垃圾收集的周詳輸出，研究垃圾收集參數對性能的影響。當增加處理器時，記得增加內存，因為分配能夠并行進行，而垃圾收集不是并行的。
常見的 Java 內存溢出有以下三種
（1） java.lang.OutOfMemoryError: Java heap space —-JVM Heap（堆）溢出
JVM 在啟動的時候會自動設置 JVM Heap 的值，其初始空間（即-Xms）是物理內存的1/64，最大空間（-Xmx）不可超過物理內存。可以利用 JVM提供的 -Xmn -Xms -Xmx 等選項可進行設置。Heap 的大小是 Young Generation 和 Tenured Generaion 之和。在 JVM 中如果 98％ 的時間是用于 GC，且可用的 Heap size 不足 2％ 的時候將拋出此異常信息。
解決方法：手動設置 JVM Heap（堆）的大小。
（2） java.lang.OutOfMemoryError: PermGen space —- PermGen space溢出。
PermGen space 的全稱是 Permanent Generation space，是指內存的永久保存區域。為什么會內存溢出，這是由于這塊內存主要是被 JVM 存放Class 和 Meta 信息的，Class 在被 Load 的時候被放入 PermGen space 區域，它和存放 Instance 的 Heap 區域不同，sun 的 GC 不會在主程序運行期對 PermGen space 進行清理，所以如果你的 APP 會載入很多 CLASS 的話，就很可能出現 PermGen space 溢出。
解決方法： 手動設置 MaxPermSize 大小
（3） java.lang.StackOverflowError —- 棧溢出
棧溢出了，JVM 依然是采用棧式的虛擬機，這個和 C 與 Pascal 都是一樣的。函數的調用過程都體現在堆棧和退棧上了。調用構造函數的 “層”太多了，以致于把棧區溢出了。通常來講，一般棧區遠遠小于堆區的，因為函數調用過程往往不會多于上千層，而即便每個函數調用需要 1K 的空間（這個大約相當于在一個 C 函數內聲明了 256 個 int 類型的變量），那么棧區也不過是需要 1MB 的空間。通常棧的大小是 1－2MB 的。
通常遞歸也不要遞歸的層次過多，很容易溢出。
解決方法：修改程序。
轉自IDONGXU博客
1.7.2 線程池的優化
默認配置下，Tomcat 會為每個連接器創建一個綁定的線程池（最大線程數 200），服務啟動時，默認創建了 5 個空閑線程隨時等待用戶請求。
首先，打開 ${TOMCAT_HOME}/conf/server.xml，搜索【<Executor name=“tomcatThreadPool”】，開啟并調整為
然后在connect里指定使用的executor，
<Connector executor="tomcatThreadPool"port="8080" protocol="HTTP/1.1"URIEncoding="UTF-8"connectionTimeout="30000"enableLookups="false"disableUploadTimeout="false"connectionUploadTimeout="150000"acceptCount="300"keepAliveTimeout="120000"maxKeepAliveRequests="1"compression="on"compressionMinSize="2048"compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain,image/gif,image/jpg,image/png" redirectPort="8443" />maxThreads :Tomcat 使用線程來處理接收的每個請求，這個值表示 Tomcat 可創建的最大的線程數，默認值是 200
minSpareThreads：最小空閑線程數，Tomcat 啟動時的初始化的線程數，表示即使沒有人使用也開這么多空線程等待，默認值是 10。
maxSpareThreads：最大備用線程數，一旦創建的線程超過這個值，Tomcat 就會關閉不再需要的 socket 線程。
上邊配置的參數，最大線程 500（一般服務器足以），要根據自己的實際情況合理設置，設置越大會耗費內存和 CPU，因為 CPU 疲于線程上下文切換，沒有精力提供請求服務了，最小空閑線程數 20，線程最大空閑時間 60 秒，當然允許的最大線程連接數還受制于操作系統的內核參數設置，設置多大要根據自己的需求與環境。當然線程可以配置在“tomcatThreadPool”中，也可以直接配置在“Connector”中，但不可以重復配置。
URIEncoding：指定 Tomcat 容器的 URL 編碼格式，語言編碼格式這塊倒不如其它 WEB 服務器軟件配置方便，需要分別指定。
connnectionTimeout： 網絡連接超時，單位：毫秒，設置為 0 表示永不超時，這樣設置有隱患的。通常可設置為 30000 毫秒，可根據檢測實際情況，適當修改。
enableLookups： 是否反查域名，以返回遠程主機的主機名，取值為：true 或 false，如果設置為false，則直接返回IP地址，為了提高處理能力，應設置為 false。
disableUploadTimeout：上傳時是否使用超時機制。
connectionUploadTimeout：上傳超時時間，畢竟文件上傳可能需要消耗更多的時間，這個根據你自己的業務需要自己調，以使Servlet有較長的時間來完成它的執行，需要與上一個參數一起配合使用才會生效。
acceptCount：指定當所有可以使用的處理請求的線程數都被使用時，可傳入連接請求的最大隊列長度，超過這個數的請求將不予處理，默認為100個。
keepAliveTimeout：長連接最大保持時間（毫秒），表示在下次請求過來之前，Tomcat 保持該連接多久，默認是使用 connectionTimeout 時間，-1 為不限制超時。
maxKeepAliveRequests：表示在服務器關閉之前，該連接最大支持的請求數。超過該請求數的連接也將被關閉，1表示禁用，-1表示不限制個數，默認100個，一般設置在100~200之間。
compression：是否對響應的數據進行 GZIP 壓縮，off：表示禁止壓縮；on：表示允許壓縮（文本將被壓縮）、force：表示所有情況下都進行壓縮，默認值為off，壓縮數據后可以有效的減少頁面的大小，一般可以減小1/3左右，節省帶寬。
compressionMinSize：表示壓縮響應的最小值，只有當響應報文大小大于這個值的時候才會對報文進行壓縮，如果開啟了壓縮功能，默認值就是2048。
compressableMimeType：壓縮類型，指定對哪些類型的文件進行數據壓縮。
noCompressionUserAgents=“gozilla, traviata”： 對于以下的瀏覽器，不啟用壓縮。
如果已經對代碼進行了動靜分離，靜態頁面和圖片等數據就不需要 Tomcat 處理了，那么也就不需要配置在 Tomcat 中配置壓縮了。
1.7.3 數據庫性能調優
Tomcat性能在等待數據庫查詢被執行期間會降低。如今大多數應用程序都是使用可能包含“命名查詢”的關系型數據庫。如果是那樣的話，Tomcat會在啟動時默認加載命名查詢，這個可能會提升性能。另一件重要事是確保所有數據庫連接正確地關閉。給數據庫連接池設置正確值也是十分重要的。我所說的值是指Resource要素的最大空閑數（maxIdle），最大連接數（maxActive）,最大建立連接等待時間（maxWait）屬性的值。因為配置依賴與應用要求，我也不能在本文指定正確的值。你可以通過調用數據庫性能測試來找到正確的值。
1.7.4 其他
- 開啟瀏覽器緩存
- 一般https會比http請求慢，當然為了安全，我們肯定要選擇https
總結
- 上一篇： spring event的事件驱动模型的
- 下一篇： nginx必知必会