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）安裝依賴庫
[root@tomcat ~]# yum install -y apr-devel openssl-devel gcc make
[root@tomcat ~]# 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包
地址：https://archive.apache.org/dist/tomcat/tomcat-connectors/native/1.2.17/source/tomcat-native-1.2.17-src.tar.gz
[root@tomcat ~]# wget https://mirrors.tuna.tsinghua.edu.cn/apache/tomcat/tomcat-connectors/native/1.2.17/source/tomcat-native-1.2.17-src.tar.gz #下載包
[root@tomcat ~]# tar zxvf tomcat-native-1.2.17-src.tar.gz -C /usr/local/tomcat/bin/ #解壓
[root@tomcat ~]# cd /usr/local/tomcat/bin/tomcat-native-1.2.17-src/native/ #移動到指定目錄
[root@tomcat native]# make && make install #編譯安裝
[root@tomcat 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自帶的工具分析問題，定位到相關代碼，讓開發解決，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/142325.html
標籤：Linux
上一篇：cat - EOF標志的使用