今天在新環(huán)境里部署tomcat, 剛開始啟動(dòng)很快，關(guān)閉之后再啟動(dòng)，卻發(fā)現(xiàn)啟動(dòng)日志打印到

00:25:14.144 [localhost-startStop-1] INFO  o.s.web.context.ContextLoader – Root WebApplicationContext: initialization completed in 6287 ms

一直hold著，tomcat程序也無法訪問，以為是程序哪里配置錯(cuò)了，找了半天，甚至把spring的配置加載完全去掉才能啟動(dòng)，why, 程序在開發(fā)環(huán)境可是刷刷刷就跑起來的

后來一直沒管這程序過了幾分鐘去看日志，發(fā)現(xiàn)tomcat 程序才啟動(dòng)完畢，why?原來不是卡住，而是慢

用jstack 觀察一下啟動(dòng)線程, 發(fā)現(xiàn) C2 CompilerThread 占用cpu很高,  同時(shí) org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom這里讀文件也產(chǎn)生阻塞，占用CPU也很高。

一、問題描述

      在發(fā)布或重啟某線上某服務(wù)時(shí)（jetty8作為服務(wù)器），常常發(fā)現(xiàn)有些機(jī)器的load會(huì)飆到非常高（高達(dá)70），并持續(xù)較長一段時(shí)間（5分鐘）后回落（圖1），與此同時(shí)響應(yīng)時(shí)間曲線（圖2）也與load曲線一致。注：load飆高的初始時(shí)刻是應(yīng)用服務(wù)端口打開，流量打入時(shí)（load）。

圖1 發(fā)布時(shí)候load飆高

圖2 發(fā)布時(shí)候響應(yīng)時(shí)間飆高

二、問題排查方法

     發(fā)布時(shí)對資源使用情況進(jìn)行監(jiān)控。

1）通過top -H -p 查找cpu使用率較高的線程，發(fā)現(xiàn)2129和2130這兩個(gè)線程cpu使用較高。

圖3 查找cpu使用率較高的線程

2）通過jstack打印棧信息，并將線程號(hào)2129和2130轉(zhuǎn)換成16進(jìn)制（printf “%xn” 2129），分別為851和852，發(fā)現(xiàn)這兩個(gè)線程是編譯線程（表1）。此外當(dāng)這兩個(gè)線程cpu使用率降低后load以及響應(yīng)時(shí)間也馬上恢復(fù)了正常，時(shí)間點(diǎn)非常吻合。

表1 cpu使用率較高的兩個(gè)線程詳細(xì)信息

三、現(xiàn)象解釋

      C2 CompilerThread線程項(xiàng)目啟動(dòng)初期cpu使用率那么高，它在干什么呢？ 

      Java程序在啟動(dòng)的時(shí)候所有代碼的執(zhí)行都處于解釋執(zhí)行模式，只有在運(yùn)行了一段時(shí)間后，根據(jù)代碼方法執(zhí)行的次數(shù)，或代碼里循環(huán)的執(zhí)行次數(shù)等達(dá)到一定的閾值才會(huì)編譯成機(jī)器碼，編譯成機(jī)器碼后執(zhí)行效率會(huì)得到大幅提升，而隨著執(zhí)行時(shí)間進(jìn)一步拉長，JVM的各種更高級的編譯優(yōu)化手段就會(huì)逐漸加上，例如if條件的執(zhí)行狀況，逃逸分析等。這里的C2 CompilerThread線程干的就是編譯優(yōu)化的活。

     現(xiàn)在貌似可以解釋之前的現(xiàn)象了。

     在程序剛啟動(dòng)的時(shí)候，java還處于解釋執(zhí)行模式，因此服務(wù)效率很低，響應(yīng)時(shí)間緩慢，處理得慢了，load自然也就高了。而當(dāng)流量持續(xù)不斷導(dǎo)入時(shí)，我們代碼的很多方法執(zhí)行次數(shù)不斷增多，此時(shí)C2 CompilerThread線程不斷收集優(yōu)化信息，并且開始將一些熱點(diǎn)代碼優(yōu)化編譯成本地機(jī)器碼，因此該線程的cpu使用率增高。而當(dāng)C2 CompilerThread線程完成初始編譯優(yōu)化過程后，C2 CompilerThread線程的cpu使用率開始下降，與此同時(shí)優(yōu)化后服務(wù)的性能大幅提升，服務(wù)響應(yīng)時(shí)間也大大縮短，load也下降。

     現(xiàn)在的癥結(jié)在于編譯優(yōu)化過程持續(xù)時(shí)間較長，引起抖動(dòng)。如何降低編譯優(yōu)化的持續(xù)時(shí)間呢？

