摘要：運(yùn)行模式分種模式一般使用模式效率低對(duì)系統(tǒng)配置有一些比較高的要求確認(rèn)的運(yùn)行模式配置文件關(guān)鍵配置最大線程數(shù)默認(rèn)是最小活躍線程數(shù)默認(rèn)是最大的等待隊(duì)列個(gè)數(shù)，超過(guò)則請(qǐng)求拒絕默認(rèn)值是，一般不改變。

Tomcat作為Web應(yīng)用的服務(wù)器，目前絕大多數(shù)公司都是用其作為應(yīng)用服務(wù)器的，應(yīng)用服務(wù)器的執(zhí)行效率會(huì)影響系統(tǒng)執(zhí)行，這里會(huì)講Tomcat怎樣進(jìn)行配置能提高處理性能。另外必須提到對(duì)應(yīng)的JVM參數(shù)的優(yōu)化的一些經(jīng)驗(yàn)。

分3種模式: bio,nio,apr 一般使用nio模式
bio效率低,apr對(duì)系統(tǒng)配置有一些比較高的要求

配置文件 server.xml

maxThreads

最大線程數(shù), 默認(rèn)是200

minSpareThread

最小活躍線程數(shù), 默認(rèn)是25

maxQueueSize

最大的等待隊(duì)列個(gè)數(shù)，超過(guò)則請(qǐng)求拒絕默認(rèn)值是Integer.MAX_VALUE ，一般不改變。在某些緊急狀態(tài)修復(fù)問(wèn)題需要調(diào)整

連接器（Connector）

Connector是連接器，負(fù)責(zé)接收客戶的請(qǐng)求，以及向客戶端回送響應(yīng)的消息。所以Connector的優(yōu)化是重要部分。默認(rèn)情況下 Tomcat只支持200線程訪問(wèn)，超過(guò)這個(gè)數(shù)量的連接將被等待甚至超時(shí)放棄，所以我們需要提高這方面的處理能力。

org.apache.coyote.http11.Http11Protocol - 阻塞式的Java連接器
org.apache.coyote.http11.Http11NioProtocol - 不阻塞Java連接器
org.apache.coyote.http11.Http11AprProtocol - APR / native 連接器
選擇不阻塞Java連接器

若是你想request.getRemoteHost()的調(diào)用履行，以便返回的長(zhǎng)途客戶端的實(shí)際主機(jī)名的DNS查詢，則設(shè)置為true。設(shè)置為false時(shí)跳過(guò)DNS查找，并返回字符串的IP地址（從而提高性能）。默認(rèn)場(chǎng)景下，禁用DNS查找

設(shè)置成on,開啟壓縮

使用Nginx+tomcat的架構(gòu)，用不著AJP協(xié)議，所以把AJP連接器禁用
server.xml注釋掉以下配置

/bin/catalina.sh
修改JAVA_OPTS參數(shù)，這里需要參照機(jī)器配置，對(duì)JVM進(jìn)行參數(shù)優(yōu)化

JDK1.7

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms512m -Xmx1024m -XX:NewSize=512m -XX:MaxNewSize=1024M -XX:PermSize=1024m -XX:MaxPermSize=1024m -XX:+DisableExplicitGC"

JDK1.8

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1024m -Xmx1024m -XX:NewSize=512m -XX:MaxNewSize=1024M -XX:+DisableExplicitGC"

1.8 版本中已經(jīng)沒(méi)有PermSize、MaxPermSize

JAVA8里對(duì)metaspace可以在小范圍自動(dòng)擴(kuò)展永生代避免溢出。

-Djava.awt.headless

沒(méi)有設(shè)備、鍵盤或鼠標(biāo)的模式。

-Dfile.encoding

設(shè)置字符集

-server

jvm的server工作模式，對(duì)應(yīng)的有client工作模式。使用“java -version”可以查看當(dāng)前工作模式

-Xms1024m

初始Heap大小，使用的最小內(nèi)存

-Xmx1024m

Java heap最大值，使用的最大內(nèi)存
經(jīng)驗(yàn): 設(shè)置Xms大小等于Xmx大小

-XX:NewSize=512m

