JVM性能調(diào)優(yōu)解決方案(總結(jié))一、弓1言本文的讀者是技術(shù)支持人員。閱讀本文后，你將理解jboss的啟動(dòng)腳本文件(run.sh)中有一系列的JVM配置參數(shù)的含義，以及如何調(diào)整它們，從而使得MegaEyes中心管理服務(wù)器的性能得到優(yōu)化。MegaEyes中心管理服務(wù)器的性能調(diào)優(yōu)涉及到系統(tǒng)的多個(gè)方面，包括MegaEyes應(yīng)用本身、應(yīng)用服務(wù)器(jboss)、數(shù)據(jù)庫和java虛擬機(jī)(JVM)等等。本文重點(diǎn)介紹JVM的性能優(yōu)化。需要注意的是，JVM性能調(diào)優(yōu)具有應(yīng)用獨(dú)特性(applicationspecific),就是說，不同的應(yīng)用情形應(yīng)該有不同的調(diào)整方案，這就要求你首先要觀察JVM的運(yùn)行狀態(tài)，然后根據(jù)觀察結(jié)果調(diào)整參數(shù)。沒有一個(gè)通用的調(diào)優(yōu)方案可以適用于所有的MegaEyes應(yīng)用。什么是性能調(diào)優(yōu)對性能調(diào)優(yōu)，不同的人有不同的理解，本文是指對下列指標(biāo)最大化：并發(fā)用戶(concurrentusers),在服務(wù)請求失敗或請求響應(yīng)超過預(yù)期時(shí)間之前，系統(tǒng)支持的最大并發(fā)用戶數(shù)量。系統(tǒng)容量(throughput),可以用每秒處理的事務(wù)(transaction)數(shù)量計(jì)算?？煽啃?reliability)換句話說，我們想對更多的用戶提供更快捷的、不會(huì)中斷的服務(wù)。JVM性能調(diào)優(yōu)的重點(diǎn)jvm的性能調(diào)優(yōu)的重點(diǎn)是垃圾回收（gc,garbagecollection）和內(nèi)存管理。垃圾回收的時(shí)候會(huì)導(dǎo)致整個(gè)虛擬機(jī)暫停服務(wù)，因此，應(yīng)該盡可能地縮短垃圾回收的處理時(shí)間。JVM內(nèi)存JVM占用的內(nèi)存稱為堆（heap）,它被分為三個(gè)區(qū)：年輕（young,又稱為new）、老（tenured，又稱為old）和永生（perm）。這三個(gè)區(qū)是按照java對象的生存期劃分的，在new區(qū)的對象生存期最短，很快就會(huì)被gc回收；perm區(qū)的對象生存期最長，與JVM同生死。Perm區(qū)的對象不會(huì)被gc回收。new區(qū)又被分為三個(gè)部分：伊甸園（eden）和兩個(gè)幸存者（survivor）。對象的創(chuàng)建總是在eden部分（這大概就是命名該部分為eden的原因吧）。兩個(gè)survivor中總有一個(gè)是空的，它作為另一個(gè)survivor的緩沖區(qū)。當(dāng)gc發(fā)生時(shí)，所有eden和survivor中活下來的對象被移動(dòng)到另一個(gè)survivor中。對象會(huì)在兩個(gè)survivor之間不斷移動(dòng)，直到活得足夠久，然后移動(dòng)到old區(qū)。我們可以猜想，之所以如此劃分使用內(nèi)存，肯定是為了縮短gc的執(zhí)行時(shí)間，提高gc的執(zhí)行效率。垃圾回收算法除了默認(rèn)的垃圾回收算法外，JVM還提供了兩個(gè)：并行（parallel）和并發(fā)（concurrent），前者作用在new區(qū)，后者作用在old區(qū)。兩者可以同時(shí)使用。