四、解決思路

1）預(yù)熱

      如果在服務(wù)接受線上請求之前提前完成編譯優(yōu)化過程，那么將能避免此種抖動(dòng)情況。一般的做法是預(yù)熱，有兩種方法：

      a）程序主動(dòng)預(yù)熱：在啟動(dòng)完成后，程序主動(dòng)的訪問熱點(diǎn)的代碼，確保主要的熱點(diǎn)代碼已被編譯成機(jī)器碼后再放入流量，可通過-XX:+PrintCompilation來確認(rèn)。

      b）復(fù)制流量預(yù)熱：通過tcpcopy軟件拷貝一份線上nginx的流量進(jìn)行預(yù)熱，完成之后再導(dǎo)入線上流量。

2）啟動(dòng)多個(gè)線程進(jìn)行編譯優(yōu)化

     如果能加快編譯優(yōu)化速度，那也能降低解釋執(zhí)行階段導(dǎo)致的抖動(dòng)時(shí)間。因此可以多拿幾個(gè)線程來做編譯，加快達(dá)到高峰性能的速度。

     可以使用-XX:CICompilerCount參數(shù)來設(shè)置編譯線程數(shù)目，這個(gè)值默認(rèn)是2（之前在棧里看到有兩個(gè)編譯線程），我們可以加到4。

3）采用多層編譯

      編譯方式有三種：1）Client模式；2）Server模式；3）Tiered模式。我們服務(wù)默認(rèn)是Server模式。

      Server模式是采用c2高級編譯的，會(huì)比較耗時(shí)且要運(yùn)行一段時(shí)間才會(huì)觸發(fā)編譯。 Server模式的優(yōu)點(diǎn)是編譯后程序效率較高；

      Client模式比較輕量也比較快觸發(fā)（比Server模式觸發(fā)快），編譯優(yōu)化后程序效率不如Server模式；

      Tiered模式是Client模式和Server模式的折中，一開始會(huì)啟用Client模式，可以在啟動(dòng)后更快的讓部分代碼先進(jìn)入編譯優(yōu)化階段，之后會(huì)啟動(dòng)Server模式，達(dá)到程序效率最大優(yōu)化的目的。

      Oracle JDK 7里的HotSpot VM已經(jīng)開始有比較好的Tiered編譯（tiered compilation）支持，可以設(shè)置參數(shù)-XX:+TieredCompilation來啟動(dòng)Tiered模式，java 8默認(rèn)就是Tiered模式。

      圖4是截取的不同編譯方式的性能比較圖，橫坐標(biāo)是時(shí)間，縱坐標(biāo)是性能?？梢钥闯鯰ired模式開始階段性能與C1相當(dāng)，當(dāng)?shù)竭_(dá)某一時(shí)刻后性能與C2相當(dāng)。

圖4 不同編譯模式的性能比較

五、結(jié)果分析

       簡單起見采用方案2和方案3來進(jìn)行優(yōu)化。

       采用方案2和3之后進(jìn)行了多次發(fā)布，發(fā)布時(shí)除個(gè)別機(jī)器load達(dá)到10之外，基本沒有過高現(xiàn)象（在2~4范圍內(nèi)），并且短時(shí)間(2分鐘)內(nèi)，load都會(huì)降到較合理水平（2左右），較發(fā)布時(shí)的load來看，比優(yōu)化前要好很多。

      方案2和方案3只是降低了抖動(dòng)持續(xù)的時(shí)間以及抖動(dòng)強(qiáng)度，并不能完全避免抖動(dòng)。真正能避免抖動(dòng)的方案應(yīng)該是方案1，通過預(yù)熱的方式實(shí)現(xiàn)平滑發(fā)布或重啟。