表示新生代初始內(nèi)存的大小，應(yīng)該小于 -Xms的值

-XX:MaxNewSize=1024M

表示新生代可被分配的內(nèi)存的最大上限，應(yīng)該小于 -Xmx的值

-XX:PermSize=1024m

設(shè)定內(nèi)存的永久保存區(qū)域,內(nèi)存的永久保存區(qū)域，VM 存放Class 和 Meta 信息，JVM在運(yùn)行期間不會(huì)清除該區(qū)域
程序加載很多class情況下，超出PermSize情況下
JDK1.7會(huì)拋出java.lang.OutOfMemoryError: PermGen space異常
JDK1.8下會(huì)拋出 ERROR: java.lang.OutOfMemoryError: Metadata space 異常

-XX:MaxPermSize=1024m

設(shè)定最大內(nèi)存的永久保存區(qū)域
經(jīng)驗(yàn): 設(shè)置PermSize大小等于MaxPermSize大小

-XX:+DisableExplicitGC

自動(dòng)將System.gc()調(diào)用轉(zhuǎn)換成一個(gè)空操作，即應(yīng)用中調(diào)用System.gc()會(huì)變成一個(gè)空操作,避免程序員在代碼里進(jìn)行System.gc()這種危險(xiǎn)操作。System.gc() 除非是到了萬(wàn)不得也的情況下使用，都交給JVM吧

XX:SurvivorRatio=2

年輕代中Eden區(qū)與Survivor區(qū)的大小比值

-XX:ReservedCodeCacheSize=256m

保留代碼占用的內(nèi)存容量，無(wú)大的影響

-Xss1024k

單個(gè)線程堆棧大小值，減少這個(gè)值可以生成更多線程，操作系統(tǒng)對(duì)于一個(gè)進(jìn)程內(nèi)的線程數(shù)是有限制的，經(jīng)驗(yàn)值在3000-5000左右

-XX:+CMSParallelRemarkEnabled

CMS 垃圾回收算法，對(duì)響應(yīng)時(shí)間的重要性需求 大于 對(duì)吞吐量的要求，能夠承受垃圾回收線程和應(yīng)用線程共享處理器資源，并且應(yīng)用中存在比較多的長(zhǎng)生命周期的對(duì)象的應(yīng)用

-XX:+UseCMSCompactAtFullCollection

在使用concurrent gc 的情況下, 防止 memoryfragmention, 對(duì)live object 進(jìn)行整理, 使 memory 碎片減少。

-XX:+UseCMSInitiatingOccupancyOnly

在FULL GC的時(shí)候， 對(duì)年老代的壓縮。CMS是不會(huì)移動(dòng)內(nèi)存的， 因此這個(gè)非常容易產(chǎn)生碎片， 導(dǎo)致內(nèi)存不夠用， 因此， 內(nèi)存的壓縮這個(gè)時(shí)候就會(huì)被啟用。 增加這個(gè)參數(shù)是個(gè)好習(xí)慣?？赡軙?huì)影響性能,但是可以消除碎片。

-XX:CMSInitiatingOccupancyFraction=60

使用cms作為垃圾回收, 使用60％后開始CMS收集

-XX:+UseGCOverheadLimit

用來(lái)限制使用內(nèi)存，如果不做控制，可能會(huì)報(bào)出
java.lang.OutOfMemoryError: GC overhead limit exceeded

-XX:+UseConcMarkSweepGC

使用CMS內(nèi)存收集

-XX:+UseParNewGC

設(shè)置年輕代為并行收集

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/x/dump_tomcat.hprof

JVM會(huì)在遇到OutOfMemoryError時(shí)拍攝一個(gè)“堆轉(zhuǎn)儲(chǔ)快照”，并將其保存在一個(gè)文件中。

-Xloggc:/xx/gc_tomcat.log

gc的日志，如果該日志中出現(xiàn)頻繁的Full GC就是有相關(guān)的系統(tǒng)問(wèn)題，如果很少，說(shuō)明暫時(shí)還算正常

-XX:+PrintGCDateStamps

輸出GC的時(shí)間戳（以基準(zhǔn)時(shí)間的形式）

-XX:+PrintGCDetails

輸出GC的日志格式

