Tomcat性能優化及JVM內存工做原理

Java性能優化原則：代碼運算性能、內存回收、應用配置（影響Java程序主要緣由是垃圾回收，下面會重點介紹這方面）

代碼層優化：避免過多循環嵌套、調用和複雜邏輯。

 

Tomcat調優主要內容以下：

1、增長最大鏈接數

2、調整工做模式

3、啓用gzip壓縮

4、調整JVM內存大小

5、做爲Web服務器時，與Apache整合或Nginx

6、合理選擇垃圾回收算法

7、儘可能使用較新JDK版本

 

生產配置實例：

<Connectorport="8080"protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="1000" minSpareThreads="100" maxSpareThreads="200" acceptCount="900" disableUploadTimeout="true" connectionTimeout="20000" URIEncoding="UTF-8" enableLookups="false" redirectPort="8443" compression="on" compressionMinSize="1024" compressableMimeType="text/html,text/xml,text/css,text/javascript"/>

 

參數說明：

org.apache.coyote.http11.Http11NioProtocol：調整工做模式爲Nio

 

maxThreads：最大線程數，默認150。增大值避免隊列請求過多，致使響應緩慢。

minSpareThreads：最小空閒線程數。

maxSpareThreads：最大空閒線程數，若是超過這個值，會關閉無用的線程。

acceptCount：當處理請求超過此值時，將後來請求放到隊列中等待。

disableUploadTimeout：禁用上傳超時時間

connectionTimeout：鏈接超時，單位毫秒，0表明不限制

URIEncoding：URI地址編碼使用UTF-8

enableLookups：關閉dns解析，提升響應時間

compression：啓用壓縮功能

compressionMinSize：最小壓縮大小，單位Byte

compressableMimeType：壓縮的文件類型

 

Tomcat有三種工做模式：Bio、Nio和Apr，下面簡單瞭解下他們工做原理：

Bio(Blocking I/O)：默認工做模式，阻塞式I/O操做，沒有任何優化技術處理，性能比較低。

Nio(New I/O or Non-Blocking)：非阻塞式I/O操做，有Bio有更好的併發處理性能。

Apr(Apache Portable Runtime，Apache可移植運行庫)：首選工做模式，主要爲上層的應用程序提供一個能夠跨越多操做系統平臺使用的底層支持接口庫。

tomcat利用基於Apr庫tomcat-native來實現操做系統級別控制，提供一種優化技術和非阻塞式I/O操做，大大提升併發處理能力。可是須要安裝apr和tomcat-native庫。

工做模式原理涉及到了網絡I/O模型知識：

 

阻塞式I/O模型：應用進程調用recv函數系統調用時，若是等待要操做的數據沒有發送到內核緩衝區，應用進程將阻塞，不能接收其餘請求。反之，內核recv端緩衝區有數據，內核會把數據複製到用戶空間解除阻塞，繼續處理下一個請求。（內核空間(緩衝區)--用戶空間(系統調用)）

非阻塞式I/O模型：應用進程設置成非阻塞模式，若是要操做的數據沒有發送到內核緩衝區，recv系統調用返回一個錯誤，應用進程利用輪詢方式不斷檢查此操做是否就緒，若是緩衝區中有數據則返回，I/O操做同時不會阻塞應用進程，期間會繼續處理新請求。

I/O複用模型：阻塞發生在select/poll的系統調用上，而不是阻塞在實際的I/O系統調用上。能同時處理多個操做，並檢查操做是否就緒，select/epoll函數發現有數據就緒後，就經過實際的I/O操做將數據複製到應用進程的緩衝區中。

異步I/O模型：應用進程通知內核開始一個異步I/O操做，並讓內核在整個操做（包括數據複製緩衝區）完成後通知應用進程，期間會繼續處理新請求。

I/O操做分爲兩個階段：第一個階段等待數據可用，第二個階段將數據從內核複製到用戶空間。

前三種模型的區別：第一階段阻塞式I/O阻塞在I/O操做上，非阻塞式I/O輪詢，I/O複用阻塞在select/poll或epoll上。第二階段都是同樣的。而異步I/O的兩個階段都不會阻塞進程。