tomcat啟動(dòng)時(shí)SessionIdGeneratorBase.createSecureRandom耗時(shí)5分鐘的問題 

通常情況下，tomcat啟動(dòng)只要2~3秒鐘，突然有一天，tomcat啟動(dòng)非常慢，要花5~6分鐘，查了很久，終于在這篇文章找到了解決方案，博主牛人啊。

Tomcat 8啟動(dòng)很慢，且日志上無任何錯(cuò)誤，在日志中查看到如下信息：
Log4j:[2015-10-29 15:47:11]  INFO ReadProperty:172 – Loading properties file from class path resource [resources/jdbc.properties]
Log4j:[2015-10-29 15:47:11]  INFO ReadProperty:172 – Loading properties file from class path resource [resources/common.properties]
29-Oct-2015 15:52:53.587 INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [342,445] milliseconds.

原因

Tomcat 7/8都使用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom類產(chǎn)生安全隨機(jī)類SecureRandom的實(shí)例作為會(huì)話ID，這里花去了342秒，也即接近6分鐘。

SHA1PRNG算法是基于SHA-1算法實(shí)現(xiàn)且保密性較強(qiáng)的偽隨機(jī)數(shù)生成器。

在SHA1PRNG中，有一個(gè)種子產(chǎn)生器，它根據(jù)配置執(zhí)行各種操作。

1）如果Java.security.egd 屬性或securerandom.source屬性指定的是”file:/dev/random”或”file:/dev/urandom”，那么JVM 會(huì)使用本地種子產(chǎn)生器NativeSeedGenerator，它會(huì)調(diào)用super()方法，即調(diào)用 SeedGenerator.URLSeedGenerator(/dev/random)方法進(jìn)行初始化。

2）如果java.security.egd屬性或securerandom.source屬性指定的是其它已存在的URL，那么會(huì)調(diào)用SeedGenerator.URLSeedGenerator(url)方法進(jìn)行初始化。

這就是為什么我們設(shè)置值為”file:///dev/urandom”或者值為”file:/./dev/random”都會(huì)起作用的原因。

在這個(gè)實(shí)現(xiàn)中，產(chǎn)生器會(huì)評估熵池（entropy pool）中的噪聲數(shù)量。隨機(jī)數(shù)是從熵池中進(jìn)行創(chuàng)建的。當(dāng)讀操作時(shí)，/dev/random設(shè)備會(huì)只返回熵池中噪聲的隨機(jī)字節(jié)。/dev/random非 常適合那些需要非常高質(zhì)量隨機(jī)性的場景，比如一次性的支付或生成密鑰的場景。

當(dāng)熵池為空時(shí)，來自/dev/random的讀操作將被阻塞，直到熵池收集到足夠的環(huán)境噪聲數(shù)據(jù)。這么做的目的是成為一個(gè)密碼安全的偽隨機(jī)數(shù)發(fā)生器，熵池要有盡可能大的輸出。對于生成高質(zhì)量的加密密鑰或者是需要長期保護(hù)的場景，一定要這么做。

那么什么是環(huán)境噪聲？

隨機(jī)數(shù)產(chǎn)生器會(huì)手??來自設(shè)備驅(qū)動(dòng)器和其它源的環(huán)境噪聲數(shù)據(jù)，并放入熵池中。產(chǎn)生器會(huì)評估熵池中的噪聲數(shù)據(jù)的數(shù)量。當(dāng)熵池為空時(shí)，這個(gè)噪聲數(shù)據(jù)的收集是比較花時(shí)間的。這就意味著，Tomcat在生產(chǎn)環(huán)境中使用熵池時(shí)，會(huì)被阻塞較長的時(shí)間。

解決

有兩種解決辦法：

1）在Tomcat環(huán)境中解決

可以通過配置JRE使用非阻塞的Entropy Source。

在catalina.sh中加入這么一行：-Djava.security.egd=file:/dev/./urandom 即可。

加入后再啟動(dòng)Tomcat，整個(gè)啟動(dòng)耗時(shí)下降到Server startup in 2912 ms。

2）在JVM環(huán)境中解決