并行算法會(huì)產(chǎn)生多個(gè)線程以提高執(zhí)行效率。當(dāng)有多個(gè)cpu的時(shí)候，它會(huì)顯著縮短gc的工作時(shí)間。并發(fā)算法可以在JVM不中斷對應(yīng)用的服務(wù)的情況下執(zhí)行（通常情況下，在gc工作的時(shí)候JVM停止對應(yīng)用的服務(wù)）。二、性能參數(shù)參數(shù)含義說明-XmsHeap的最小尺寸-XmxHeap的最大尺寸作為一個(gè)通行的準(zhǔn)則，設(shè)置xms和xmx的尺寸一樣，以減少gc的次數(shù)。要將它們設(shè)置足夠大，否則就會(huì)產(chǎn)生outofmemory錯(cuò)誤，但又不能設(shè)置過大，過大會(huì)增加gc的工作時(shí)間。-Xmnnew的尺寸-xx：PermSizePerm的最小尺寸-xx：MaxPermSizePerm的最大尺寸類似heap的設(shè)置，應(yīng)該將perm設(shè)置為固定尺寸，即最大和最小尺寸一樣。-xx：SurvivorRatioNew區(qū)中eden與Survivor區(qū)的比值-xx：+useParallelGC使用parallelgc-xx：ParallelGCThreadsParallelgc的線程個(gè)數(shù)與cpu個(gè)數(shù)相同，使得所有cpu都參與gc工作。JVM的參數(shù)主要由-X和-XX類型的選項(xiàng)組成，上邊列出了一些對內(nèi)存和gc的性能影響比較大的。三、性能參數(shù)調(diào)優(yōu)要調(diào)整參數(shù)首先要觀察它們。觀察JVM內(nèi)存和gc的工具很多，jdk本身也提供了一些，這些工具簡單、實(shí)用，而且不需要安裝。其中，最常用的是jps和jstat，前者用來查看JVM的進(jìn)程id（pid），后者用這個(gè)pid作為參數(shù)來得到內(nèi)存和gc的狀態(tài)，就是說，在執(zhí)行jstat之前必須用jps得到1」JVM的pid。Jstat的例子：：jstat-gcutil2130825010其中，21308是（運(yùn)行jboss）的JVM的pid；250是采樣間隔，單位是毫秒，即250毫秒采集一次數(shù)據(jù)；10是采樣次數(shù)。上述命令的執(zhí)行結(jié)果如下：S0S1EOPYGCYGCTFGCFGCTGCT0.00 0.00 11.39 5.29 13.57 328 1.955327133.126135.0810.00 0.00 11.39 5.29 13.57 328 1.955327133.126135.081

0.000.0011.395.2913.573281.955327133.126135.0810.000.0011.395.2913.573281.955327133.126135.0810.000.0011.395.2913.573281.955327133.126135.0810.000.0011.395.2913.573281.955327133.126135.0810.000.0011.395.2913.573281.955327133.126135.0810.000.0011.395.2913.573281.955327133.126135.0810.000.0011.395.2913.573281.955327133.126135.0810.000.0011.395.2913.573281.955327133.126135.081列標(biāo)題含義說明S0SurvivorS1SurvivorEEdenOOld