Java性能問題主要來自於JVM，JVM GC也比較複雜，再調優以前瞭解下相關基礎概念是必要的：

1）JVM內存劃分分爲年輕代（Young Generation）、老年代（Old Generation）、永久代（Permanent Generation）。

2）年輕代又分爲Eden和Survivor區。Survivor區由FromSpace和ToSpace組成。Eden區佔大容量，Survivor兩個區佔小容量，默認比例大概是8:2。

3）堆內存（Heap）=年輕代+老年代。非堆內存=永久代。

4）堆內存用途：存放的是對象，垃圾收集器就是收集這些對象，而後根據GC算法回收。

5）非堆內存用途：JVM自己使用，存放一些類、方法、常量、屬性等。

6）年輕代：新生成的對象首先放到年輕代的Eden區中，當Eden滿時，通過GC後，還存活的對象被複制到Survivor區的FromSpace中，若是Survivor區滿時，會再被複制到Survivor區的ToSpace區。若是還有存活對象，會再被複制到老年代。

7）老年代：在年輕代中通過GC後還存活的對象會被複制到老年代中。當老年代空間不足時，JVM會對老年代進行徹底的垃圾回收（Full GC）。若是GC後，仍是沒法存放從Survivor區複製過來的對象，就會出現OOM（Out of Memory）。

8）永久代：也稱爲方法區，存放靜態類型數據，好比類、方法、屬性等。

垃圾回收（GC，Garbage Collection）算法：

1）標記-清除（Mark-Sweep）

GC分爲兩個階段，標記和清除。首先標記全部可回收的對象，在標記完成後統一回收全部被標記的對象。同時會產生不連續的內存碎片。碎片過多會致使之後程序運行時須要分配較大對象時，沒法找到足夠的連續內存，而不得已再次觸發GC。

2）複製（Copy）

將內存按容量劃分爲兩塊，每次只使用其中一塊。當這一塊內存用完了，就將存活的對象複製到另外一塊上，而後再把已使用的內存空間一次清理掉。這樣使得每次都是對半個內存區回收，也不用考慮內存碎片問題，簡單高效。缺點須要兩倍的內存空間。

3）標記-整理（Mark-Compact）

也分爲兩個階段，首先標記可回收的對象，再將存活的對象都向一端移動，而後清理掉邊界之外的內存。此方法避免標記-清除算法的碎片問題，同時也避免了複製算法的空間問題。

通常年輕代中執行GC後，會有少許的對象存活，就會選用複製算法，只要付出少許的存活對象複製成本就能夠完成收集。而老年代中由於對象存活率高，沒有額外過多內存空間分配，就須要使用標記-清理或者標記-整理算法來進行回收。

垃圾收集器：

1）串行收集器（Serial）

比較老的收集器，單線程。收集時，必須暫停應用的工做線程，直到收集結束。

2）並行收集器（Parallel）

多條垃圾收集線程並行工做，在多核CPU下效率更高，應用線程仍然處於等待狀態。

3）CMS收集器（Concurrent Mark Sweep）

CMS收集器是縮短暫停應用時間爲目標而設計的，是基於標記-清除算法實現，整個過程分爲4個步驟，包括：

• 初始標記（Initial Mark）

• 併發標記（Concurrent Mark）

• 從新標記（Remark）

• 併發清除（Concurrent Sweep）

其中，初始標記、從新標記這兩個步驟仍然須要暫停應用線程。初始標記只是標記一下GC Roots能直接關聯到的對象，速度很快，併發標記階段是標記可回收對象，而從新標記階段則是爲了修正併發標記期間因用戶程序繼續運做致使標記產生變更的那一部分對象的標記記錄，這個階段暫停時間比初始標記階段稍長一點，但遠比並發標記時間段。

因爲整個過程當中消耗最長的併發標記和併發清除過程收集器線程均可以與用戶線程一塊兒工做，因此，CMS收集器內存回收與用戶一塊兒併發執行的，大大減小了暫停時間。

4）G1收集器（Garbage First）

