在工做中,做爲 Java 開發的程序員,Tomcat 服務器是你們經常使用的,也是不少公司如今正在用的。可是,在系統併發量比較大的狀況下,Tomcat 就會出現卡死和自動關閉等問題。如何優化 Tomcat,讓它更高效的運行就成了問題,在本篇小編中,我將爲你分享如何更好的提高 Tomcat 性能。nginx
找到Tomcat根目錄下的conf目錄,修改server.xml文件的內容。小編這裏也對應整理了一份JVM調優和實戰400多頁學習筆記,關注公衆號:麒麟改bug,獲取詳細PDF對於這部分的調優,我所瞭解到的就是無非設置一下Tomcat服務器的最大併發數和Tomcat初始化時建立的線程數的設置,固然還有其餘一些性能調優的設置,下圖是我根據我機子的性能設置的一些參數值,給各位詳細解釋一下吧:程序員
一、URIEncoding=「UTF-8」:設置Tomcat的字符集。這種配置咱們通常是不會設置的,由於關於亂碼的轉換咱們會在具體項目中具體處理,直接修改Tomcat的字符集未免過於太死板。tomcat
二、maxThreads=「300」:設置當前Tomcat的最大併發數。Tomcat默認配置的最大請求數是150個,即同時能支持150個併發。可是在實際運用中,最大併發數與硬件性能和CPU數量都有很大關係的,更好的硬件、更高的處理器都會使Tomcat支持更多的併發數。若是通常在實際開發中,當某個應用擁有 250 個以上併發的時候,都會考慮到應用服務器的集羣。服務器
三、minSpareThreads=「50」:設置當前Tomcat初始化時建立的線程數,默認值爲25。微信
四、acceptCount=「250」:當同時鏈接的人數達到maxThreads參數設置的值時,還能夠接收排隊的鏈接數量,超過這個鏈接的則直接返回拒絕鏈接。指定當任何可以使用的處理請求的線程數都被使用時,可以放處處理隊列中的請求數,超過這個數的請求將不予處理。默認值爲100。在實際應用中,若是想加大Tomcat的併發數 ,應該同時加大acceptCount和maxThreads的值。整編:微信公衆號,搜雲庫技術團隊,ID:souyunku多線程
五、enableLookups=「false」:是否開啓域名反查,通常設置爲false來提升處理能力,它的取值還有true,通常不多使用。併發
六、maxKeepAliveRequests=「1」:nginx動態的轉給tomcat,nginx是不能keepalive的,而tomcat端默認開啓了keepalive,會等待keepalive的timeout,默認不設置就是使用connectionTimeout。因此必須設置tomcat的超時時間,並關閉tomcat的keepalive。不然會產生大量tomcat的socket timewait。socket
maxKeepAliveRequests=」1」就能夠避免tomcat產生大量的TIME_WAIT鏈接,從而從必定程度上避免tomcat假死。ide
Tomcat自己仍是運行在JVM上的,經過對JVM參數的調整咱們可使Tomcat擁有更好的性能。目前針對JVM的調優主要有兩個方面:內存調優和垃圾回收策略調優。性能
找到Tomcat根目錄下的bin目錄,設置catalina.sh文件中JAVA_OPTS變量便可,由於後面的啓動參數會把JAVA_OPTS做爲JVM的啓動參數來處理。再說Java虛擬機的內存結構是有點複雜的,相信不少人在理解上都是很抽象的,它主要分爲堆、棧、方法區和垃圾回收系統等幾個部分組成,下面是我從網上扒的內存結構圖:
內存調優這塊呢,無非就是經過修改它們各自的內存空間的大小,使應用可以更加合理的運用,下圖是我根據我機子的性能設置的參數,給各位詳細解釋一下各個參數的含義吧:
一、-Xmx512m:設置Java虛擬機的堆的最大可用內存大小,單位:兆(m),整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代通常固定大小爲64m。堆的不一樣分佈狀況,對系統會產生必定的影響。儘量將對象預留在新生代,減小老年代GC的次數(一般老年回收起來比較慢)。
實際工做中,一般將堆的初始值和最大值設置相等,這樣能夠減小程序運行時進行的垃圾回收次數和空間擴展,從而提升程序性能。整編:微信公衆號,搜雲庫技術團隊,ID:souyunku
二、-Xms512m:設置Java虛擬機的堆的初始值內存大小,單位:兆(m),此值能夠設置與-Xmx相同,以免每次垃圾回收完成後JVM從新分配內存。
三、-Xmn170m:設置年輕代內存大小,單位:兆(m),此值對系統性能影響較大,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,上面也說了,持久代通常固定的內存大小爲64m。
八、-XX:MaxTenuringThreshold=0:設置垃圾最大年齡。
若是設置爲0的話,則年輕代對象不通過Survivor區,直接進入年老代。對於年老代比較多的應用,能夠提升效率。
若是將此值設置爲一個較大值,則年輕代對象會在Survivor區進行屢次複製,這樣能夠增長對象再年輕代的存活時間,增長在年輕代即被回收的概論。
找到Tomcat根目錄下的bin目錄,也是設置catalina.sh文件中JAVA_OPTS變量便可。咱們都知道Java虛擬機都有默認的垃圾回收機制,可是不一樣的垃圾回收機制的效率是不一樣的,正是由於這點咱們才常常對Java虛擬機的垃圾回收策略進行相應的調整。下面也是經過個人一些需求來配置的垃圾回收策略:
Java虛擬機的垃圾回收策略通常分爲:串行收集器、並行收集器和併發收集器。
一、-XX:+UseSerialGC:表明垃圾回收策略爲串行收集器,即在整個掃描和複製過程採用單線程的方式來進行,適用於單CPU、新生代空間較小及對暫停時間要求不是很是高的應用上,是client級別默認的GC方式,主要在JDK1.5以前的垃圾回收方式。
一、-XX:+UseParallelGC:表明垃圾回收策略爲並行收集器(吞吐量優先),即在整個掃描和複製過程採用多線程的方式來進行,適用於多CPU、對暫停時間要求較短的應用上,是server級別默認採用的GC方式。此配置僅對年輕代有效。該配置只能讓年輕代使用併發收集,而年老代仍舊使用串行收集。整編:微信公衆號,搜雲庫技術團隊,ID:souyunku
二、-XX:ParallelGCThreads=4:配置並行收集器的線程數,即:同時多少個線程一塊兒進行垃圾回收。此值最好配置與處理器數目相等。
三、-XX:+UseParallelOldGC:配置年老代垃圾收集方式爲並行收集。JDK6.0支持對年老代並行收集 。
四、-XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間,若是沒法知足此時間,JVM會自動調全年輕代大小,以知足此值。
五、-XX:+UseAdaptiveSizePolicy:設置此選項後,並行收集器會自動選擇年輕代區大小和相應的Survivor區比例,以達到目標系統規定的最低相應時間或者收集頻率等,此值建議使用並行收集器時,一直打開。
併發收集器:
一、-XX:+UseConcMarkSweepGC:表明垃圾回收策略爲併發收集器。
好了,到此我對虛擬機的垃圾回收策略總結就這麼多,小編這裏也對應整理了一份JVM調優和實戰400多頁學習筆記,關注公衆號:麒麟改bug,獲取詳細PDF,仍是這句話:優化的學習一直在路上,下面還有一張從其餘博客中摘錄的圖,聽說以上三種GC機制是須要配合使用的。