PPerm以上數(shù)據(jù)都是百分比。YGCYoung（new）區(qū)完成的gc的次數(shù)YGCTYGC消耗的總時(shí)間（秒）FGC整個(gè)heap完成的gc的次數(shù)如果采用了parallelgc,你會(huì)看到Y(jié)GC明顯大于FGC。FGCTFGC消耗的總時(shí)間（秒）GCTYGCT+FGCT我們可以將采樣次數(shù)設(shè)置足夠大，這樣就可以看到內(nèi)存和gc的變化了。從上述數(shù)據(jù)可以看出，內(nèi)存各區(qū)域的占用率都不高，gc的執(zhí)行時(shí)間都不長，不過，perm區(qū)有些太大，太浪費(fèi)了。因?yàn)閜erm區(qū)的對象與JVM的生命周期是一樣的，對象數(shù)量不會(huì)動(dòng)態(tài)變化，所以，我們可以把這個(gè)區(qū)域的尺寸設(shè)置為原尺寸的二分之一，這樣，perm的占用率將從13%左右增加到26%左右。從上述數(shù)據(jù)還可以看出，new區(qū)的gc明顯比真?zhèn)€heap的gc快得多。通常，F(xiàn)GC應(yīng)該不超過400毫秒，否則，將嚴(yán)重影響java應(yīng)用的正常運(yùn)行。分割線一、JVM內(nèi)存模型及垃圾收集算法L根據(jù)Java虛擬機(jī)規(guī)范，JVM將內(nèi)存劃分為：New（年輕代）Tenured（年老代）永久代（Perm）其中New和Tenured屬于堆內(nèi)存，堆內(nèi)存會(huì)從JVM啟動(dòng)參數(shù)（-xmx:3G）指定的內(nèi)存中分配，Perm不屬于堆內(nèi)存，有虛擬機(jī)直接分配，但可以通過-XX：Permsize-xx：MaxPermSize等參數(shù)調(diào)整其大小。年輕代（New）：年輕代用來存放JVM剛分配的Java對象年老代（Tenured）：年輕代中經(jīng)過垃圾回收沒有回收掉的對象將被Copy到年老代永久代（Perm）：永久代存放class、Method元信息，其大小跟項(xiàng)目的規(guī)模、類、方法的量有關(guān)，一般設(shè)置為128M就足夠，設(shè)置原則是預(yù)留30%的空間。New又分為幾個(gè)部分：Eden：Eden用來存放JVM剛分配的對象SurvivorlSurvivro2：兩個(gè)Survivor空間一樣大，當(dāng)Eden中的對象經(jīng)過垃圾回收沒有被回收掉時(shí)，會(huì)在兩個(gè)Survivor之間來回Copy，當(dāng)滿足某個(gè)條件，比如Copy次數(shù)，就會(huì)被Copy至UTenured。顯然，Survivor只是增加了對象在年輕代中的逗留時(shí)間，增加了被垃圾回收的可能性。2.垃圾回收算法垃圾回收算法可以分為三類，都基于標(biāo)記-清除（復(fù)制）算法:serial算法（單線程）并行算法并發(fā)算法JVM會(huì)根據(jù)機(jī)器的硬件配置對每個(gè)內(nèi)存代選擇適合的回收算法，比如，如果機(jī)器多于1個(gè)核，會(huì)對年輕代選擇并行算法，關(guān)于選擇細(xì)節(jié)請參考JVM調(diào)優(yōu)文檔。稍微解釋下的是，并行算法是用多線程進(jìn)行垃圾回收，回收期間會(huì)暫停程序的執(zhí)行，而并發(fā)算法，也是多線程回收，但期間不停止應(yīng)用執(zhí)行。所以，并發(fā)算法適用于交互性高的一些程序。經(jīng)過觀察，并發(fā)算法會(huì)減少年輕代的大小，其實(shí)就是使用了一個(gè)大的年老代，這反過來跟并行算法相比吞吐量相對較低。還有一個(gè)問題是，垃圾回收動(dòng)作何時(shí)執(zhí)行？當(dāng)年輕代內(nèi)存滿時(shí)，會(huì)引發(fā)一次普通GC,該GC僅回收年輕代。需要強(qiáng)調(diào)的時(shí)，年輕代滿是指Eden代滿，survivor滿不會(huì)引發(fā)GC當(dāng)年老代滿時(shí)會(huì)引發(fā)FullGC,FullGC將會(huì)同時(shí)回收年輕代、年老代當(dāng)永久代滿時(shí)也會(huì)引發(fā)FullGC,會(huì)導(dǎo)致class、Method元信息的卸載另一個(gè)問題是，何時(shí)會(huì)拋出OutOfMemoryException,并不是內(nèi)存被耗空的時(shí)候才拋出JVM98%的時(shí)間都花費(fèi)在內(nèi)存回收每次回收的內(nèi)存小于2%滿足這兩個(gè)條件將觸發(fā)OutOfMemoryException,這將會(huì)留給系統(tǒng)一個(gè)微小的間隙以做一些Down之前的操作，比如手動(dòng)打印HeapDump。二、內(nèi)存泄漏及解決方法L系統(tǒng)崩潰前的一些現(xiàn)象：每次垃圾回收的時(shí)間越來越長，由之前的10ms延長到50ms左右，F(xiàn)ullGC的時(shí)間也有之前的0.5s延長到4、5sFU11GC的次數(shù)越來越多，最頻繁時(shí)隔不到1分鐘就進(jìn)行一次FU11GC年老代的內(nèi)存越來越大并且每次FullGC后年老代沒有內(nèi)存被釋放之后系統(tǒng)會(huì)無法響應(yīng)新的請求，逐漸到達(dá)OutOfMemoryError的臨界值。.生成堆的dump文件通過jmx的MBean生成當(dāng)前的Heap信息，大小為一個(gè)3G（整個(gè)堆的大?。┑膆prof文件，如果沒有啟動(dòng)JMX可以通過Java的jmap命令來生成該文件。.分析dump文件下面要考慮的是如何打開這個(gè)3G的堆信息文件，顯然一般的Window系統(tǒng)沒有這么大的內(nèi)存，必須借助高配置的Linux。當(dāng)然我們可以借助X-Window把Linux上的圖形導(dǎo)入到Window。我們考慮用下面幾種工具打開該文件：VisualvmIBMHeapAnalyzerJDK自帶的Hprof工具使用這些工具時(shí)為了確保加載速度，建議設(shè)置最大內(nèi)存為6G。使用后發(fā)現(xiàn)，這些工具都無法直觀地觀察到內(nèi)存泄漏，visualvm雖能觀察到對象大小，但看不到調(diào)用堆棧；HeapAnalyzer雖然能看到調(diào)用堆棧，卻無法正確打開一個(gè)3G的文件。因此，我們又選用了Eclipse專門的靜態(tài)內(nèi)存分析工具：Mat。.分析內(nèi)存泄漏通過Mat我們能清楚地看到，哪些對象被懷疑為內(nèi)存泄漏，哪些對象占的空間最大及對象的調(diào)用關(guān)系。針對本案，在ThreadLocal中有很多的JbpmContext實(shí)例，經(jīng)過調(diào)查是JBPM的Context沒有關(guān)閉所致。另，通過Mat或JMX我們還可以分析線程狀態(tài)，可以觀察到線程被阻塞在哪個(gè)對象上，從而判斷系統(tǒng)的瓶頸。.回歸問題Q：為什么崩潰前垃圾回收的時(shí)間越來越長？A:根據(jù)內(nèi)存模型和垃圾回收算法，垃圾回收分兩部分：內(nèi)存標(biāo)記、清除（復(fù)制），標(biāo)記部分只要內(nèi)存大小固定時(shí)間是不變的，變的是復(fù)制部分，因?yàn)槊看卫厥斩加幸恍┗厥詹坏舻膬?nèi)存，所以增加了復(fù)制量，導(dǎo)致時(shí)間延長。所以，垃圾回收的時(shí)間也可以作為判斷內(nèi)存泄漏的依據(jù)Q：為什么FullGC的次數(shù)越來越多？A：因此內(nèi)存的積累，逐漸耗盡了年老代的內(nèi)存，導(dǎo)致新對象分配沒有更多的空間，從而導(dǎo)致頻繁的垃圾回收Q:為什么年老代占用的內(nèi)存越來越大？A:因?yàn)槟贻p代的內(nèi)存無法被回收，越來越多地被Copy到年老代三、性能調(diào)優(yōu)除了上述內(nèi)存泄漏外，我們還發(fā)現(xiàn)CPU長期不足3%,系統(tǒng)吞吐量不夠，針對8corexl6G.64bit的Linux服務(wù)器來說，是嚴(yán)重的資源浪費(fèi)。在CPU負(fù)載不足的同時(shí)，偶爾會(huì)有用戶反映請求的時(shí)間過長，我們意識(shí)到必須對程序及JVM進(jìn)行調(diào)優(yōu)。從以下幾個(gè)方面進(jìn)行：線程池：解決用戶響應(yīng)時(shí)間長的問題連接池JVM啟動(dòng)參數(shù)：調(diào)整各代的內(nèi)存比例和垃圾回收算法，提高吞吐量程序算法：改進(jìn)程序邏輯算法提高性能LJava線程池(java.util.concurrent.ThreadpoolExecutor)大多數(shù)JVM6上的應(yīng)用采用的線程池都是JDK自帶的線程池，之所以把成熟的Java線程池進(jìn)行羅嗦說明，是因?yàn)樵摼€程池的行為與我們想象的有點(diǎn)出入。Java線程池有幾個(gè)重要的配置參數(shù)：corePoolSize：核心線程數(shù)(最新線程數(shù))maximumpoolsize：最大線程數(shù)，超過這個(gè)數(shù)量的任務(wù)會(huì)被拒絕，用戶可以通過RejectedExecutionHandler接口自定義處理方式keepAliveTime：線程保持活動(dòng)的時(shí)間workQueue：工作隊(duì)列，存放執(zhí)行的任務(wù)Java線程池需要傳入一個(gè)Queue參數(shù)(workQueue)用來存放執(zhí)行的任務(wù)，而對Queue的不同選擇，線程池有完全不同的行為：SynchronousQueue：一個(gè)無容量的等待隊(duì)列，一個(gè)線程的insert操作必須等待另一線程的remove操作，采用這個(gè)Queue線程池將會(huì)為每個(gè)任務(wù)分配一個(gè)新線程LinkedBlockingQueue：無界隊(duì)列，采用該Queue,線程池將忽略maximumpoolsize參數(shù)，僅用corePoolsize的線程處理所有的任務(wù)，未處理的任務(wù)便在LinkedBlockingQueue中排隊(duì)ArrayBlockingQueue：有界隊(duì)列，在有界隊(duì)列和maximumpoolsize的作用下，程序?qū)⒑茈y被調(diào)優(yōu)：更大的Queue和小的maximumPoolSize將導(dǎo)致CPU的低負(fù)載；小的Queue和大的池，Queue就沒起動(dòng)應(yīng)有的作用。其實(shí)我們的要求很簡單，希望線程池能跟連接池一樣，能設(shè)置最小線程數(shù)、最大線程數(shù)，當(dāng)最小數(shù)〈任務(wù)〈最大數(shù)時(shí)，應(yīng)該分配新的線程處理；當(dāng)任務(wù),最大數(shù)時(shí)，應(yīng)該等待有空閑線程再處理該任務(wù)。但線程池的設(shè)計(jì)思路是，任務(wù)應(yīng)該放到Queue中，當(dāng)Queue放不下時(shí)再考慮用新線程處理，如果Queue滿且無法派生新線程，就拒絕該任務(wù)。設(shè)計(jì)導(dǎo)致“先放等執(zhí)行”、“放不下再執(zhí)行"、“拒絕不等待"。所以，根據(jù)不同的Queue參數(shù)，要提高吞吐量不能一味地增大maximumPoolSize。當(dāng)然，要達(dá)到我們的目標(biāo)，必須對線程池進(jìn)行一定的封裝，幸運(yùn)的是ThreadPoolExecutor中留了足夠的自定義接口以幫助我們達(dá)到目標(biāo)。我們封裝的方式是：以SynchronousQueue作為參數(shù)，使maximumPoolSize發(fā)揮作用，以防止線程被無限制的分配，同時(shí)可以通過提高maximumPoolSize來提高系統(tǒng)吞吐量自定義一個(gè)RejectedExecutionHandler，當(dāng)線程數(shù)超過maximumPoolSize時(shí)進(jìn)行處理，處理方式為隔一段時(shí)間檢查線程池是否可以執(zhí)行新Task，如果可以把拒絕的Task重新放入到線程池，檢查的時(shí)間依賴keepAliveTime的大小。.連接池(mons.dbcp.BasicDataSource)在使用mons.dbcp.BasicDataSource的時(shí)候，因?yàn)橹安捎昧四J(rèn)配置，所以當(dāng)訪問量大時(shí)，通過JMX觀察到很多Tomcat線程都阻塞在BasicDataSource使用的ApacheObjectpool的鎖上，直接原因當(dāng)時(shí)是因?yàn)锽asicDataSource連接池的最大連接數(shù)設(shè)置的太小，默認(rèn)的BasicDataSource配置，僅使用8個(gè)最大連接。我還觀察到一個(gè)問題，當(dāng)較長的時(shí)間不訪問系統(tǒng)，比如2天,DB上的Mysql會(huì)斷掉所以的連接，導(dǎo)致連接池中緩存的連接不能用。為了解決這些問題，我們充分研究了BasicDataSource,發(fā)現(xiàn)了一些優(yōu)化的點(diǎn)：Mysql默認(rèn)支持100個(gè)鏈接，所以每個(gè)連接池的配置要根據(jù)集群中的機(jī)器數(shù)進(jìn)行，如有2臺(tái)服務(wù)器，可每個(gè)設(shè)置為60initialsize：參數(shù)是一直打開的連接數(shù)minEvictableidleTimeMillis：該參數(shù)設(shè)置每個(gè)連接的空閑時(shí)間，超過這個(gè)時(shí)間連接將被關(guān)閉timeBetweenEvictionRunsMillis：后臺(tái)線程的運(yùn)行周期，用來檢測過期連接maxActive：最大能分配的連接數(shù)maxIdle：最大空閑數(shù)，當(dāng)連接使用完畢后發(fā)現(xiàn)連接數(shù)大于maxIdle，連接將被直接關(guān)閉。只有initialSize<x<maxIdle的連接將被定期檢測是否超期。這個(gè)參數(shù)主要用來在峰值訪問時(shí)提高吞吐量。initialSize是如何保持的？經(jīng)過研究代碼發(fā)現(xiàn)，BasicDataSource會(huì)關(guān)閉所有超期的連接，然后再打開initialSize數(shù)量的連接，這個(gè)特性與minEvictableIdleTimeMillis、timeBetweenEvictionRunsMillis一起保證了所有超期的initialSize連接都會(huì)被重新連接，從而避免了Mysql長時(shí)間無動(dòng)作會(huì)斷掉連接的問題。.JVM參數(shù)在JVM啟動(dòng)參數(shù)中，可以設(shè)置跟內(nèi)存、垃圾回收相關(guān)的一些參數(shù)設(shè)置，默認(rèn)情況不做任何設(shè)置JVM會(huì)工作的很好，但對一些配置很好的Server和具體的應(yīng)用必須仔細(xì)調(diào)優(yōu)才能獲得最佳性能。通過設(shè)置我們希望達(dá)到一些目標(biāo)：GC的時(shí)間足夠的小GC的次數(shù)足夠的少發(fā)生FullGC的周期足夠的長前兩個(gè)目前是相悖的，要想GC時(shí)間小必須要一個(gè)更小的堆，要保證GC次數(shù)足夠少，必須保證一個(gè)更大的堆，我們只能取其平衡。(1)針對JVM堆的設(shè)置一般，可以通過-xms-Xmx限定其最小、最大值，為了防止垃圾收集器在最小、最大之間收縮堆而產(chǎn)生額外的時(shí)間，我們通常把最大、最小設(shè)置為相同的值(2)年輕代和年老代將根據(jù)默認(rèn)的比例(1：2)分配堆內(nèi)存，可以通過調(diào)整二者之間的比率NewRadio來調(diào)整二者之間的大小，也可以針對回收代，比如年輕代，通過-xx：newsize-xx：MaxNewSize來設(shè)置其絕對大小。同樣，為了防止年輕代的堆收縮，我們通常會(huì)把-xx:newSize-xx:MaxNewSize設(shè)置為同樣大小(3)年輕代和年老代設(shè)置多大才算合理？這個(gè)我問題毫無疑問是沒有答案的，否則也就不會(huì)有調(diào)優(yōu)。我們觀察一下二者大小變化有哪些影響更大的年輕代必然導(dǎo)致更小的年老代,大的年輕代會(huì)延長普通GC的周期,但會(huì)增加每次GC的時(shí)間；小的年老代會(huì)導(dǎo)致更頻繁的FullGC更小的年輕代必然導(dǎo)致更大年老代，小的年輕代會(huì)導(dǎo)致普通GC很頻繁，但每次的GC時(shí)間會(huì)更短；大的年老代會(huì)減少FullGC的頻率如何選擇應(yīng)該依賴應(yīng)用程序?qū)ο笊芷诘姆植记闆r：如果應(yīng)用存在大量的臨時(shí)對象，應(yīng)該選擇更大的年輕代；如果存在相對較多的持久對象，年老代應(yīng)該適當(dāng)增大。但很多應(yīng)用都沒有這樣明顯的特性，在抉擇時(shí)應(yīng)該根據(jù)以下兩點(diǎn)：（A）本著FullGC盡量少的原則，讓年老代盡量緩存常用對象，JVM的默認(rèn)比例L2也是這個(gè)道理（B）通過觀察應(yīng)用一段時(shí)間，看其他在峰值時(shí)年老代會(huì)占多少內(nèi)存，在不影響FullGC的前提下，根據(jù)實(shí)際情況加大年輕代，