G1收集器將堆內存劃分多個大小相等的獨立區域（Region），而且能預測暫停時間，能預測緣由它能避免對整個堆進行全區收集。G1跟蹤各個Region裏的垃圾堆積價值大小（所得到空間大小以及回收所需時間），在後臺維護一個優先列表，每次根據容許的收集時間，優先回收價值最大的Region，從而保證了再有限時間內得到更高的收集效率。

G1收集器工做工程分爲4個步驟，包括：

• 初始標記（Initial Mark）

• 併發標記（Concurrent Mark）

• 最終標記（Final Mark）

• 篩選回收（Live Data Counting and Evacuation）

初始標記與CMS同樣，標記一下GC Roots能直接關聯到的對象。併發標記從GC Root開始標記存活對象，這個階段耗時比較長，但也能夠與應用線程併發執行。而最終標記也是爲了修正在併發標記期間因用戶程序繼續運做而致使標記產生變化的那一部分標記記錄。最後在篩選回收階段對各個Region回收價值和成本進行排序，根據用戶所指望的GC暫停時間來執行回收。

 

瞭解了JVM基礎知識，下面配置下相關Java參數，將下面一段放到catalina.sh裏面：

 

JAVA_OPTS="-server -Xms1024m -Xmx1536m -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC -XX:+UseParallelGCThreads=8 XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:-PrintGC -XX:-PrintGCDetails -XX:-PrintGCTimeStamps -Xloggc:../logs/gc.log"

參數	描述
-Xms	堆內存初始大小，單位m、g
-Xmx	堆內存最大容許大小，通常不要大於物理內存的80%
-XX:PermSize	非堆內存初始大小，通常應用設置初始化200m，最大1024m就夠了
-XX:MaxPermSize	非堆內存最大容許大小
-XX:+UseParallelGCThreads=8	並行收集器線程數，同時有多少個線程進行垃圾回收，通常與CPU數量相等
-XX:+UseParallelOldGC	指定老年代爲並行收集
-XX:+UseConcMarkSweepGC	CMS收集器（併發收集器）
-XX:+UseCMSCompactAtFullCollection	開啓內存空間壓縮和整理，防止過多內存碎片
-XX:CMSFullGCsBeforeCompaction=0	表示多少次Full GC後開始壓縮和整理，0表示每次Full GC後當即執行壓縮和整理
-XX:CMSInitiatingOccupancyFraction=80%	表示老年代內存空間使用80%時開始執行CMS收集，防止過多的Full GC

注意：不是JVM內存設置越大越好，具體仍是根據項目對象實際佔用內存大小而定，能夠經過Java自帶的分析工具來查看。若是設置過大，會增長回收時間，從而增長暫停應用時間。

 

博客地址：http://lizhenliang.blog.51cto.com

QQ羣：323779636（Shell/Python運維開發羣）

 

gzip壓縮做用：節省服務器流量和提升網站訪問速度。客戶端請求服務器資源後，服務器將資源文件壓縮，再返回給客戶端，由客戶端的瀏覽器負責解壓縮並瀏覽。

 

使用Apache與Tomcat整合，由於Tomcat處理靜態文件能力遠不足Apache，所以讓Apache來處理靜態文件，Tomcat處理動態jsp文件，能夠有效提升處理速度。

在集羣架構下，會涉及到一個問題，怎麼保存Session？

TomcatSessionID持久化三種方法：

   Session粘性：經過瀏覽器Cookie綁定SessionID，經過sticky模式將同一Session請求分配到同一Tomcat上。

   Session複製：Tomcat經過廣播形式將Session同步到其餘Tomcat節點，而且Linux下要手動開啓開放廣播地址。不易後端節點過多

 Session保存數據庫（memcache、redis）：將SessionID保存在共享的數據庫中。

 

 

OOM（Out of Memory）異經常見有如下幾個緣由：

1）老年代內存不足：java.lang.OutOfMemoryError:Javaheapspace

2）永久代內存不足：java.lang.OutOfMemoryError:PermGenspace

3）代碼bug，佔用內存沒法及時回收。

 

前兩種狀況經過加大內存容量，能夠獲得解決。若是是代碼bug，就要經過jstack、jmap、jstat自帶的工具分析問題，定位到相關代碼，讓開發解決。