打開$JAVA_PATH/jre/lib/security/java.security這個(gè)文件，找到下面的內(nèi)容：

securerandom.source=file:/dev/urandom

替換成
securerandom.source=file:/dev/./urandom

tomcat的缺省配置是不能長期穩(wěn)定的運(yùn)行的，也就是不適合生產(chǎn)環(huán)境，會(huì)出現(xiàn)死機(jī)的情況，讓他不斷的重啟。對于操作系統(tǒng)的優(yōu)化來說，是盡可能的提高內(nèi)存容量，提高cpu的頻率，保證文件系統(tǒng)的讀寫速率。

tomcat的優(yōu)化主要有三方面，分為系統(tǒng)優(yōu)化，tomcat自身優(yōu)化，java虛擬機(jī)（jvm）調(diào)優(yōu)，此處主要討論后兩種。

一、tomcat本身優(yōu)化

1 工作方式選擇

為了提升性能，首先就要對代碼進(jìn)行動(dòng)靜分離，讓 Tomcat 只負(fù)責(zé) jsp 文件的解析工作。如采用 Apache 和 Tomcat 的整合方式，他們之間的連接方案有三種選擇，JK、http_proxy 和 ajp_proxy。相對于 JK 的連接方式，后兩種在配置上比較簡單的，靈活性方面也一點(diǎn)都不遜色。但就穩(wěn)定性而言不像JK 這樣久經(jīng)考驗(yàn)，所以建議采用 JK 的連接方式。

2 connector連接器的工作方式

Tomcat 連接器的三種方式： bio、nio 和 apr，三種方式性能差別很大，apr 的性能最優(yōu)， bio 的性能最差。而 Tomcat 7 使用的 Connector  默認(rèn)就啟用的 Apr 協(xié)議，但需要系統(tǒng)安裝 Apr 庫，否則就會(huì)使用 bio 方式。

3配置文件優(yōu)化

(1) 線程池

tomcat為每個(gè)connector綁定一個(gè)線程池（默認(rèn)最大線程數(shù)為200）。

配置方式如下：

    <Executor name=”tomcatThreadPool” namePrefix=”catalina-exec-“

        maxThreads=”500″ minSpareThreads=”20″ maxSpareThreads=”50″ maxIdleTime=”60000″/>

    <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使用線程來處理請求，這個(gè)值表示tomcat可以創(chuàng)建的最大線程數(shù)，默認(rèn)值為200。

minSpareThreads：最小空閑線程數(shù)，tomcat啟動(dòng)時(shí)的初始化線程數(shù)，表示即便沒有請求，也要開啟這么多的線程等待，默認(rèn)值是10。

maxSpareThreads：最大空閑線程數(shù)，一旦空閑的線程數(shù)超過這個(gè)值，tomcat就會(huì)關(guān)閉不在需要的socket線程。

maxThreads的值越大就會(huì)越消耗內(nèi)存和CPU,因?yàn)镃PU疲于處理線程上下文切換，就沒有精力處理請求了。具體的值要取決于系統(tǒng)參數(shù)及實(shí)際應(yīng)用場景。線程池可以配置在tomcatTheadPool中，也可以直接配置在connector中，但不可以重復(fù)配置。

（2）URIEncoding：指定 Tomcat 容器的 URL 編碼格式，語言編碼格式這塊倒不如其它 WEB 服務(wù)器軟件配置方便，需要分別指定。

（3）connnectionTimeout： 網(wǎng)絡(luò)連接超時(shí)，單位：毫秒，設(shè)置為 0 表示永不超時(shí)，這樣設(shè)置有隱患的。通常可設(shè)置為 30000 毫秒，可根據(jù)檢測實(shí)際情況，適當(dāng)修改。

（4）enableLookups： 是否反查域名，以返回遠(yuǎn)程主機(jī)的主機(jī)名，取值為：true 或 false，如果設(shè)置為false，則直接返回IP地址，為了提高處理能力，應(yīng)設(shè)置為 false。

（5）disableUploadTimeout：上傳時(shí)是否使用超時(shí)機(jī)制。

