引言: 不知不覺自己已經做了幾年開發了，由記得剛出來工作的時候感覺自己能牛逼，現在回想起來感覺好無知。懂的越多的時候你才會發現懂的越少。
如果傳送失效:2365217564
微雲學習地址：https://share.weiyun.com/5mokPqU
網盤學習地址：https://pan.baidu.com/s/1CTx5SqUeM-ZKtDYLeovODQ 提取碼：iclq
1、Tomcat 的缺省端口是多少，怎么修改?
1)找到 Tomcat 目錄下的 conf 文件夾
2)進入 conf 文件夾里面找到 server.xml 文件
3)打開 server.xml 文件
4)在 server.xml 文件里面找到下列信息
<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443" uriEncoding="utf-8"/> port="8080"改成你想要的端口
2、tomcat 有哪幾種 Connector 運行模式(優化)?
bio:傳統的 Java I/O 操作，同步且阻塞 IO。
maxThreads=”150”//Tomcat 使用線程來處理接收的每個請求。這個值表示 Tomcat 可創建的最大的線程數。默認值 200。可以根據機器的時期性能和內存 大小調整，一般可以在 400-500。最大可以在 800 左右。 minSpareThreads=”25”—Tomcat 初始化時創建的線程數。默認值 4。如果 當前沒有空閑線程，且沒有超過 maxThreads，一次性創建的空閑線程數量。 Tomcat 初始化時創建的線程數量也由此值設置。 maxSpareThreads=”75”–一旦創建的線程超過這個值，Tomcat 就會關閉不 再需要的 socket 線程。默認值 50。一旦創建的線程超過此數值，Tomcat 會關 閉不再需要的線程。線程數可以大致上用 “同時在線人數每秒用戶操作次數系 統平均操作時間” 來計算。 acceptCount=”100”—-指定當所有可以使用的處理請求的線程數都被使用 時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理。默認值 10。如果當前可用線程數為 0，則將請求放入處理隊列中。這個值限定了請求 隊列的大小，超過這個數值的請求將不予處理。 connectionTimeout=”20000” –網絡連接超時，默認值 20000，單位:毫 秒。設置為 0 表示永不超時，這樣設置有隱患的。通常可設置為 30000 毫秒。
nio:JDK1.4 開始支持，同步阻塞或同步非阻塞 IO。
指定使用 NIO 模型來接受 HTTP 請求 protocol=”org.apache.coyote.http11.Http11NioProtocol” 指定使用 NIO 模型 來接受 HTTP 請求。默認是 BlockingIO，配置為 protocol=”HTTP/1.1” acceptorThreadCount=”2” 使用 NIO 模型時接收線程的數目
aio(nio.2):JDK7 開始支持，異步非阻塞 IO。
apr:Tomcat 將以 JNI 的形式調用 Apache HTTP 服務器的核心動態鏈接庫來 處理文件讀取或網絡傳輸操作，從而大大地 提高Tomcat對靜態文件的處理性 能。
<!--
<Connector connectionTimeout="20000" port="8000"
protocol="HTTP/1.1" redirectPort="8443" uriEncoding="utf-8"/> -->
<!-- protocol 啟用 nio模式，(tomcat8默認使用的是nio)(apr模式利用系 統級異步 io) -->
<!-- minProcessors 最小空閑連接線程數-->
<!-- maxProcessors 最大連接線程數-->
<!-- acceptCount 允許的最大連接數，應大於等於 maxProcessors-->
<!-- enableLookups 如果為 true,requst.getRemoteHost 會執行 DNS 查
找，反向解析 ip 對應域名或主機名--> <Connector
protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000"
redirectPort="8443 maxThreads=“500” minSpareThreads=“100” maxSpareThreads=“200” acceptCount="200" enableLookups="false"
/>
port="8080"
其他配置
maxHttpHeaderSize="8192" http 請求頭信息的最大程度，超過此長度的部分 不予處理。一般 8K。
URIEncoding="UTF-8" 指定 Tomcat 容器的 URL 編碼格式。 disableUploadTimeout="true" 上傳時是否使用超時機制 enableLookups="false"--是否反查域名，默認值為 true。為了提高處理能力， 應設置為 false
compression="on" 打開壓縮功能
compressionMinSize="10240" 啟用壓縮的輸出內容大小，默認為 2KB noCompressionUserAgents="gozilla, traviata" 對於以下的瀏覽器，不啟用 壓縮 compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 哪些資源類型需要壓縮
3、Tomcat 有幾種部署方式?
1)直接把 Web 項目放在 webapps 下，Tomcat 會自動將其部署 2)在 server.xml 文件上配置<Context>節點，設置相關的屬性即可
3)通過 Catalina 來進行配置:進入到 conf\Catalina\localhost 文件下，創建一個 xml 文件，該文件的名字就是站點的名字。
編寫 XML 的方式來進行設置。
4、tomcat 容器是如何創建 servlet 類實例?用到了什么原理?
當容器啟動時，會讀取在 webapps 目錄下所有的 web 應用中的 web.xml 文 件，然后對 xml 文件進行解析，
並讀取 servlet 注冊信息。然后，將每個應用中注冊的 servlet 類都進行加載， 並通過反射的方式實例化。
(有時候也是在第一次請求時實例化)在 servlet 注冊時加上如果為正數，則在 一開始就實例化，
如果不寫或為負數，則第一次請求實例化。
5.tomcat 如何優化?
1、優化連接配置.這里以 tomcat7 的參數配置為例，需要修改 conf/server.xml
文件，修改連接數，關閉客戶端 dns 查詢。 參數解釋:
URIEncoding=”UTF-8′′ :使得 tomcat 可以解析含有中文名的文件的 url，真 方便，不像 apache 里還有搞個 mod_encoding，還要手工編譯
maxSpareThreads : 如果空閑狀態的線程數多於設置的數目，則將這些線程中 止，減少這個池中的線程總數。
minSpareThreads : 最小備用線程數，tomcat 啟動時的初始化的線程數。 enableLookups : 這個功效和 Apache 中的 HostnameLookups 一樣，設為關
閉。
connectionTimeout : connectionTimeout 為網絡連接超時時間毫秒數。
maxThreads : maxThreads Tomcat使用線程來處理接收的每個請求。這個值 表示 Tomcat 可創建的最大的線程數，即最大並發數。
acceptCount : acceptCount是當線程數達到maxThreads后，后續請求會被放 入一個等待隊列，這個 acceptCount 是這個隊列的大小，如果這個隊列也滿 了，就直接 refuse connection
maxProcessors與minProcessors : 在 Java中線程是程序運行時的路徑，是 在一個程序中與其它控制線程無關的、能夠獨立運行的代碼段。它們共享相同
的地址空間。多線程幫助程序員寫出CPU最 大利用率的高效程序，使空閑時 間保持最低，從而接受更多的請求。
通常 Windows 是 1000 個左右，Linux 是 2000 個左右。 useURIValidationHack:
我們來看一下 tomcat 中的一段源碼:
【security】
if (connector.getUseURIValidationHack()) {
String uri = validate(request.getRequestURI());
if (uri == null) {
res.setStatus(400);
res.setMessage(“Invalid URI”);
throw new IOException(“Invalid URI”);
} else {
req.requestURI().setString(uri);
// Redoing the URI decoding
req.decodedURI().duplicate(req.requestURI());
req.getURLDecoder().convert(req.decodedURI(), true);
可以看到如果把 useURIValidationHack 設成”false”，可以減少它對一些 url 的不必要的檢查從而減省開銷。
enableLookups=”false” : 為了消除 DNS 查詢對性能的影響我們可以關閉 DNS 查詢，方式是修改 server.xml 文件中的 enableLookups 參數值。
disableUploadTimeout :類似於 Apache 中的 keeyalive 一樣 給 Tomcat 配置 gzip 壓縮(HTTP 壓縮)功能 compression=”on” compressionMinSize=”2048′′
compressableMimeType=”text/html,text/xml,text/JavaScript,text/css,text/plain”
HTTP 壓縮可以大大提高瀏覽網站的速度，它的原理是，在客戶端請求網頁 后，從服務器端將網頁文件壓縮，再下載到客戶端，由客戶端的瀏覽器負責解 壓縮並瀏覽。相對於普通的瀏覽過程HTML,CSS,javascript , Text ，它可以節 省 40%左右的流量。更為重要的是，它可以對動態生成的，包括 CGI、PHP , JSP , ASP , Servlet,SHTML 等輸出的網頁也能進行壓縮，壓縮效率驚人。
1)compression=”on” 打開壓縮功能
2)compressionMinSize=”2048′′ 啟用壓縮的輸出內容大小，這里面默認為
2KB
3)noCompressionUserAgents=”gozilla, traviata” 對於以下的瀏覽器，不啟
用壓縮 4)compressableMimeType=”text/html,text/xml” 壓縮類型
最后不要忘了把 8443 端口的地方也加上同樣的配置，因為如果我們走 https 協 議的話，我們將會用到 8443 端口這個段的配置，對吧?
<!–enable tomcat ssl–>
<Connector port=”8443′′ protocol=”HTTP/1.1′′
URIEncoding=”UTF-8′′ minSpareThreads=”25′′ maxSpareThreads=” 75′′
enableLookups=”false” disableUploadTimeout=”true” connectionTimeout=”20000′′
acceptCount=”300′′ maxThreads=”300′′ maxProcessors=”1000′′ minProcessors=”5′′
useURIValidationHack=”false”
compression=”on” compressionMinSize=”2048′′ compressableMimeType=”text/html,text/xml,text/javascript,text/css,text/plain” SSLEnabled=”true”
scheme=”https” secure=”true”
clientAuth=”false” sslProtocol=”TLS” keystoreFile=”d:/tomcat2/conf/shnlap93.jks” keystorePass=”aaaaaa” />
好了，所有的 Tomcat 優化的地方都加上了。
6.內存調優
內存方式的設置是在 catalina.sh 中，調整一下 JAVA_OPTS 變量即可，因為后 面的啟動參數會把 JAVA_OPTS 作為 JVM 的啟動參數來處理。 具體設置如下:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k - XX:NewRatio=4 -XX:SurvivorRatio=4"
其各項參數如下:
-Xmx3550m:設置 JVM 最大可用內存為 3550M。
-Xms3550m:設置 JVM 促使內存為 3550m。此值可以設置與-Xmx 相同，以 避免每次垃圾回收完成后 JVM 重新分配內存。 -Xmn2g:設置年輕代大小為2G。整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為 64m，所以增大年輕代后，將會減小年老 代大小。此值對系統性能影響較大，Sun 官方推薦配置為整個堆的 3/8。 -Xss128k:設置每個線程的堆棧大小。JDK5.0 以后每個線程堆棧大小為 1M， 以前每個線程堆棧大小為 256K。更具應用的線程所需內存大小進行調整。在相 同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的 線程數還是有限制的，不能無限生成，經驗值在 3000~5000 左右。 -XX:NewRatio=4:設置年輕代(包括 Eden 和兩個 Survivor 區)與年老代的比 值(除去持久代)。設置為 4，則年輕代與年老代所占比值為 1:4，年輕代占 整個堆棧的 1/5
-XX:SurvivorRatio=4:設置年輕代中 Eden 區與 Survivor 區的大小比值。設置 為 4，則兩個 Survivor 區與一個 Eden 區的比值為 2:4，一個 Survivor 區占整 個年輕代的 1/6
-XX:MaxPermSize=16m:設置持久代大小為 16m。 -XX:MaxTenuringThreshold=0:設置垃圾最大年齡。如果設置為 0 的話，則年 輕代對象不經過 Survivor 區，直接進入年老代。對於年老代比較多的應用，可 以提高效率。如果將此值設置為一個較大值，則年輕代對象會在 Survivor 區進 行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收 的概論。
7.垃圾回收策略調優
垃圾回收的設置也是在 catalina.sh 中，調整 JAVA_OPTS 變量。 具體設置如下:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -
XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
具體的垃圾回收策略及相應策略的各項參數如下: 串行收集器(JDK1.5 以前主要的回收方式) -XX:+UseSerialGC:設置串行收集器 並行收集器(吞吐量優先)
示例:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC - XX:MaxGCPauseMillis=100
-XX:+UseParallelGC:選擇垃圾收集器為並行收集器。此配置僅對年輕代有 效。即上述配置下，年輕代使用並發收集，而年老代仍舊使用串行收集。 -XX:ParallelGCThreads=20:配置並行收集器的線程數，即:同時多少個線程 一起進行垃圾回收。此值最好配置與處理器數目相等。 -XX:+UseParallelOldGC:配置年老代垃圾收集方式為並行收集。JDK6.0 支持 對年老代並行收集 -XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間，如果無法 滿足此時間，JVM 會自動調整年輕代大小，以滿足此值。 -XX:+UseAdaptiveSizePolicy:設置此選項后，並行收集器會自動選擇年輕代 區大小和相應的 Survivor 區比例，以達到目標系統規定的最低相應時間或者收 集頻率等，此值建議使用並行收集器時，一直打開。 並發收集器(響應時間優先)
示例:java -Xmx3550m -Xms3550m -Xmn2g -Xss128k - XX:+UseConcMarkSweepGC -XX:+UseConcMarkSweepGC:設置年老代為並發收集。測試中配置這個以 后，-XX:NewRatio=4 的配置失效了，原因不明。所以，此時年輕代大小最好 用-Xmn 設置。
-XX:+UseParNewGC: 設置年輕代為並行收集。可與 CMS 收集同時使用。 JDK5.0 以上，JVM 會根據系統配置自行設置，所以無需再設置此值。 -XX:CMSFullGCsBeforeCompaction:由於並發收集器不對內存空間進行壓 縮、整理，所以運行一段時間以后會產生“碎片”，使得運行效率降低。此值 設置運行多少次 GC 以后對內存空間進行壓縮、整理。 -XX:+UseCMSCompactAtFullCollection:打開對年老代的壓縮。可能會影響性 能，但是可以消除碎片
8.共享 session 處理
目前的處理方式有如下幾種:
1).使用 Tomcat 本身的 Session 復制功能
參考 http://ajita.iteye.com/blog/1715312(Session 復制的配置) 方案的有點是配置簡單，缺點是當集群數量較多時，Session 復制的時間會比 較長，影響響應的效率
2).使用第三方來存放共享 Session
目前用的較多的是使用 memcached 來管理共享 Session，借助於 memcached-sesson-manager 來進行 Tomcat 的 Session 管理
參考 http://ajita.iteye.com/blog/1716320(使用 MSM 管理 Tomcat 集群 session)
3).使用黏性 session 的策略 對於會話要求不太強(不涉及到計費，失敗了允許重新請求下等)的場合，同 一個用戶的 session 可以由 nginx 或者 apache 交給同一個 Tomcat 來處理，這 就是所謂的 session sticky 策略，目前應用也比較多 參考:http://ajita.iteye.com/blog/1848665(tomcat session sticky) nginx默認不包含session sticky模塊，需要重新編譯才行(windows下我也不 知道怎么重新編譯)
優點是處理效率高多了，缺點是強會話要求的場合不合適
8.添加 JMS 遠程監控
對於部署在局域網內其它機器上的 Tomcat，可以打開 JMX 監控端口，局域網 其它機器就可以通過這個端口查看一些常用的參數(但一些比較復雜的功能不 支持)，同樣是在 JVM 啟動參數中配置即可，配置如下: -Dcom.sun.management.jmxremote.ssl=false - Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=192.168.71.38 設置JVM的JMS監控監聽的IP 地址，主要是為了防止錯誤的監聽成 127.0.0.1 這個內網地址 -Dcom.sun.management.jmxremote.port=1090 設置 JVM 的 JMS 監控的端口 -Dcom.sun.management.jmxremote.ssl=false 設置 JVM 的 JMS 監控不實用 SSL
-Dcom.sun.management.jmxremote.authenticate=false 設置 JVM 的 JMS 監 控不需要認證
9.專業點的分析工具有
IBM ISA，JProfiler、probe 等，具體監控及分析方式去網上搜索即可 10.關於 Tomcat 的 session 數目
這個可以直接從 Tomcat 的 web 管理界面去查看即可 ; 或者借助於第三方工具 Lambda Probe 來查看，它相對於 Tomcat 自帶的管理 稍微多了點功能，但也不多 ;
11.監視 Tomcat 的內存使用情況
使用 JDK 自帶的 jconsole 可以比較明了的看到內存的使用情況，線程的狀態， 當前加載的類的總量等;
JDK 自帶的 jvisualvm 可以下載插件(如 GC 等)，可以查看更豐富的信息。 如果是分析本地的 Tomcat 的話，還可以進行內存抽樣等，檢查每個類的使用 情況
12.打印類的加載情況及對象的回收情況
這個可以通過配置 JVM 的啟動參數，打印這些信息(到屏幕(默認也會到 catalina.log 中)或者文件)，具體參數如下: -XX:+PrintGC:輸出形式:[GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs] -XX:+PrintGCDetails:輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps可與上面兩個 混合使用，輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中斷 的執行時間。可與上面混合使用。輸出形式:Application time: 0.5291524 seconds -XX:+PrintGCApplicationStoppedTime:打印垃圾回收期間程序暫停的時間。 可與上面混合使用。輸出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:PrintHeapAtGC: 打印 GC 前后的詳細堆棧信息 -Xloggc:filename:與上面幾個配合使用，把相關日志信息記錄到文件以便分析 -verbose:class 監視加載的類的情況
-verbose:gc 在虛擬機發生內存回收時在輸出設備顯示信息
-verbose:jni 輸出 native 方法調用的相關情況，一般用於診斷 jni 調用錯誤信息
13.Tomcat 一個請求的完整過程 Ng:(nginx)
upstream yy_001{
server 10.99.99.99:8080; server 10.99.99.100:8080;
hash $**;
healthcheck_enabled;
healthcheck_delay 3000;
healthcheck_timeout 1000;
healthcheck_failcount 2;
healthcheck_send 'GET /healthcheck.html HTTP/1.0' 'Host: wo.com'
'Connection: close'; }
server {
include base.conf; server_name wo.de.tian;
...
location /yy/ {
proxy_pass http://yy_001;
}
首先 dns 解析 wo.de.tian 機器，一般是 ng 服務器 ip 地址
然后 ng 根據 server 的配置，尋找路徑為 yy/的機器列表，ip 和端口 最后 選擇其中一台機器進行訪問—->下面為詳細過程
1) 請求被發送到本機端口 8080，被在那里偵聽的 Coyote
Connector 獲得
2) Connector 把該請求交給它所在的 Service 的 Engine 來處理，並等待來自 Engine 的回應
3) Engine 獲得請求 localhost/yy/index.jsp，匹配它所擁有的所有虛擬主機 Host 4) Engine 匹配到名為 localhost 的 Host(即使匹配不到也把請求交給該 Host 處理，因為該 Host 被定義為該 Engine 的默認主機)
5) localhost Host 獲得請求/yy/index.jsp，匹配它所擁有的所有 Context
6) Host 匹配到路徑為/yy 的 Context(如果匹配不到就把該請求交給路徑名 為”“的 Context 去處理)
7) path=”/yy”的Context獲得請求/index.jsp，在它的mapping table中尋找 對應的 servlet
8) Context 匹配到 URL PATTERN 為*.jsp 的 servlet，對應於 JspServlet 類
9) 構造 HttpServletRequest 對象和 HttpServletResponse 對象，作為參數調用 JspServlet 的 doGet 或 doPost 方法
10)Context 把執行完了之后的 HttpServletResponse 對象返回給 Host
11)Host 把 HttpServletResponse 對象返回給 Engine
12)Engine 把 HttpServletResponse 對象返回給 Connector
-
13)Connector 把 HttpServletResponse 對象返回給客戶 browser
-
————————————————
版權聲明：本文為CSDN博主「QQ_417240199」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/QQ_417240199/article/details/105347929