-Dnetworkaddress.cache.ttl=60

-Dsun.net.inetaddr.ttl=60

設(shè)置DNS緩存時(shí)間

-DautoStartup=false

-Dsun.net.client.defaultConnectTimeout=60000

連接建立超時(shí)時(shí)間

-Dsun.net.client.defaultReadTimeout=60000

內(nèi)容獲取超時(shí)設(shè)置

-Djmagick.systemclassloader=no

是否生成縮略圖的一個(gè)框架的配置

-Djava.security.egd=file:/dev/./urandom

export JAVA_OPTS="-server -showversion -Xms2000m -Xmx2000m -Xmn500m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:SurvivorRatio=2 -XX:ReservedCodeCacheSize=256m -Xss1024k -Djava.awt.headless=true -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tomcat_path/logs/dump_tomcat.hprof -Xloggc:/tomcat_path/logs/gc_tomcat.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCDetails -Dnetworkaddress.cache.ttl=60 -Dsun.net.inetaddr.ttl=60 -DautoStartup=false -Dsun.net.client.defaultConnectTimeout=60000 -Dsun.net.client.defaultReadTimeout=60000 -Djmagick.systemclassloader=no -Djava.security.egd=file:/dev/./urandom -Dfile.encoding=UTF-8"

java.lang.OutOfMemoryError: Java heap space —-JVM Heap（堆）溢出

JVM 在啟動(dòng)的時(shí)候會(huì)自動(dòng)設(shè)置 JVM Heap 的值，其初始空間（即-Xms）是物理內(nèi)存的1/64，最大空間（-Xmx）不可超過(guò)物理內(nèi)存?？梢岳?JVM提供的 -Xmn -Xms -Xmx 等選項(xiàng)可進(jìn)行設(shè)置。Heap 的大小是 Young Generation 和 Tenured Generaion 之和。在 JVM 中如果 98％ 的時(shí)間是用于 GC，且可用的 Heap size 不足 2％ 的時(shí)候?qū)伋龃水惓Ｐ畔ⅰ?/p>

解決方法：手動(dòng)設(shè)置 JVM Heap（堆）的大小。

java.lang.OutOfMemoryError: PermGen space —- PermGen space溢出。

jdk1.8 拋出 ERROR: java.lang.OutOfMemoryError: Metadata space 異常
PermGen space 的全稱是 Permanent Generation space，是指內(nèi)存的永久保存區(qū)域。為什么會(huì)內(nèi)存溢出，這是由于這塊內(nèi)存主要是被 JVM 存放Class 和 Meta 信息的，Class 在被 Load 的時(shí)候被放入 PermGen space 區(qū)域，它和存放 Instance 的 Heap 區(qū)域不同，sun 的 GC 不會(huì)在主程序運(yùn)行期對(duì) PermGen space 進(jìn)行清理，所以如果你的 APP 會(huì)載入很多 CLASS 的話，就很可能出現(xiàn) PermGen space 溢出。

解決方法： 手動(dòng)設(shè)置 MaxPermSize 大小

java.lang.StackOverflowError —- 棧溢出

棧溢出了，JVM 依然是采用棧式的虛擬機(jī)。函數(shù)的調(diào)用過(guò)程都體現(xiàn)在堆棧和退棧上了。調(diào)用構(gòu)造函數(shù)的 “層”太多了，以致于把棧區(qū)溢出了。通常來(lái)講，一般棧區(qū)遠(yuǎn)遠(yuǎn)小于堆區(qū)的，因?yàn)楹瘮?shù)調(diào)用過(guò)程往往不會(huì)多于上千層，而即便每個(gè)函數(shù)調(diào)用需要 1K 的空間（這個(gè)大約相當(dāng)于在一個(gè) C 函數(shù)內(nèi)聲明了 256 個(gè) int 類型的變量），那么棧區(qū)也不過(guò)是需要 1MB 的空間。通常棧的大小是 1－2MB 的。

解決方法: 代碼中遞歸也不要遞歸的層次過(guò)多

線上應(yīng)用系統(tǒng)出現(xiàn)問(wèn)題，怎么快速定位系統(tǒng)哪塊資源問(wèn)題？