（6）connectionUploadTimeout：上傳超時(shí)時(shí)間，畢竟文件上傳可能需要消耗更多的時(shí)間，這個(gè)根據(jù)你自己的業(yè)務(wù)需要自己調(diào)，以使Servlet有較長的時(shí)間來完成它的執(zhí)行，需要與上一個(gè)參數(shù)一起配合使用才會(huì)生效。

（7）acceptCount：指定當(dāng)所有可以使用的處理請求的線程數(shù)都被使用時(shí)，可傳入連接請求的最大隊(duì)列長度，超過這個(gè)數(shù)的請求將不予處理，默認(rèn)為100個(gè)。

（8）keepAliveTimeout：長連接最大保持時(shí)間（毫秒），表示在下次請求過來之前，Tomcat 保持該連接多久，默認(rèn)是使用 connectionTimeout 時(shí)間，-1 為不限制超時(shí)。

（9）maxKeepAliveRequests：表示在服務(wù)器關(guān)閉之前，該連接最大支持的請求數(shù)。超過該請求數(shù)的連接也將被關(guān)閉，1表示禁用，-1表示不限制個(gè)數(shù)，默認(rèn)100個(gè)，一般設(shè)置在100~200之間。

（10）compression：是否對響應(yīng)的數(shù)據(jù)進(jìn)行 GZIP 壓縮，off：表示禁止壓縮；on：表示允許壓縮（文本將被壓縮）、force：表示所有情況下都進(jìn)行壓縮，默認(rèn)值為off，壓縮數(shù)據(jù)后可以有效的減少頁面的大小，一般可以減小1/3左右，節(jié)省帶寬。

（11）compressionMinSize：表示壓縮響應(yīng)的最小值，只有當(dāng)響應(yīng)報(bào)文大小大于這個(gè)值的時(shí)候才會(huì)對報(bào)文進(jìn)行壓縮，如果開啟了壓縮功能，默認(rèn)值就是2048。

（12）compressableMimeType：壓縮類型，指定對哪些類型的文件進(jìn)行數(shù)據(jù)壓縮。

（13）noCompressionUserAgents=”gozilla, traviata”： 對于以下的瀏覽器，不啟用壓縮。

　　如果已經(jīng)對代碼進(jìn)行了動(dòng)靜分離，靜態(tài)頁面和圖片等數(shù)據(jù)就不需要 Tomcat 處理了，那么也就不需要配置在 Tomcat 中配置壓縮了。

以上是一些常用的配置參數(shù)屬性，當(dāng)然還有好多其它的參數(shù)設(shè)置，還可以繼續(xù)深入的優(yōu)化，HTTP Connector 與 AJP Connector 的參數(shù)屬性值，可以參考官方文檔的詳細(xì)說明：

https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html

二、JVM優(yōu)化

JVM常見配置

堆設(shè)置

-Xms:初始堆大小

-Xmx:最大堆大小

-XX:NewSize=n:設(shè)置年輕代大小

-XX:NewRatio=n:設(shè)置年輕代和年老代的比值。如:為3，表示年輕代與年老代比值為1：3，年輕代占整個(gè)年輕代年老代和的1/4

-XX:SurvivorRatio=n:年輕代中Eden區(qū)與兩個(gè)Survivor區(qū)的比值。注意Survivor區(qū)有兩個(gè)。如：3，表示Eden：Survivor=3：2，一個(gè)Survivor區(qū)占整個(gè)年輕代的1/5

-XX:MaxPermSize=n:設(shè)置持久代大小

收集器設(shè)置

-XX:+UseSerialGC:設(shè)置串行收集器

-XX:+UseParallelGC:設(shè)置并行收集器

-XX:+UseParalledlOldGC:設(shè)置并行年老代收集器

-XX:+UseConcMarkSweepGC:設(shè)置并發(fā)收集器

垃圾回收統(tǒng)計(jì)信息

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

并行收集器設(shè)置

-XX:ParallelGCThreads=n:設(shè)置并行收集器收集時(shí)使用的CPU數(shù)。并行收集線程數(shù)。

-XX:MaxGCPauseMillis=n:設(shè)置并行收集最大暫停時(shí)間

-XX:GCTimeRatio=n:設(shè)置垃圾回收時(shí)間占程序運(yùn)行時(shí)間的百分比。公式為1/(1+n)

