❶ linux下安裝tomcat的默認安裝目錄在哪
Ubuntu的tomcat安裝包，解壓後，就是安裝目錄
從官網http://tomcat.apache.org/下載tomcat，保存並拿在/home目錄下。
# cp apache-tomcat-6.0.20.tar.gz /home
# cd /home
#tar -zxvf apache-tomcat-6.0.20.tar.gz
# ls
apache-tomcat-6.0.18 jdk-6u30-linux-i586.bin mytask.sh web.war
jdk1.6.0_30 ljq ubuntu
# cd apache-tomcat-6.0.18/
# ls
bin lib logs RELEASE-NOTES temp work
conf LICENSE NOTICE RUNNING.txt webapps
tomcat目錄解析：
bin：存放啟動和關閉Tomcat的可執行腳本。
conf：Tomcat的配置文件，如server.xml(Tomcat伺服器配置文件)和或蔽中web.xml(被所有webapps共享的配置文件)，密碼忘了看 tomcat-users.xml。
webapps：存放web applications，用戶自己需要部署的應用程序也放到此目錄。
work：tomcat運行時生成的臨時文件，包括jsp編譯後產生的class文件等。
logs：存放日誌文件。
temp：JVM用於存放臨時文件的目錄(java.io.tmpdir)。
/home/apache-tomcat-6.0.18/bin# ./startup.sh //啟動tomcat
/home/apache-tomcat-6.0.18/bin# ./shutdown.sh //關閉tomcat
/home/apache-tomcat-6.0.18/logs# tail -f catalina.out //查看tomcat日誌(-f表示會不衫山斷列印新的日誌出來)
❷ Tomcat配置實踐
要部署使用tomcat，則必須了解tomcat的目錄結構以及各目錄的作用。這里以tomcat7為例，進入tomcat安裝目錄下：
前端請求被tomcat直接接收或者由前端的代理，通過HTTP，或者AJP代理給Tomcat，此時請求被tomcat中的connector接收，不同的connector和Engine被service組件關聯起來，在一個Engine中定義了許多的虛擬主機，由Host容器定義，每一個Host容器代表一個主機，在各自的Host中，又可以定義多個Context，用此來定義一個虛擬主機中的多個獨立的應用程序。
Tomcat Server的結構圖如下：
看上去很復雜。其實，大部分都是注釋。下面是一個簡圖說明了各組件之間的關系！
上面列出的比較常用的組件元素，server.xml文件中可定義的元素非常多，包括Server, Service, Connector, Engine, Cluster, Host, Alias, Context, Realm, Valve, Manager, Listener, Resources, Resource, ResourceEnvRef, ResourceLink, WatchedResource, GlobalNameingResources, Store, Transaction, Channel, Membership, Transport, Member, ClusterListener等等。
由以上配置不難看出存在的一個問題。如果我們想要對其中一個應用程序的配置做一些修改，那麼就必須重新啟動tomcat，那樣勢必就會影響到另外兩個應用程序的正常服務。因此以上配置是不適合線上使用的， 因此需要將其配置為多實例，每個實例只跑一個獨立的應用程序，那樣我們應用程序之間就不會在互相受到影響。 但是我們將面臨這樣一豎雹個問題，80埠只能被一個HTTP/1.1 Connector監聽，而三個tomcat實例則至少需要3個HTTP/1.1 Connector，這樣我們就 需要一個前端代理做分發處理，接收HTTP 80埠的請求，按域名通過每個tomcat實例的AJP/1.3 Connector傳遞請求 。而前端的代理選擇apache，基於這樣的思路，我們還可以做到tomcat的負載均衡，而且 apache會將接收的HTTP超文本傳輸報文重新封裝成二進制格式通過AJP/1.3 協議傳遞給後端的tomcat處理 ，在效率上余指帆也是有明顯的提升。
這會讓Tomcat啟動一個server實例（即一個JVM），它監聽在8005埠以接收shutdown命令。各Server的定義不能使用同一個埠，這意味著如果在同一個物理機上啟動了多個Server實例，必須配置它們使用不同的埠。這個埠的定義用於為管理員提供一個關閉此實例的便捷途徑，因此，管理員可以直接telnet至此埠使用SHUTDOWN命令關閉此實例。不過，基於安全形度的考慮，這通常不允許遠程進行。
該元素代表整個容器，是Tomcat實例的頂層元素。由org.apache.catalina.Server介面來定義。它包含一個或多個<Service>元素。並且它不能做為任何元素的子元素。
Service主要用於關聯一個引擎和與此引擎相關的連接器，每個連接器通過一個特定的埠和協議接收入站請求交將其轉發至關聯的引擎進行處理。因此，Service要包含一個引擎、一個或多個連接器。
該元素由org.apache.catalina.Service介面定義，它包含一個<Engine>元素，以及一個或多個<Connector>，這些Connector元素共享用同一個Engine元素。
Engine是Servlet處理器的一個實逗備例，即servlet引擎，默認為定義在server.xml中的Catalina。
每個Service元素只能有一個Engine元素。元素處理在同一個<Service>中所有<Connector>元素接收到的客戶請求。由org.apahce.catalina.Engine介面定義。
位於Engine容器中用於接收請求並進行相應處理的主機或虛擬主機。
它由Host介面定義。一個Engine元素可以包含多個<Host>元素。每個<Host>的元素定義了一個虛擬主機。它包含了一個或多個Web應用<Context>。
Context在某些意義上類似於apache中的路徑別名，一個Context定義用於標識tomcat實例中的一個Web應用程序。
它由Context介面定義。是使用最頻繁的元素。每個<Context>元素代表了運行在虛擬主機上的單個Web應用。一個<Host>可以包含多個<Context>元素。每個web應用有唯一的一個相對應的Context代表web應用自身。servlet容器為第一個web應用創建一個 ServletContext對象。
由Connector介面定義。<Connector>元素代表與客戶程序實際交互的組件，它負責接收客戶請求，以及向客戶返回響應結果。
進入Tomcat的請求可以根據Tomcat的工作模式分為如下兩類：
Tomcat應該考慮工作情形並為相應情形下的請求分別定義好需要的連接器才能正確接收來自於客戶端的請求。一個引擎可以有一個或多個連接器，以適應多種請求方式。
定義連接器可以使用多種屬性，有些屬性也只適用於某特定的連接器類型。一般說來，常見於server.xml中的連接器類型通常有4種：
Connector元素共用屬性：
HttpConnector元素的屬性：
AJP Connector的屬性：
即一個service配置多個埠，項目可以通過多個埠訪問。 修改tomcat-homeconf下的server.xml，在Service下配置多個<Connector>即可。
在這個應用里，可以用8080埠號訪問服務，也可以用8099埠號來訪問服務; 服務放置的路徑由host決定，上例中服務放在webapps下。
即配置多個service，每個service可以配置多個埠。修改tomcat-homeconf下的server.xml，添加多個Service即可。
注意：Service name、Engine name、appBase，埠號別忘了修改，以免重復。
以上三個service，發布的路徑不同，項目分別發布在webapps、webapps1、webapps2下，訪問不同的項目的方法：
在$CATALINA_HOME/conf/server.xml配置文件中的Connetctor節點，和連接數相關的參數配置和優化。
Tomcat使用線程來處理接收的每個請求。這個值表示Tomcat可創建的最大的線程數。默認值200。 可以根據機器的時期性能和內存大小調整，一般可以在400-500 。最大可以在800左右。
指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理。默認值10。
Tomcat初始化時創建的線程數。默認值4。
一旦創建的線程超過這個值，Tomcat就會關閉不再需要的socket線程。默認值50。
是否反查域名，默認值為true。 為了提高處理能力，應設置為false 。
網路連接超時，默認值20000，單位：毫秒。設置為0表示永不超時，這樣設置有隱患的。 通常可設置為30000毫秒 。
保持請求數量，默認值100。
輸入流緩沖大小，默認值2048 bytes。
壓縮傳輸，取值on/off/force，默認值off。
其中和最大連接數相關的參數為maxThreads和acceptCount。 如果要加大並發連接數，應同時加大這兩個參數 。 web server允許的最大連接數還受制於操作系統的內核參數設置 ，通常Windows是2000個左右，Linux是1000個左右。
配置示例：
Tomcat默認可以使用的內存為128MB,Windows下,在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件$CATALINA_HOME/bin/catalina.sh的前面，增加如下設置：
一般說來，你應該使用物理內存的 80% 作為堆大小。如果本機上有Apache伺服器，可以先折算Apache需要的內存，然後修改堆大小。 建議設置為70％；建議設置[初始化內存大小]等於[可以使用的最大內存]，這樣可以減少頻繁分配堆而降低性能。
在$CATALINA_HOME/conf/web.xml中，把listings參數設置成false即可，如下：
參考
WEB請求處理四：Tomcat配置實踐
❸ tomcat 7的默認t配置文件在哪裡
tomcat通常分為安裝版和壓縮版.看你是什麼方式進行的安裝.
不正含過無穗祥論那種方式,你都可以使用文件名查找方式進行.
windows:略
linux:find / -name "tomcat"
查找舉族笑到後,通常在文件夾下的conf文件夾中.
❹ 詳解 Tomcat 配置文件 server.xml
前言
Tomcat隸屬於Apache基金會，是開源的輕量級Web應用伺服器，使用非常廣泛。server.xml是Tomcat中最重要的配置文件，server.xml的每一個元素都對應了Tomcat中的一個組件；通過對xml文件中元素的配置，可以實現對Tomcat中各個組件的控制。因此，學習server.xml文件的配置，對於了解和使用Tomcat至關重要。
本文將通過實例，介紹server.xml中各個組件的配置，並詳細說明Tomcat各個核心組件的作用以及各個組件之間的相互關系。
說明：由於server.xml文件中元素與Tomcat中組件的對應關系，後文中為了描述方便，「元素」和「組件」的使用不嚴格區分。
一、一個server.xml配置實例
server.xml位於$TOMCAT_HOME/conf目錄下；下面是一個server.xml實例。後文中將結合該實例講解server.xml中，各個元素的含義和作用；在閱讀後續章節過程中，可以對照該xml文檔便於理解。
二、server.xml文檔的元素分類和整體結構
1、整體結構
server.xml的整體結構如下：
該結構中只給出了Tomcat的核心組件，除了核心組件外，Tomcat還有一些其他組件，下面介紹一下組件的分類。
2、元素分類
server.xml文件中的元素可以分為以下4類：
（1）頂層元素：和
元素是整個配置文件的根元素，元素則代表一個Engine元素以及一組與之相連的Connector元素。
（2）連接器：
代表了外部客戶端發送請求到特定Service的介面；同時也是外部客戶端從特定Service接收響應的介面。
（3）容器：
容器的功能是處理Connector接收進來的請求，並產生相應的響應。Engine、Host和Context都是容器，但它們不是平行的關系，而是父子關系：Engine包含Host，Host包含Context。一個Engine組件可以處理Service中的所有請求，一個Host組件可以處理發向一個特定虛擬主機的所有請求，一個Context組件可以處理一個特定Web應用的所有請求。
（4）內嵌組件：可以內嵌到容器中的組件。實際上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat組件，其他組件都可以歸為內嵌組件。
下面將詳細介紹Tomcat中各個核心組件的作用，以及相互之間的關系。
三、核心組件
本部分將分別介紹各個核心組件的作用、特點以及配置方式等。
1、Server
Server元素在最頂層，代表整個Tomcat容器，因此它必須是server.xml中唯一一個最外層的元素。一個Server元素中可以有一個或多個Service元素。
在第一部分的例子中，在最外層有一個元素，shutdown屬性表示關閉Server的指令；port屬性表示Server接收shutdown指令的埠號，設為-1可以禁掉該埠。
Server的主要任務，就是提供一個介面讓客戶端能夠訪問到這個Service集合，同時維護它所包含的所有的Service的聲明周期，包括如何初始化、如何結束服務、如何找到客戶端要訪問的Service。
2、Service
Service的作用，是在Connector和Engine外麵包了一層，把它們組裝在一起，對外提供服務。一個Service可以包含多個Connector，但是只能包含一個Engine；其中Connector的作用是從客戶端接收請求，Engine的作用是處理接收進來的請求。
在第一部分的例子中，Server中包含一個名稱為「Catalina」的Service。實際上，Tomcat可以提供多個Service，不同的Service監聽不同的埠，後文會有介紹。
3、Connector
Connector的主要功能，是接收連接請求，創建Request和Response對象用於和請求端交換數據；然後分配線程讓Engine來處理這個請求，並把產生的Request和Response對象傳給Engine。
通過配置Connector，可以控制請求Service的協議及埠號。在第一部分的例子中，Service包含兩個Connector：
在這個例子中，Tomcat監聽HTTP請求，使用的是8080埠，而不是正式的80埠；實際上，在正式的生產環境中，Tomcat也常常監聽8080埠，而不是80埠。這是因為在生產環境中，很少將Tomcat直接對外開放接收請求，而是在Tomcat和客戶端之間加一層代理伺服器(如nginx)，用於請求的轉發、負載均衡、處理靜態文件等；通過代理伺服器訪問Tomcat時，是在區域網中，因此一般仍使用8080埠。
（2）通過配置第2個Connector，客戶端可以通過8009埠號使用AJP協議訪問Tomcat。AJP協議負責和其他的HTTP伺服器(如Apache)建立連接；在把Tomcat與其他HTTP伺服器集成時，就需要用到這個連接器。之所以使用Tomcat和其他伺服器集成，是因為Tomcat可以用作Servlet/JSP容器，但是對靜態資源的處理速度較慢，不如Apache和IIS等HTTP伺服器；因此常常將Tomcat與Apache等集成，前者作Servlet容器，後者處理靜態資源，而AJP協議便負責Tomcat和Apache的連接。Tomcat與Apache等集成的原理如下圖(圖片來源)：
4、Engine
Engine組件在Service組件中有且只有一個；Engine是Service組件中的請求處理組件。Engine組件從一個或多個Connector中接收請求並處理，並將完成的響應返回給Connector，最終傳遞給客戶端。
前面已經提到過，Engine、Host和Context都是容器，但它們不是平行的關系，而是父子關系：Engine包含Host，Host包含Context。
在第一部分的例子中，Engine的配置語句如下：
其中，name屬性用於日誌和錯誤信息，在整個Server中應該唯一。defaultHost屬性指定了默認的host名稱，當發往本機的請求指定的host名稱不存在時，一律使用defaultHost指定的host進行處理；因此，defaultHost的值，必須與Engine中的一個Host組件的name屬性值匹配。
5、Host
（1）Engine與Host
Host是Engine的子容器。Engine組件中可以內嵌1個或多個Host組件，每個Host組件代表Engine中的一個虛擬主機。Host組件至少有一個，且其中一個的name必須與Engine組件的defaultHost屬性相匹配。
（2）Host的作用
Host虛擬主機的作用，是運行多個Web應用（一個Context代表一個Web應用），並負責安裝、展開、啟動和結束每個Web應用。
Host組件代表的虛擬主機，對應了伺服器中一個網路名實體(如」www.test.com」，或IP地址」116.25.25.25」)；為了使用戶可以通過網路名連接Tomcat伺服器，這個名字應該在DNS伺服器上注冊。
客戶端通常使用主機名來標識它們希望連接的伺服器；該主機名也會包含在HTTP請求頭中。Tomcat從HTTP頭中提取出主機名，尋找名稱匹配的主機。如果沒有匹配，請求將發送至默認主機。因此默認主機不需要是在DNS伺服器中注冊的網路名，因為任何與所有Host名稱不匹配的請求，都會路由至默認主機。
（3）Host的配置
在第一部分的例子中，Host的配置如下：
下面對其中配置的屬性進行說明：
name屬性指定虛擬主機的主機名，一個Engine中有且僅有一個Host組件的name屬性與Engine組件的defaultHost屬性相匹配；一般情況下，主機名需要是在DNS伺服器中注冊的網路名，但是Engine指定的defaultHost不需要，原因在前面已經說明。
unpackWARs指定了是否將代表Web應用的WAR文件解壓；如果為true，通過解壓後的文件結構運行該Web應用，如果為false，直接使用WAR文件運行Web應用。
Host的autoDeploy和appBase屬性，與Host內Web應用的自動部署有關；此外，本例中沒有出現的xmlBase和deployOnStartup屬性，也與Web應用的自動部署有關；將在下一節(Context)中介紹。
6、Context
（1）Context的作用
Context元素代表在特定虛擬主機上運行的一個Web應用。在後文中，提到Context、應用或Web應用，它們指代的都是Web應用。每個Web應用基於WAR文件，或WAR文件解壓後對應的目錄（這里稱為應用目錄）。
Context是Host的子容器，每個Host中可以定義任意多的Context元素。
在第一部分的例子中，可以看到server.xml配置文件中並沒有出現Context元素的配置。這是因為，Tomcat開啟了自動部署，Web應用沒有在server.xml中配置靜態部署，而是由Tomcat通過特定的規則自動部署。下面介紹一下Tomcat自動部署Web應用的機制。
（2）Web應用自動部署
Host的配置
要開啟Web應用的自動部署，需要配置所在的虛擬主機；配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy屬性。如果deployOnStartup和autoDeploy設置為true，則tomcat啟動自動部署：當檢測到新的Web應用或Web應用的更新時，會觸發應用的部署(或重新部署)。二者的主要區別在於，deployOnStartup為true時，Tomcat在啟動時檢查Web應用，且檢測到的所有Web應用視作新應用；autoDeploy為true時，Tomcat在運行時定期檢查新的Web應用或Web應用的更新。除此之外，二者的處理相似。
通過配置deployOnStartup和autoDeploy可以開啟虛擬主機自動部署Web應用；實際上，自動部署依賴於檢查是否有新的或更改過的Web應用，而Host元素的appBase和xmlBase設置了檢查Web應用更新的目錄。
其中，appBase屬性指定Web應用所在的目錄，默認值是webapps，這是一個相對路徑，代表Tomcat根目錄下webapps文件夾。
xmlBase屬性指定Web應用的XML配置文件所在的目錄，默認值為conf//，例如第一部分的例子中，主機localhost的xmlBase的默認值是$TOMCAT_HOME/conf/Catalina/localhost。
檢查Web應用更新
一個Web應用可能包括以下文件：XML配置文件，WAR包，以及一個應用目錄(該目錄包含Web應用的文件結構)；其中XML配置文件位於xmlBase指定的目錄，WAR包和應用目錄位於appBase指定的目錄。
Tomcat按照如下的順序進行掃描，來檢查應用更新：
A、掃描虛擬主機指定的xmlBase下的XML配置文件
B、掃描虛擬主機指定的appBase下的WAR文件
C、掃描虛擬主機指定的appBase下的應用目錄
元素的配置
Context元素最重要的屬性是docBase和path，此外reloadable屬性也比較常用。
docBase指定了該Web應用使用的WAR包路徑，或應用目錄。需要注意的是，在自動部署場景下(配置文件位於xmlBase中)，docBase不在appBase目錄中，才需要指定；如果docBase指定的WAR包或應用目錄就在docBase中，則不需要指定，因為Tomcat會自動掃描appBase中的WAR包和應用目錄，指定了反而會造成問題。
path指定了訪問該Web應用的上下文路徑，當請求到來時，Tomcat根據Web應用的 path屬性與URI的匹配程度來選擇Web應用處理相應請求。例如，Web應用app1的path屬性是」/app1」，Web應用app2的path屬性是」/app2」，那麼請求/app1/index.html會交由app1來處理；而請求/app2/index.html會交由app2來處理。如果一個Context元素的path屬性為」」，那麼這個Context是虛擬主機的默認Web應用；當請求的uri與所有的path都不匹配時，使用該默認Web應用來處理。
但是，需要注意的是，在自動部署場景下(配置文件位於xmlBase中)，不能指定path屬性，path屬性由配置文件的文件名、WAR文件的文件名或應用目錄的名稱自動推導出來。如掃描Web應用時，發現了xmlBase目錄下的app1.xml，或appBase目錄下的app1.WAR或app1應用目錄，則該Web應用的path屬性是」app1」。如果名稱不是app1而是ROOT，則該Web應用是虛擬主機默認的Web應用，此時path屬性推導為」」。
reloadable屬性指示tomcat是否在運行時監控在WEB-INF/classes和WEB-INF/lib目錄下class文件的改動。如果值為true，那麼當class文件改動時，會觸發Web應用的重新載入。在開發環境下，reloadable設置為true便於調試；但是在生產環境中設置為true會給伺服器帶來性能壓力，因此reloadable參數的默認值為false。
下面來看自動部署時，xmlBase下的XML配置文件app1.xml的例子：
在該例子中，docBase位於Host的appBase目錄之外；path屬性沒有指定，而是根據app1.xml自動推導為」app1」；由於是在開發環境下，因此reloadable設置為true，便於開發調試。
自動部署舉例
最典型的自動部署，就是當我們安裝完Tomcat後，$TOMCAT_HOME/webapps目錄下有如下文件夾：
當我們啟動Tomcat後，可以使用http://localhost:8080/來訪問Tomcat，其實訪問的就是ROOT對應的Web應用；我們也可以通過http://localhost:8080/docs來訪問docs應用，同理我們可以訪問examples/host-manager/manager這幾個Web應用。
（3）server.xml中靜態部署Web應用
除了自動部署，我們也可以在server.xml中通過元素靜態部署Web應用。靜態部署與自動部署是可以共存的。在實際應用中，並不推薦使用靜態部署，因為server.xml 是不可動態重載入的資源，伺服器一旦啟動了以後，要修改這個文件，就得重啟伺服器才能重新載入。而自動部署可以在Tomcat運行時通過定期的掃描來實現，不需要重啟伺服器。
server.xml中使用Context元素配置Web應用，Context元素應該位於Host元素中。舉例如下：
1
docBase：靜態部署時，docBase可以在appBase目錄下，也可以不在；本例中，docBase不在appBase目錄下。
path：靜態部署時，可以顯式指定path屬性，但是仍然受到了嚴格的限制：只有當自動部署完全關閉(deployOnStartup和autoDeploy都為false)或docBase不在appBase中時，才可以設置path屬性。在本例中，docBase不在appBase中，因此path屬性可以設置。
reloadable屬性的用法與自動部署時相同。
四、核心組件的關聯
1、整體關系
核心組件之間的整體關系，在上一部分有所介紹，這里總結一下：
Server元素在最頂層，代表整個Tomcat容器；一個Server元素中可以有一個或多個Service元素。
Service在Connector和Engine外麵包了一層，把它們組裝在一起，對外提供服務。一個Service可以包含多個Connector，但是只能包含一個Engine；Connector接收請求，Engine處理請求。
Engine、Host和Context都是容器，且 Engine包含Host，Host包含Context。每個Host組件代表Engine中的一個虛擬主機；每個Context組件代表在特定Host上運行的一個Web應用。
2、如何確定請求由誰處理？
當請求被發送到Tomcat所在的主機時，如何確定最終哪個Web應用來處理該請求呢？
（1）根據協議和埠號選定Service和Engine
Service中的Connector組件可以接收特定埠的請求，因此，當Tomcat啟動時，Service組件就會監聽特定的埠。在第一部分的例子中，Catalina這個Service監聽了8080埠（基於HTTP協議）和8009埠（基於AJP協議）。當請求進來時，Tomcat便可以根據協議和埠號選定處理請求的Service；Service一旦選定，Engine也就確定。
通過在Server中配置多個Service，可以實現通過不同的埠號來訪問同一台機器上部署的不同應用。
（2）根據域名或IP地址選定Host
Service確定後，Tomcat在Service中尋找名稱與域名/IP地址匹配的Host處理該請求。如果沒有找到，則使用Engine中指定的defaultHost來處理該請求。在第一部分的例子中，由於只有一個Host（name屬性為localhost），因此該Service/Engine的所有請求都交給該Host處理。
（3）根據URI選定Context/Web應用
這一點在Context一節有詳細的說明：Tomcat根據應用的 path屬性與URI的匹配程度來選擇Web應用處理相應請求，這里不再贅述。
（4）舉例
以請求http://localhost:8080/app1/index.html為例，首先通過協議和埠號（http和8080）選定Service；然後通過主機名（localhost）選定Host；然後通過uri（/app1/index.html）選定Web應用。
3、如何配置多個服務
通過在Server中配置多個Service服務，可以實現通過不同的埠號來訪問同一台機器上部署的不同Web應用。
在server.xml中配置多服務的方法非常簡單，分為以下幾步：
（1）復制元素，放在當前後面。
（2）修改埠號：根據需要監聽的埠號修改元素的port屬性；必須確保該埠沒有被其他進程佔用，否則Tomcat啟動時會報錯，而無法通過該埠訪問Web應用。
以Win7為例，可以用如下方法找出某個埠是否被其他進程佔用：netstat -aon|findstr 「8081″發現8081埠被PID為2064的進程佔用，tasklist |findstr 「2064″發現該進程為FrameworkService.exe(這是McAfee殺毒軟體的進程)。
（3）修改Service和Engine的name屬性
（4）修改Host的appBase屬性（如webapps2）
（5）Web應用仍然使用自動部署
（6）將要部署的Web應用(WAR包或應用目錄)拷貝到新的appBase下。
以第一部分的server.xml為例，多個Service的配置如下：
http://localhost:8080/docs/
http://localhost:8084/docs/
五、其他組件
除核心組件外，server.xml中還可以配置很多其他組件。下面只介紹第一部分例子中出現的組件，如果要了解更多內容，可以查看Tomcat官方文檔。
1、Listener
Listener(即監聽器)定義的組件，可以在特定事件發生時執行特定的操作；被監聽的事件通常是Tomcat的啟動和停止。
監聽器可以在Server、Engine、Host或Context中，本例中的監聽器都是在Server中。實際上，本例中定義的6個監聽器，都只能存在於Server組件中。監聽器不允許內嵌其他組件。
監聽器需要配置的最重要的屬性是className，該屬性規定了監聽器的具體實現類，該類必須實現了org.apache.catalina.LifecycleListener介面。
下面依次介紹例子中配置的監聽器：
VersionLoggerListener：當Tomcat啟動時，該監聽器記錄Tomcat、Java和操作系統的信息。該監聽器必須是配置的第一個監聽器。
AprLifecycleListener：Tomcat啟動時，檢查APR庫，如果存在則載入。APR，即Apache Portable Runtime，是Apache可移植運行庫，可以實現高可擴展性、高性能，以及與本地伺服器技術更好的集成。
JasperListener：在Web應用啟動之前初始化Jasper，Jasper是JSP引擎，把JVM不認識的JSP文件解析成java文件，然後編譯成class文件供JVM使用。
：與類載入器導致的內存泄露有關。
：通過該監聽器，初始化< GlobalNamingResources>標簽中定義的全局JNDI資源；如果沒有該監聽器，任何全局資源都不能使用。< GlobalNamingResources>將在後文介紹。
：當Web應用因thread-local導致的內存泄露而要停止時，該監聽器會觸發線程池中線程的更新。當線程執行完任務被收回線程池時，活躍線程會一個一個的更新。只有當Web應用(即Context元素)的屬性設置為true時，該監聽器才有效。
2、GlobalNamingResources與Realm
第一部分的例子中，Engine組件下定義了Realm組件：
Realm，可以把它理解成「域」；Realm提供了一種用戶密碼與web應用的映射關系，從而達到角色安全管理的作用。在本例中，Realm的配置使用name為UserDatabase的資源實現。而該資源在Server元素中使用GlobalNamingResources配置：
GlobalNamingResources元素定義了全局資源，通過配置可以看出，該配置是通過讀取$TOMCAT_HOME/ conf/tomcat-users.xml實現的。
關於Tomcat域管理的更多內容，可以參考：Realm域管理
3、Valve
在第一部分的例子中，Host元素內定義了Valve組件：
單詞Valve的意思是「閥門」，在Tomcat中代表了請求處理流水線上的一個組件；Valve可以與Tomcat的容器(Engine、Host或Context)關聯。
不同的Valve有不同的特性，下面介紹一下本例中出現的AccessLogValve。
AccessLogValve的作用是通過日誌記錄其所在的容器中處理的所有請求，在本例中，Valve放在Host下，便可以記錄該Host處理的所有請求。AccessLogValve記錄的日誌就是訪問日誌，每天的請求會寫到一個日誌文件里。AccessLogValve可以與Engine、Host或Context關聯；在本例中，只有一個Engine，Engine下只有一個Host，Host下只有一個Context，因此AccessLogValve放在三個容器下的作用其實是類似的。
本例的AccessLogValve屬性的配置，使用的是默認的配置；下面介紹AccessLogValve中各個屬性的作用：
（1）className：規定了Valve的類型，是最重要的屬性；本例中，通過該屬性規定了這是一個AccessLogValve。
（2）directory：指定日誌存儲的位置，本例中，日誌存儲在$TOMCAT_HOME/logs目錄下。
（3）prefix：指定了日誌文件的前綴。
（4）suffix：指定了日誌文件的後綴。通過directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目錄下，可以看到如下所示的日誌文件。
（5）pattern：指定記錄日誌的格式，本例中各項的含義如下：
%h：遠程主機名或IP地址；如果有nginx等反向代理伺服器進行請求分發，該主機名/IP地址代表的是nginx，否則代表的是客戶端。後面遠程的含義與之類似，不再解釋。
%l：遠程邏輯用戶名，一律是」-」，可以忽略。
%u：授權的遠程用戶名，如果沒有，則是」-」。
%t：訪問的時間。
%r：請求的第一行，即請求方法(get/post等)、uri、及協議。
%s：響應狀態，200,404等等。
%b：響應的數據量，不包括請求頭，如果為0，則是」」-。
例如，下面是訪問日誌中的一條記錄
pattern的配置中，除了上述各項，還有一個非常常用的選項是%D，含義是請求處理的時間(單位是毫秒)，對於統計分析請求的處理速度幫助很大。
開發人員可以充分利用訪問日誌，來分析問題、優化應用。例如，分析訪問日誌中各個介面被訪問的比例，不僅可以為需求和運營人員提供數據支持，還可以使自己的優化有的放矢；分析訪問日誌中各個請求的響應狀態碼，可以知道伺服器請求的成功率，並找出有問題的請求；分析訪問日誌中各個請求的響應時間，可以找出慢請求，並根據需要進行響應時間的優化。
❺ embedtomcat默認配置
embedtomcat默認配置步驟如下。
1、把自己開發的項目下的webroot復制到ROOT下(先念首刪除掉原有的的ROOT下東西)，重啟，應該就OK了。
2、找仔早數到TOMCAT_HOME/conf/server、xml，編輯
3、最睜胡後的結果就是：
❻ TOMCAT配置文件 目錄描述
1、TOMCAT配置文件：
$CATALINA_HOME/conf/web.xml配置簡介
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
說明：<servlet-name>：定義Servlet的名字。<servlet-class>：指定實現這個Servlet的類。<init-param>：定義Servlet的初始化參數（包括參數名和參數值），一個 <servlet>元素中可以有多個<init-param>元素。<load-on-startup>：指定當Web應用啟動時，裝載Servlet的次序。當這個值為正數或零，Servlet容器先載入數值小的Servlet，再一次載入其他數值大的Servlet。如果這個值為負數或沒有設定，Servlet將在Web客戶首次訪問這個Servlet時載入它。
<session-config>
<session-timeout>30</session-timeout>
</session-config>
a.如果某文件資源沒有找到，伺服器要報404錯誤，按下述配置則會調用\webapps\ROOT\notFileFound.jsp
<error-page>
<error-code>404</error-code>
<location>/notFileFound.jsp</location>
</error-page>
b.如果執行的某個JSP文件產生NullPointException，則會調用\webapps\ROOT\null.jsp
<error-page>
<exception-type>java.lang.NullPointerException</exception-type>
<location>/null.jsp</location>
</error-page>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
默認Web應用的首頁文件的設置
報錯文件的設置
session 會話過期時間的設置,單位是分鍾
servlet的設置
filter過濾器的設置
<filter>
<filter-name>FilterSource</filter-name>
<filter-class>project4. FilterSource </filter-class>
</filter>
<filter-mapping>
<filter-name>FilterSource</filter-name>
<url-pattern>/WwwServlet</url-pattern>
(<url-pattern>/haha/*</url-pattern>)
</filter-mapping>
2、TOMCAT的目錄結構
/bin：存放windows或Linux平台上啟動和關閉Tomcat的腳本文件
/conf：存放Tomcat伺服器的各種全局配置文件，其中最重要的是server.xml和web.xml
/doc：存放Tomcat文檔
/server：包含三個子目錄：classes、lib和webapps
/server/lib：存放Tomcat伺服器所需的各種JAR文件
/server/webapps：存放Tomcat自帶的兩個WEB應用admin應用和 manager應用
/common/lib：存放Tomcat伺服器以及所有web應用都可以訪問的jar文件
/shared/lib：存放所有web應用都可以訪問的jar文件（但是不能被Tomcat伺服器訪問）
/logs：存放Tomcat執行時的日誌文件
/src：存放Tomcat的源代碼
/webapps：Tomcat的主要Web發布目錄，默認情況下把Web應用文件放於此目錄
/work：存放JSP編譯後產生的class文件
❼ tomcat 的配置文件有那些
tomcat的配置文件可能出現的問題如下：
一、正確的配置方法：
(1)jdk配置：
新建java_home=d:program
filesjavajdk1.6.0
編輯path：（java_home在用戶變數path也要在用戶變數中）path=%java_home%in;
在系統變數中
新建：classpath=.;%java_home%lib;%java_home%lib*.jar;
classpath必須在系統變數中建
（2）
tomcat配置：
catalina_home=d:apache-tomcat-6.0.18
（或者是tomcat_home=d:apache-tomcat-6.0.18）
二、tomcat啟動後一閃而過：
1.如果雙擊startup.bat,窗口一閃而過，可以在命令行裡面啟動startup.bat；
2.如果命令行裡面啟動startup.bat情況還是這樣，就可以在bat命令後面加上pause，這樣就不會一閃而過了；
三、其他一些關於tomcat啟動時的奇怪問題：
a.tomcat無法從"開始"中啟動,但可以在startup.bat中啟動
jdk版本過低
b.啟動的時候，載入信息的提示界面在屏幕上停留幾秒鍾就消失了，同時，tomcat的應用程序也自動關閉
在server.xml的最後，/host之上，應該寫上的是：content
c.tomcat啟動時有一些顯示,但仍會自動關閉,無法啟動.
可能是地址被佔用,運行桌面上的"關閉tomcat"快捷方式,執行完畢後再啟動tomcat.
d.tomcat啟動時一閃而過,無法啟動.
可能是埠被佔用,可找到tomcat的安裝目錄下的server.xml文件,如..eam2003confserver.xml,用記事本打開此文件,查找8080,如果找到,就將8080改為8088.
❽ Tomcat基礎(2)
Tomcat伺服器的配置主要集中於tomcat/conf下的catalina.policy, catalina.properties,context.xml、server.xml、tomcat-users.xml、web.xml文件。
server.xml 是tomcat伺服器的核心配置文件,包含了Tomcat的servlet容器(catalina)的所有配置。由於配置的屬性特別多,我們在這里主要講解其中的一部分重要配置。
Server是server.xml的根元素,用於創建一個Server實例,默認使用的實現類是org.apache.catalina.core.standardserver.
port:Tomcat監聽的關閉伺服器的埠。
shutdown:關閉伺服器的指令字元串。
Server內嵌的子元素為Listener, GlobalNamingResources, Service.
默認配置的5個Listener的含義
GlobalNamingResources中定義了全局命名服務
該元素用於創建Service實例,默認使用org.apache.catalina.core.Standardservice,默認情況下,Tomcat僅指定了Service的名稱,值為"Catalina",Service可以內嵌的元素為:Listener, Executor, connector, Engine ,其中Listener用於為Service添加生命周期監聽器,Executor用於配置Service共享線程池,Connector用於配置Service包含的鏈接器,Engine用於配置Service中鏈接器對應的Servlet容器引擎。一個Server伺服器,可以包含多個Service服務。
默認情況下Service並未添加共享線程池配置，如果我們想添加一個線程池，可以在下添加如下配置：
屬性說明
屬性含義
name線程池名稱，用於Connector中指定。
nameprefix所創建的每個線程的名稱前綴,一個單獨的線程名稱為namePrefix+threadNumber.
maxThreads池中最大線程數。
minSpareThreads活躍線程數,也就是核心池線程數,這些線程不會被銷毀,會一直存在。
maxIdleTime線程空閑時間,超過該時間後,空閑線程會被銷毀,默認值為6000 (1分鍾) ,單位毫秒。
maxQueuesize在被執行前最大線程排隊數目,默認為Int的最大值,也就是廣義的無限。除非特殊情況,這個值不需要更改,否則會有請求不會被處理的情況發生。
prestartminSpareThreads啟動線程池時是否啟動minSpareThreads部分線程。默認值為false,即不啟動。
threadPriority線程池中線程優先順序,默認值為5,值從1到10。
className
線程池實現類,未指定情況下，默認實現類為org.apache.catalina.core.standardThreadExecutor,如果想使用自定義線程池首先需要實現 org.apache.catalina.Executor介面。
JDK工具jconsole.exe觀察線程池被創建
如果不配置共享線程池，那麼Catalina各組件在用到線程池時會獨立創建。
Connector用於創建鏈接器實例。默認情況下, server.xml配置了兩個鏈接器,一個支持HTTP協議,一個支持AJP協議。因此大多數情況下,我們並不需要新增鏈接器配置,只是根據需要對已有鏈接器進行優化。
屬性說明
1) port:埠號,Connector用於創建服務端Socket並進行監聽,以等待客戶端請求鏈接。如果該屬性設置為0,Tomcat將會隨機選擇一個可用的埠號給當前Connector使用。
2)protocol :當前Connector支持的訪問協議。默認為HTTP/1.1 ,並採用自動切換機制選擇一個基於JAVA NIO的鏈接器或者基於本地APR的鏈接器(根據本地是否含有Tomcat的本地庫判定)。
如果不希望採用上述自動切換的機制,而是明確指定協議,可以使用以下值。
Http協議:
AJP協議
3) connectionTimeOut: Connector接收鏈接後的等待超時時間,單位為毫秒。-1表示不超時。
4)redirectPort:當前Connector不支持SSL(HTTP協議證書)請求,接收到了一個請求,並且也符合security-constraint約束,需要SSL傳輸,Catalina自動將請求重定向到指定的埠。
5)executor:指定共享線程池的名稱, 也可以通過maxThreads, minSpareThreads等屬性配置內部線程池。
6)URIEncoding:用於指定編碼URI的字元編碼,
Tomcat8.x版本默認的編碼為UTF-8，Tomcat7.X版本默認為ISO-8859-1(解決請求字元串亂碼問題，Tomcat8版本默認UTF-8不需要指定URI字元編碼)。
完整的配置如下:
Engine作為Servlet引擎的頂級元素，內部可嵌入：Cluster、Listener、Realm、Valve和Host。
屬性說明：
1)name：用於指定Engine的名稱，默認為Catalina。該名稱會影響一部分Tomcat的存儲路徑(如臨時文件);
2)defaultHost：默認使用虛擬主機名稱，當客戶端請求指向的的主機無效時將交由默認虛擬主機處理，默認為localhost。
Host元素用於配置一個虛擬主機,它支持以下嵌入元素:Alias,cluster,Listener,valve,Realm,context,如果在Engine下配置Realm,那麼此配置將在當前Engine下的所有Host中共享。同樣,如果在Host中配置Realm , 則在當前Host下的所有context中共享。Context中的Realm優先順序>Host的Realm優先順序>Engine中的Realm優先順序。
屬性說明:
1)name:當前Host通用的網路名稱,必須與DNS伺服器上的注冊信息一致。Engine中包含的Host必須存在一個名稱與Engine的defaultHost設置一致。
2)appBase:當前Host的應用基礎目錄,當前Host上部署的web應用均在該目錄下(可以是絕對目錄,相對路徑)。默認為webapps。
3)unpackWARs:設置為true, Host在啟動時會將appBase目錄下war包解壓為目錄。設置為false,Host將直接從war文件啟動。
4)autoDeploy:控制tomcat是否在運行時定期檢測並自動部署新增或變更的web應用。
通過給Host添加別名，我們可以實現同一個Host擁有多個網路名稱，配置如下：
Context用於配置一個web應用，默認配置如下：
屬性描述 ：
1)docBase：Web應用目錄或War包的部署路徑。可以是絕對路徑，也可以是相對於Host appBase的相對路徑。
2)Path：Web應用的Context路徑。如果我們Host名為localhost，則該web應用訪問的路徑為： http://localhost:8080/myApp
它支持的內嵌元素為:CookieProcessor,Loader,Manager,Realm,Resources,WatchedResource,Jarscanner,Valve.
該配置文件中，主要配置的是Tomcat的用戶，角色等信息，用來控制Tomcat中manager，host-manager的訪問許可權。
web.xml是web應用的描述文件, 它支持的元素及屬性來自於servlet規范定義。在Tomcat中,web應用的描述信息包括tomcat/conf/web.xml中默認配置以及web應用WEB-INE/web.xml下的定製配置。
我們可以通過<context-param>添加ServletContext初始化參數，它配置了一個鍵值對，這樣我們可以在應用程序中使用javax.servlet.ServletContext.getInitParameter()方法獲取參數。 可以直接在servlet中進行應用 。
5.2 會話配置
<session-config>用於配置web應用會話，包括超時時間Cookie配置以及 會話追蹤模式 。它將覆蓋server.xml和context.xml
1)session-timeout:超時時間,單位分鍾。
2)cookie-config:用於配置會話追蹤Cookie
nane:Cookie的名稱
domain:Cookie的域名
path: Cookie的路徑
comment: 注釋
http-only:cookie只能通過HTTP方式進行訪問, JS無法讀取或修改,此項可以增加網站訪問的安全性。
secuze :設置true則此cookie只能通過HTTPS連接傳遞到伺服器,而HTTP連接則不會傳遞該信息。注意是從瀏覽器傳遞到伺服器,伺服器端的Cookie對像不受此項影響。
max-age:以秒為單位表示cookie的生存期,默認為-1表示是會話Cookie ,瀏覽器關閉時就會消失。
3)tracking-mode:用於配置會話追蹤模式,Servlet3.0版本中支持追蹤模式:COOKIE,URL,SSL
ACOOKIE:通過HTTP Cookie 追蹤會話是最常用的會話追蹤機制, 而且Servlet規范也要求所有的Servlet規范都需要支持Cookie追蹤。
B.URL:URL重寫是最基本的會話追蹤機制。當客戶端不支持Cookie時,可以採用URI重寫的方式。當採用URI追蹤模式時,請求路徑需要包含會話標識信息,Servlet容器會根據路徑中的會話標識設置請求的會話信息。如:"http: //www.myserver.com/user/index.html;jessionid=1234567890。
C.SSL:對於SSL請求,通過SSL會話標識確定請求會話標識。
Servlet的配置主要是兩部分，servlet和servlet-mapping；
配置說明：
1)sexvlet-name:指定servle的名稱,該屬性在web.xml中唯一。
2)servlet-class:用於指定servlet類名
3)init-param:用於指定servlet的初始化參數, 在應用中可以通過HttpServlet.getInitParameter獲取。
4) load-on-startup:用於控制在Web應用啟動時,Servlet的載入順序。值小於0, web應用啟動時,不載入該servlet,第一次訪問時載入
5)enabled: true ,false。若為false ,表示servlet不處理任何請求。
6)url-pattern:用於指定URL表達式,一個servlet-mapping可以同時配置多個url-pattern。
Servlet 中文件上傳配置
配置說明：
1)location:存放生成的文件地址。
2) max-file-size:允許上傳的文件最大值。默認值為-1,表示沒有限制。
3)max-request-size:針對該multi/form-data請求的最大數量,默認值為-1,表示無限制。
4)file-size-threshold:當數量量大於該值時, 內容會被寫入文件。
Listener用於監聽servlet中的事件，例如context、request、session對象的創建、修改、刪除，並觸發響應響應。Listener是 觀察者模式 的 實現 ，在servlet中主要用於context、request、session對象的生命周期進行監控。在servlet 2.5規范中共定義了8重Listener。在啟動時，ServletContextListener的執行順序與web.xml中的配置順序一致，停止時執行順序相反。
配置說明：
1)filter-name:用於指定過濾器名稱,在web.xm1中,過濾器名稱必須唯一。
2)filter-class:過濾器的全限定類名,該類必須實現Filter介面。
3)async-supported:該過濾器是否支持非同步。
4)init-param:用於配置Filter的初始化參數,可以配置多個,可以通過 FilterConfig.getInitParameter 獲取
5)url-pattern:指定該過濾器需要攔截的URL。
Tomcat conf/web.xml中配置了web默認訪問頁面。
Tomcat啟動後會嘗從上到下的請求順序。
如果在項目的WEB-INF目錄下的web.xml中配置訪問頁面，則會覆蓋Tomcat中的默認配置。
error-page用於配置web項目訪問異常時定向的頁面，支持HTTP響應碼和異常類兩種形式。優化用戶體驗，保證系統安全。
Tomcat中自定義錯誤頁面放入ROOT目錄下。
項目中將錯誤頁面放在web目錄下，並且會覆蓋Tomcat中的配置。
從早期的Tomcat版本開始,就提供了web版的管理控制台,他們是兩個獨立的web應用,位於webapps目錄下。Tomcat提供的管理應用有用於管理的Host的host-manager和用於管理web應用的manager。
這兩個web應用主要作用就是為Tomcat提供了管理後台，可以通過這兩個應用去管理Tomcat中所配置的虛擬主機、Tomcat中部署的web應用、Tomcat佔用的JVM內存分配、JVM參數配比等
Host-manager主要用來管理 虛擬主機 信息。Tomcat啟動之後,可以通過 http://localhost:8080/host-manager/html 訪問該web應用。host-manager默認添加了訪問許可權控制,當打開網址時,需要輸入用戶名和密碼(conf/tomcat-users.xml中配置) 。所以要想訪問該頁面,需要在conf/tomcat-users.xml中配置,並分配對應的角色:
1)admin-gui:用於控制頁面訪問許可權
2)admin-script:用於控制以簡單文本的形式進行訪問
配置如下:
界面：
Manager用來管理部署在當前Tomcat上的web應用，訪問路徑為 http://localhost:8080/manager ，同樣manager也添加了頁面訪問控制，因此我們需要為登錄用戶分配角色為：
Server Status查看伺服器狀態，給JVM內存優化參考數據
❾ 1 如何優化Tomcat
（1）bin：主要用來存放命令，.bat是windows下，.sh是Linux下
（2）conf：主要用來存放tomcat的一些配置文件
（3）lib：存放tomcat依賴的一些jar包
（4）logs：存放tomcat在運行時產生的日誌文件
（5）temp：存放運行時產生的臨時文件
（6）webapps：存放應用程序
（7）work：存放tomcat運行時編譯後的文件，比如JSP編譯後的文件
tomcat優化可以有幾個方向：配置項的刪除，配置參數的修改，jdk參數修改、Tomcat內存優化、Tomcat並發優化、Tomcat緩存優化
web項目中自帶的WEB-INF/web.xml，
tomcat自帶的conf/web.xml以及conf/server.xml文件。
因為這些xml文件都會被tomcat解析，所以優化方向是將這三類文件中不必要的配置刪除。
tomcat在啟動時，會將web項目中WEB-INF/web.xml和自己的conf/web.xml進行合並，然後在ContextConfig類下的configureContext()統一解析這些內容：
這個只能是在項目中不需要的配置不要放進去，有過期的配置要及時刪除，減少tomcat的解析成本。
這是一個處理靜態文件的servlet，如果項目中不需要tomcat進行靜態文件的處理，可以將其刪掉。
這個servlet是用來編譯和執行jsp文件的，如果項目中沒有jsp文件，可以將其刪掉。
項目中沒有jsp，關於jsp下面的映射也可以刪除：
文件中提供的mime類型非常多，如果有確定項目中不會涉及到的類型，可以刪除其映射配置。
如果不需要展示tomcat的歡迎頁，可以將其刪掉。
下面是tomcat8.5版本提供的默認listener列表：
作用是在Tomcat初始化時，列印一下Tomcat相關的版本信息以及操作系統和jdk環境信息，可以刪掉。
Tomcat啟動時，檢查APR庫，如果存在則載入，這個配置僅當connector的protocol設置為AJP/1.3時有用，如果非AJP/1.3，可以刪除。
Java運行環境可能導致某些已知位置的內存泄漏或文件鎖定，
提供這些情況的解決方案。
作用於全局資源，通過該監聽器，初始化標簽中定義的全局JNDI資源；
如果沒有該監聽器，定義的全局資源都不能使用。
如果不使用GlobalNamingResources定義全局資源，可以刪除。
Web應用因thread-local導致的內存泄露而要停止時，該監聽器會觸發線程池中線程的更新。
只有當Web應用(即Context元素)的屬性設置為true時，該監聽器才有效。
官方文檔對配置的解釋為：
GlobalNamingResources可以定義全局資源，可以看出，這個tomcat的默認配置是通過讀取$TOMCAT_HOME/ conf/tomcat-users.xml實現的。
tomcat-user.xml用於定義tomcat管理頁面相關配置，如果不登錄管理界面可以刪掉。
官網中對於這個connector有如下描述：
The AJP Connector element represents a Connector component that communicates with a web connector via the AJP protocol. This is used for cases where you wish to invisibly integrate Tomcat into an existing (or new) Apache installation, and you want Apache to handle the static content contained in the web application, and/or utilize Apache's SSL processing.
可知當tomcat需要集成到Apache伺服器時才使用這個connector，現在一般都用Nginx代替Apache，所以不使用Apache的話這個也可以刪掉。
tomcat默認配置包含如下connector：
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
Realm，可以把它理解成「域」；
Realm提供了一種用戶密碼與web應用的映射關系，從而達到角色安全管理的作用，tomcat默認的這個realm是和name為UserDatabase的資源綁定的，而該資源在Server元素中使用GlobalNamingResources配置。如果不需要可以刪掉。
Valve的意思是「閥門」，不同的Valve有不同的特性，Valve的配置中AccessLogValve的作用是記錄其所在容器處理的所有請求，默認配置中的Valve放在Host下，便可以記錄該Host處理的所有請求。
AccessLogValve記錄的日誌就是訪問日誌，每天的請求會寫到一個日誌文件里。現在一般記錄Nginx訪問日誌，這個也可以刪除。
tomcat是用Java寫的，就要運行在jvm上，垃圾處理方式等都要遵循jvm的方式。
tomcat中設置jvm參數在 catalina.sh(Linux)和catalina.bat(windows)中，以JAVA_OPTS變數存儲。以catalina.sh為例：
可以在該變數中添加jvm參數，達到減少gc次數等目標，例如根據tomcat所在伺服器修改jvm內存大小等。
參數優化主要是優化sever.xml中的配置參數，示例server.xml如下：
port：指定一個埠，這個埠負責監聽關閉tomcat的請求。
shutdown：指定向埠發送的命令字元串。
sever配置沒什麼可優化的。
name：指定service的名字。
service配置沒什麼可優化的。
port：指定伺服器端要創建的埠號，並在這個埠監聽來自客戶端的請求
minProcessors：伺服器啟動時創建的處理請求的線程數
maxProcessors：最大可以創建的處理請求的線程數
enableLookups：如果為true，則可以通過調用request.getRemoteHost()進行DNS查詢來得到遠程客戶端的實際主機名，若為false則不進行DNS查詢，而是返回其ip地址
redirectPort：指定伺服器正在處理http請求時收到了一個SSL傳輸請求後重定向的埠號
acceptCount：指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求將不予處理
maxConnections：達到這個值之後，將繼續接受連接，但是不處理，能繼續接受多少根據acceptCount的值
minSpareThreads：最小空閑線程數
connectionTimeout：指定超時的時間數(以毫秒為單位)
官網8.5版本connector使用連接類型如下：
查看Connector源碼:
可知默認協議使用的是Http11NioProtocol，即NIO方式。
tomcat默認連接池有限制，可以為connector配置自己的連接池，例如：
在連接池中可以根據項目自定義最大線程數量。
name：屬性用於日誌和錯誤信息，在整個Server中應該唯一
defaultHost：defaultHost屬性指定了默認的host名稱，當發往本機的請求指定的host名稱不存在時，一律使用defaultHost指定的host進行處理；因此defaultHost的值，必須與Engine中的一個Host組件的name屬性值匹配
沒什麼可優化的。
name：指定虛擬主機的主機名，一個Engine中有且僅有一個Host組件的name屬性與Engine組件的defaultHost屬性相匹配；
註：一般情況下，主機名需要是在DNS伺服器中注冊的網路名，但是Engine指定的defaultHost不需要
appBase：應用程序基本目錄，即存放應用程序的目錄
unpackWARs：指定了是否將war文件解壓，如果為true，則通過解壓後的目錄運行該Web應用；如果為false，則直接使用WAR文件運行Web應用
autoDeploy：是否自動部署，Tomcat運行期間會用一個線程定時檢查，如果有新的web工程會自動部署。
autoDeploy生產環境之下可以改成false，減少tomcat的負擔。
autoDeploy有需要注意的點，如果為true，拷貝war到webapp下面，tomcat自動解壓並部署。但是停掉tomcat拷貝新的war包過去，tomcat不會解壓新包並後覆蓋舊目錄，因為tomcat直接使用了之前解壓過的目錄。官網有描述：
If you redeploy an updated WAR file, be sure to delete the expanded directory when restarting Tomcat, so that the updated WAR file will be re-expanded (note that the auto deployer, if enabled, will automatically expand the updated WAR file once the previously expanded directory is removed).
docBase：代表應用程序或war文件存放的路徑，這個可以自由指定，例如d:/study
path：
表示此web應用程序的url的前綴，這樣請求的url為 http://localhost:8080/path/ **
reloadable：如果為true，則tomcat會自動檢測應用程序的/WEB-INF/lib和/WEB-INF/classes目錄的變化，自動裝載新的應用程序，可以在不重起tomcat的情況下改變應用程序
生產環境中可以把reloadable設置為false。
className：指定Realm使用的類名，此類必須實現org.apache.catalina.Realm介面
沒什麼可優化的
className：規定了Valve的類型；例如tomcat默認的是AccessLogValve。
directory：指定日誌存儲的位置，默認日誌存儲在 TOMCAT_HOME/logs目錄下，可以看到如下所示的日誌文件。
沒什麼可優化的。
Tomcat內存優化主要是對 tomcat 啟動參數優化，我們可以在 tomcat 的啟動腳本 catalina.sh 中設置 java_OPTS 參數。
現公司伺服器內存一般都可以加到最大2G ，所以可以採取以下配置：
JAVA_OPTS=』-Xms1024m -Xmx2048m -XX: PermSize=256M -XX:MaxNewSize=256m -XX:MaxPermSize=256m』
配置完成後可重啟Tomcat ，通過以下命令進行查看配置是否生效：
首先查看Tomcat 進程號：sudo lsof -i:9027
我們可以看到Tomcat 進程號是 12222 。
查看是否配置生效：sudo jmap – heap 12222
我們可以看到MaxHeapSize 等參數已經生效。
在Tomcat 配置文件 server.xml 中的
<Connector port="9027"
protocol="HTTP/1.1"
maxHttpHeaderSize="8192"
minProcessors="100"
maxProcessors="1000"
acceptCount="1000"
redirectPort="8443"
disableUploadTimeout="true"/>
maxThreads 客戶請求最大線程數
minSpareThreads Tomcat初始化時創建的 socket 線程數
maxSpareThreads Tomcat連接器的最大空閑 socket 線程數
enableLookups 若設為true, 則支持域名解析，可把 ip 地址解析為主機名
redirectPort 在需要基於安全通道的場合，把客戶請求轉發到基於SSL 的 redirectPort 埠
acceptAccount 監聽埠隊列最大數，滿了之後客戶請求會被拒絕（不能小於maxSpareThreads ）
connectionTimeout 連接超時
minProcessors 伺服器創建時的最小處理線程數
maxProcessors 伺服器同時最大處理線程數
URIEncoding URL統一編碼
compression 打開壓縮功能
compressionMinSize 啟用壓縮的輸出內容大小，這裡面默認為2KB
compressableMimeType 壓縮類型
connectionTimeout 定義建立客戶連接超時的時間. 如果為 -1, 表示不限制建立客戶連接的時間