Tomcat的效能優化及JVM記憶體工作原理
技術標籤：技術
JVM效能優化原則：程式碼運算效能、記憶體回收、應用配置（影響Java程式主要原因是垃圾回收機制）
程式碼層優化：避免過多迴圈巢狀、呼叫和複雜邏輯。
Tomcat調優主要內容
1、增加最大連線數
2、調整工作模式
3、啟用gzip壓縮
4、調整JVM記憶體大小
5、作為web伺服器時、無Apache整合或者nginx
6、合理選擇垃圾回收演算法
7、儘量使用較新的JDK版本
生產配置例項
<Connectorport="8080"protocol="org.apache.coyote.http11.Http11NioProtocol" #調整工作模式為NIO maxThreads="1000" #最大執行緒數，預設150。這裡這是1000是為了避免佇列請求過多，導致響應過慢 minSpareThreads="100" #最小空閒執行緒數 maxSpareThreads="200" #最大空閒執行緒數，如果是超過這個數值，會自動關閉無用的執行緒 acceptCount="900" #當請求超過該值，便會將請求放到後面的佇列中等待 disableUploadTimeout="true" #禁止上傳超時時間 connectionTimeout="20000" #連線超時，單位毫秒，0代表不限制 URIEncoding="UTF-8" #URL地址編碼使用UTF-8 enableLookups="false" #關閉DNS解析，提高相應時間 redirectPort="8443" #重定向埠 compression="on" #啟用壓縮功能 compressionMinSize="1024" #最小壓縮大小，單位為Byte（位元組） compressableMimeType="text/html,text/xml,text/css,text/javascript"/> #可支援壓縮的檔案型別
Tomcat的執行模式
Tomcat有三種工作模式：Bio、Nio和Apr
Bio（Blocking I/O）：預設工作模式，一個執行緒處理一個請求，在高併發的的環境下，執行緒數較多，浪費資源，沒有任何優化技術處理，效能比較低
Nio（New I/O or Non-Blocking）:非阻塞式I/O模式，NIO主要是利用Java的非同步I/O處理，可以通過少量的執行緒處理大量的請求
Apr（Apache Portable Runtime，Apathe可移植執行庫）：Tomcat執行高併發應用的首選工作模式，APR是從作業系統層面解決IO阻塞問題，大幅度提高伺服器的處理和響應效能
啟動Apr模式的方法
1）安裝依賴庫 [[email protected] ~]# yum install -y apr-devel openssl-devel gcc make [[email protected] ~]# rpm -qa | grep openssl openssl-libs-1.0.2k-12.el7.x86_64 openssl-devel-1.0.2k-12.el7.x86_64 openssl-1.0.2k-12.el7.x86_64 2）安裝apr動態庫 在安裝apr動態庫之前，需要java環境，在這裡，有個坑需要注意，那就是ap在預編譯的之後一定要有jdk環境，我們一般安裝都是直接yum install -y java一條命令搞定，但是呢，在這裡是不支援的， 需要手動配置才行，否則便會報錯
配置環境變數
export JAVA_HOME=/usr/java/jdk1.7.0_65
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH:$HOMR/bin
下載Tomcat-native包
[[email protected] ~]# wget https://mirrors.tuna.tsinghua.edu.cn/apache/tomcat/tomcat-connectors/native/1.2.17/source/tomcat-native-1.2.17-src.tar.gz #下載包
[[email protected] ~]# tar zxvf tomcat-native-1.2.17-src.tar.gz -C /usr/local/tomcat/bin/ #解壓
[[email protected] ~]# cd /usr/local/tomcat/bin/tomcat-native-1.2.17-src/native/ #移動到指定目錄
[[email protected] native]# make && make install #編譯安裝
[[email protected] native]# ll /usr/local/apr/lib/ #檢視是否成功
total 3268
-rw-r--r-- 1 root root 2121194 Jun 30 16:28 libtcnative-1.a
-rwxr-xr-x 1 root root 1027 Jun 30 16:28 libtcnative-1.la
lrwxrwxrwx 1 root root 23 Jun 30 16:28 libtcnative-1.so -> libtcnative-1.so.0.2.17
lrwxrwxrwx 1 root root 23 Jun 30 16:28 libtcnative-1.so.0 -> libtcnative-1.so.0.2.17
-rwxr-xr-x 1 root root 1204408 Jun 30 16:28 libtcnative-1.so.0.2.17
drwxr-xr-x 2 root root 4096 Jun 30 16:28 pkgconfig
配置APR本地庫到系統共享庫搜尋路徑 # vim /usr/local/tomcat/bin/catalina.sh
JAVA_OPTS="$JAVA_OPTS -Djava.library.path=/usr/local/apr/lib/" #在虛擬機器啟動引數JAVA_OPTS中新增java.library.path引數，指定apr庫的路徑
實現原理：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記憶體劃分為年輕代、老年代、永久代。
2、年輕代又分為： Eden和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）
-
初始標記（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自帶的分析工具來檢視。如果設定過大，會增加回收時間，從而增加暫停應用時間。
gzip壓縮作用：節省伺服器流量和提高網站訪問速度。客戶端請求伺服器資源後，伺服器將資原始檔壓縮，再返回給客戶端，由客戶端的瀏覽器負責解壓縮並瀏覽。
使用Apache與Tomcat整合，因為Tomcat處理靜態檔案能力遠不足Apache，因此讓Apache來處理靜態檔案，Tomcat處理動態jsp檔案，可以有效提高處理速度。
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自帶的工具分析問題，定位到相關程式碼，讓開發解決。