并發(fā)收集器設(shè)置

-XX:+CMSIncrementalMode:設(shè)置為增量模式。適用于單CPU情況。

-XX:ParallelGCThreads=n:設(shè)置并發(fā)收集器年輕代收集方式為并行收集時(shí)，使用的CPU數(shù)。并行收集線程數(shù)。

常見的內(nèi)存溢出有以下兩種:

Java.lang.OutOfMemoryError: PermGen space

java.lang.OutOfMemoryError: Java heap space

這里以tomcat環(huán)境為例

一、java.lang.OutOfMemoryError: PermGen space

PermGen space的全稱是Permanent Generation space,是指內(nèi)存的永久保存區(qū)域,

這塊內(nèi)存主要是被JVM存放Class和Meta信息的,Class在被Loader時(shí)就會(huì)被放到PermGen space中,它和存放類實(shí)例(Instance)的Heap區(qū)域不同,GC(Garbage Collection)不會(huì)在主程序運(yùn)行期對PermGen space進(jìn)行清理，所以如果你的應(yīng)用中有很多CLASS的話,就很可能出現(xiàn)PermGen space錯(cuò)誤,這種錯(cuò)誤常見在web服務(wù)器對JSP進(jìn)行pre compile的時(shí)候。如果你的WEB APP下都用了大量的第三方j(luò)ar, 其大小超過了jvm默認(rèn)的大小(4M)那么就會(huì)產(chǎn)生此錯(cuò)誤信息了。
解決方法： 手動(dòng)設(shè)置MaxPermSize大小
建議：將相同的第三方j(luò)ar文件移置到tomcat/shared/lib目錄下，這樣可以達(dá)到減少jar 文檔重復(fù)占用內(nèi)存的目的。

二、java.lang.OutOfMemoryError: Java heap space
JVM堆的設(shè)置是指java程序運(yùn)行過程中JVM可以調(diào)配使用的內(nèi)存空間的設(shè)置.JVM在啟動(dòng)的時(shí)候會(huì)自動(dòng)設(shè)置Heap size的值，其初始空間(即-Xms)是物理內(nèi)存的1/64，最大空間(-Xmx)是物理內(nèi)存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項(xiàng)可進(jìn)行設(shè)置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
提示：在JVM中如果98％的時(shí)間是用于GC且可用的Heap size 不足2％的時(shí)候?qū)伋龃水惓Ｐ畔ⅰ?br />提示：Heap Size 最大不要超過可用物理內(nèi)存的80％，一般的要將-Xms和-Xmx選項(xiàng)設(shè)置為相同，而-Xmn為1/4的-Xmx值。
解決方法：手動(dòng)設(shè)置Heap size

Linux下修改JVM內(nèi)存大小:

要添加在tomcat 的bin 下catalina.sh 里，位置cygwin=false前 。

# OS specific support. $var _must_ be set to either true or false.
JAVA_OPTS=”-Xms256m -Xmx512m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m”
cygwin=false

Windows下修改JVM內(nèi)存大小:

情況一:解壓版本的Tomcat, 要通過startup.bat啟動(dòng)tomcat才能加載配置

要添加在tomcat 的bin 下catalina.bat 里

rem Guess CATALINA_HOME if not defined
set CURRENT_DIR=%cd%后面添加,紅色的為新添加的.

set JAVA_OPTS=-Xms256m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m -Djava.awt.headless=true

情況二:安裝版的Tomcat下沒有catalina.bat

windows服務(wù)執(zhí)行的是bin/tomcat.exe.他讀取注冊表中的值,而不是catalina.bat的設(shè)置.

修改注冊表HKEY_LOCAL_MACHINE/SOFTWARE/Apache Software Foundation/Tomcat Service Manager/Tomcat5/Parameters/JavaOptions
原值為
-Dcatalina.home=”C:/ApacheGroup/Tomcat 5.0″
-Djava.endorsed.dirs=”C:/ApacheGroup/Tomcat 5.0/common/endorsed”
-Xrs

加入 -Xms300m -Xmx350m
重起tomcat服務(wù),設(shè)置生效

如何設(shè)置Tomcat的JVM虛擬機(jī)內(nèi)存大小

可以給Java虛擬機(jī)設(shè)置使用的內(nèi)存，但是如果你的選擇不對的話，虛擬機(jī)不會(huì)補(bǔ)償?？赏ㄟ^命令行的方式改變虛擬機(jī)使用內(nèi)存的大小。如下表所示有兩個(gè)參數(shù)用來設(shè)置虛擬機(jī)使用內(nèi)存的大小。

-Xms
JVM初始化堆的大小

-Xmx
JVM堆的最大值

這兩個(gè)值的大小一般根據(jù)需要進(jìn)行設(shè)置。初始化堆的大小執(zhí)行了虛擬機(jī)在啟動(dòng)時(shí)向系統(tǒng)申請的內(nèi)存的大小。一般而言，這個(gè)參數(shù)不重要。但是有的應(yīng)用程序在大負(fù)載的 情況下會(huì)急劇地占用更多的內(nèi)存，此時(shí)這個(gè)參數(shù)就是顯得非常重要，如果虛擬機(jī)啟動(dòng)時(shí)設(shè)置使用的內(nèi)存比較小而在這種情況下有許多對象進(jìn)行初始化，虛擬機(jī)就必須 重復(fù)地增加內(nèi)存來滿足使用。由于這種原因，我們一般把-Xms和-Xmx設(shè)為一樣大，而堆的最大值受限于系統(tǒng)使用的物理內(nèi)存。一般使用數(shù)據(jù)量較大的應(yīng)用程 序會(huì)使用持久對象，內(nèi)存使用有可能迅速地增長。當(dāng)應(yīng)用程序需要的內(nèi)存超出堆的最大值時(shí)虛擬機(jī)就會(huì)提示內(nèi)存溢出，并且導(dǎo)致應(yīng)用服務(wù)崩潰。因此一般建議堆的最大值設(shè)置為可用內(nèi)存的最大值的80%。

Tomcat默認(rèn)可以使用的內(nèi)存為128MB，在較大型的應(yīng)用項(xiàng)目中，這點(diǎn)內(nèi)存是不夠的，需要調(diào)大。
Windows下，在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下設(shè)置：
JAVA_OPTS=’-Xms【初始化內(nèi)存大小】 -Xmx【可以使用的最大內(nèi)存】’
需要把這個(gè)兩個(gè)參數(shù)值調(diào)大。例如：
JAVA_OPTS=’-Xms256m -Xmx512m’
表示初始化內(nèi)存為256MB，可以使用的最大內(nèi)存為512MB。
另 外需要考慮的是Java提供的垃圾回收機(jī)制。虛擬機(jī)的堆大小決定了虛擬機(jī)花費(fèi)在收集垃圾上的時(shí)間和頻度。收集垃圾可以接受的速度與應(yīng)用有關(guān)，應(yīng)該通過分析 實(shí)際的垃圾收集的時(shí)間和頻率來調(diào)整。如果堆的大小很大，那么完全垃圾收集就會(huì)很慢，但是頻度會(huì)降低。如果你把堆的大小和內(nèi)存的需要一致，完全收集就很快， 但是會(huì)更加頻繁。調(diào)整堆大小的的目的是最小化垃圾收集的時(shí)間，以在特定的時(shí)間內(nèi)最大化處理客戶的請求。在基準(zhǔn)測試的時(shí)候，為保證最好的性能，要把堆的大小 設(shè)大，保證垃圾收集不在整個(gè)基準(zhǔn)測試的過程中出現(xiàn)。

如果系統(tǒng)花費(fèi)很多的時(shí)間收集垃圾，請減小堆大小。一次完全的垃圾收集應(yīng)該不超過 3-5 秒。如果垃圾收集成為瓶頸，那么需要指定代的大小，檢查垃圾收集的詳細(xì)輸出，研究 垃圾收集參數(shù)對性能的影響。一般說來，你應(yīng)該使用物理內(nèi)存的 80% 作為堆大小。當(dāng)增加處理器時(shí)，記得增加內(nèi)存，因?yàn)榉峙淇梢圆⑿羞M(jìn)行，而垃圾收集不是并行的。