JVM 調(diào)優(yōu)及調(diào)優(yōu)實例

GC策略&內(nèi)存申請、對象衰老JVM里的GC(GarbageCollection)的算法有很多種，如標記清除收集器，壓縮收集器，分代收集器等等,詳見HotSpotVMGC的種類現(xiàn)在比較常用的是分代收集（generationalcollection,也是SUNVM使用的,J2SE1.2之后引入），即將內(nèi)存分為幾個區(qū)域，將不同生命周期的對象放在不同區(qū)域里:younggeneration，tenuredgeneration和permanetgeneration。絕大部分的objec被分配在younggeneration(生命周期短)，并且大部分的object在這里die。當younggeneration滿了之后，將引發(fā)minorcollection(YGC)。在minorcollection后存活的object會被移動到tenuredgeneration(生命周期比較長)。最后，tenuredgeneration滿之后觸發(fā)majorcollection。majorcollection（Fullgc）會觸發(fā)整個heap的回收，包括回收younggeneration。permanetgeneration區(qū)域比較穩(wěn)定，主要存放classloader信息。younggeneration有eden、2個survivor區(qū)域組成。其中一個survivor區(qū)域一直是空的，是eden區(qū)域和另一個survivor區(qū)域在下一次copycollection后活著的objecy的目的地。object在survivo區(qū)域被復制直到轉(zhuǎn)移到tenured區(qū)。我們要盡量減少Fullgc的次數(shù)(tenuredgeneration一般比較大,收集的時間較長,頻繁的Fullgc會導致應用的性能收到嚴重的影響)。堆內(nèi)存GCJVM(采用分代回收的策略)，用較高的頻率對年輕的對象(younggeneration)進行YGC，而對老對象(tenuredgeneration)較少(tenuredgeneration滿了后才進行)進行FullGC。這樣就不需要每次GC都將內(nèi)存中所有對象都檢查一遍。非堆內(nèi)存不GCGC不會在主程序運行期對PermGenSpace進行清理，所以如果你的應用中有很多CLASS(特別是動態(tài)生成類，當然permgenspace存放的內(nèi)容不僅限于類)的話,就很可能出現(xiàn)PermGenSpace錯誤。內(nèi)存申請、對象衰老過程一、內(nèi)存申請過程1. JVM會試圖為相關(guān)Java對象在Eden中初始化一塊內(nèi)存區(qū)域；2. 當Eden空間足夠時，內(nèi)存申請結(jié)束。否則到下一步；3. JVM試圖釋放在Eden中所有不活躍的對象（minorcollection），釋放后若Eden空間仍然不足以放入新對象，則試圖將部分Eden中活躍對象放入Survivor區(qū)；4. Survivor區(qū)被用來作為Eden及old的中間交換區(qū)域，當OLD區(qū)空間足夠時，Survivor區(qū)的對象會被移到Old區(qū)，否則會被保留在Survivor區(qū)；5. 當old區(qū)空間不夠時，JVM會在old區(qū)進行majorcollection；6. 完全垃圾收集后，若Survivor及old區(qū)仍然無法存放從Eden復制過來的部分對象，導致JVM無法在Eden區(qū)為新對象創(chuàng)建內(nèi)存區(qū)域，則出現(xiàn)"Outofmemory錯誤"；二、對象衰老過程1. 新創(chuàng)建的對象的內(nèi)存都分配自eden。Minorcollection的過程就是將eden和在用survivorspace中的活對象copy到空閑survivorspace中。對象在younggeneration里經(jīng)歷了一定次數(shù)(可以通過參數(shù)配置)的minorcollection后，就會被移到oldgeneration中，稱為tenuring。2. GC觸發(fā)條件GC類型觸發(fā)條件觸發(fā)時發(fā)生了什么注意查看方式Y(jié)GCeden空間不足清空Eden+fromsurvivor中所有noref的對象占用的內(nèi)存將eden+fromsur中所有存活的對象copy到tosur中一些對象將晉升到old中:

tosur放不下的存活次數(shù)超過turningthreshold中的重新計算tenuringthreshold(serialparallelGC會觸發(fā)此項)重新調(diào)整Eden和from的大小(parallelGC會觸發(fā)此項)全過程暫停應用是否為多線程處理由具體的GC決定jstat–gcutil

gclogFGCold空間不足perm空間不足

顯示調(diào)用System.GC,RMI等的定時觸發(fā)YGC時的悲觀策略dumplive的內(nèi)存信息時(jmap–dump:live)清空heap中noref的對象permgen中已經(jīng)被卸載的classloader中加載的class信息如配置了CollectGenOFirst,則先觸發(fā)YGC(針對serialGC)如配置了ScavengeBeforeFullGC,則先觸發(fā)YGC(針對serialGC)全過程暫停應用是否為多線程處理由具體的GC決定是否壓縮需要看配置的具體GCjstat–gcutil

gclog3.permanentgeneration空間不足會引發(fā)FullGC,仍然不夠會引發(fā)PermGenSpace錯誤。參考：/blog/356502/blog/archives/164

/redcreen/archive/2011/05/04/2037056.htmlJVM參數(shù)設(shè)置、分析不管是YGC還是FullGC,GC過程中都會對導致程序運行中中斷,正確的選擇不同的GC策略,調(diào)整JVM、GC的參數(shù)，可以極大的減少由于GC工作，而導致的程序運行中斷方面的問題，進而適當?shù)奶岣逬ava程序的工作效率。但是調(diào)整GC是以個極為復雜的過程，由于各個程序具備不同的特點，如：web和GUI程序就有很大區(qū)別（Web可以適當?shù)耐ｎD，但GUI停頓是客戶無法接受的），而且由于跑在各個機器上的配置不同（主要cup個數(shù)，內(nèi)存不同），所以使用的GC種類也會不同(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數(shù)的設(shè)置來提高系統(tǒng)的性能。GC性能方面的考慮對于GC的性能主要有2個方面的指標：吞吐量throughput（工作時間不算gc的時間占總的時間比）和暫停pause（gc發(fā)生時app對外顯示的無法響應）。1.TotalHeap默認情況下，vm會增加/減少heap大小以維持freespace在整個vm中占的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。一般而言，server端的app會有以下規(guī)則：? 對vm分配盡可能多的memory；? 將Xms和Xmx設(shè)為一樣的值。如果虛擬機啟動時設(shè)置使用的內(nèi)存比較小，這個時候又需要初始化很多對象，虛擬機就必須重復地增加內(nèi)存。? 處理器核數(shù)增加，內(nèi)存也跟著增大。2.TheYoungGeneration另外一個對于app流暢性運行影響的因素是younggeneration的大小。younggeneration越大，minorcollection越少；但是在固定heapsize情況下，更大的younggeneration就意味著小的tenuredgeneration，就意味著更多的majorcollection(majorcollection會引發(fā)minorcollection)。NewRatio反映的是young和tenuredgeneration的大小比例。NewSize和MaxNewSize反映的是younggeneration大小的下限和上限，將這兩個值設(shè)為一樣就固定了younggeneration的大?。ㄍ琗ms和Xmx設(shè)為一樣）。如果希望，SurvivorRatio也可以優(yōu)化survivor的大小，不過這對于性能的影響不是很大。SurvivorRatio是eden和survior大小比例。一般而言，server端的app會有以下規(guī)則：? 首先決定能分配給vm的最大的heapsize，然后設(shè)定最佳的younggeneration的大小；? 如果heapsize固定后，增加younggeneration的大小意味著減小tenuredgeneration大小。讓tenuredgeneration在任何時候夠大，能夠容納所有l(wèi)ive的data（留10%-20%的空余）。經(jīng)驗&&規(guī)則1. 年輕代大小選擇? 響應時間優(yōu)先的應用:盡可能設(shè)大,直到接近系統(tǒng)的最低響應時間限制(根據(jù)實際情況選擇).在此種情況下,年輕代收集發(fā)生的頻率也是最小的.同時,減少到達年老代的對象.? 吞吐量優(yōu)先的應用:盡可能的設(shè)置大,可能到達Gbit的程度.因為對響應時間沒有要求,垃圾收集可以并行進行,一般適合8CPU以上的應用.? 避免設(shè)置過小.當新生代設(shè)置過小時會導致:1.YGC次數(shù)更加頻繁2.可能導致YGC對象直接進入舊生代,如果此時舊生代滿了,會觸發(fā)FGC.2. 年老代大小選擇1. 響應時間優(yōu)先的應用:年老代使用并發(fā)收集器,所以其大小需要小心設(shè)置,一般要考慮并發(fā)會話率和會話持續(xù)時間等一些參數(shù).如果堆設(shè)置小了,可以會造成內(nèi)存碎片,高回收頻率以及應用暫停而使用傳統(tǒng)的標記清除方式;如果堆大了,則需要較長的收集時間.最優(yōu)化的方案,一般需要參考以下數(shù)據(jù)獲得:并發(fā)垃圾收集信息、持久代并發(fā)收集次數(shù)、傳統(tǒng)GC信息、花在年輕代和年老代回收上的時間比例。2. 吞吐量優(yōu)先的應用:一般吞吐量優(yōu)先的應用都有一個很大的年輕代和一個較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象.3. 較小堆引起的碎片問題因為年老代的并發(fā)收集器使用標記,清除算法,所以不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合并,這樣可以分配給較大的對象.但是,當堆空間較小時,運行一段時間以后,就會出現(xiàn)"碎片",如果并發(fā)收集器找不到足夠的空間,那么并發(fā)收集器將會停止,然后使用傳統(tǒng)的標記,清除方式進行回收.如果出現(xiàn)"碎片",可能需要進行如下配置:-XX:+UseCMSCompactAtFullCollection:使用并發(fā)收集器時,開啟對年老代的壓縮.-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設(shè)置多少次FullGC后,對年老代進行壓縮4. 用64位操作系統(tǒng)，Linux下64位的jdk比32位jdk要慢一些，但是吃得內(nèi)存更多，吞吐量更大5. XMX和XMS設(shè)置一樣大，MaxPermSize和MinPermSize設(shè)置一樣大，這樣可以減輕伸縮堆大小帶來的壓力6. 使用CMS的好處是用盡量少的新生代，經(jīng)驗值是128M－256M，然后老生代利用CMS并行收集，這樣能保證系統(tǒng)低延遲的吞吐效率。實際上cms的收集停頓時間非常的短，2G的內(nèi)存，大約20－80ms的應用程序停頓時間7. 系統(tǒng)停頓的時候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看，或者killall-3java，然后查看java控制臺日志，能看出很多問題。(相關(guān)工具的使用方法將在后面的blog中介紹)8. 仔細了解自己的應用，如果用了緩存，那么年老代應該大一些，緩存的HashMap不應該無限制長，建議采用LRU算法的Map做緩存，LRUMap的最大長度也要根據(jù)實際情況設(shè)定。9. 采用并發(fā)回收時，年輕代小一點，年老代要大，因為年老大用的是并發(fā)回收，即使時間長點也不會影響其他程序繼續(xù)運行，網(wǎng)站不會停頓10. JVM參數(shù)的設(shè)置(特別是–Xmx–Xms–Xmn-XX:SurvivorRatio-XX:MaxTenuringThreshold等參數(shù)的設(shè)置沒有一個固定的公式，需要根據(jù)PVold區(qū)實際數(shù)據(jù)YGC次數(shù)等多方面來衡量。為了避免promotionfaild可能會導致xmn設(shè)置偏小，也意味著YGC的次數(shù)會增多，處理并發(fā)訪問的能力下降等問題。每個參數(shù)的調(diào)整都需要經(jīng)過詳細的性能測試，才能找到特定應用的最佳配置。promotionfailed:垃圾回收時promotionfailed是個很頭痛的問題，一般可能是兩種原因產(chǎn)生，第一個原因是救助空間不夠，救助空間里的對象還不應該被移動到年老代，但年輕代又有很多對象需要放入救助空間；第二個原因是年老代沒有足夠的空間接納來自年輕代的對象；這兩種情況都會轉(zhuǎn)向FullGC，網(wǎng)站停頓時間較長。解決方方案一：第一個原因我的最終解決辦法是去掉救助空間，設(shè)置-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0即可，第二個原因我的解決辦法是設(shè)置CMSInitiatingOccupancyFraction為某個值（假設(shè)70），這樣年老代空間到70%時就開始執(zhí)行CMS，年老代有足夠的空間接納來自年輕代的對象。解決方案一的改進方案：又有改進了，上面方法不太好，因為沒有用到救助空間，所以年老代容易滿，CMS執(zhí)行會比較頻繁。我改善了一下，還是用救助空間，但是把救助空間加大，這樣也不會有promotionfailed。具體操作上，32位Linux和64位Linux好像不一樣，64位系統(tǒng)似乎只要配置MaxTenuringThreshold參數(shù)，CMS還是有暫停。為了解決暫停問題和promotionfailed問題，最后我設(shè)置-XX:SurvivorRatio=1，并把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoinfailed，而且更重要的是，年老代和永久代上升非常慢（因為好多對象到不了年老代就被回收了），所以CMS執(zhí)行頻率非常低，好幾個小時才執(zhí)行一次，這樣，服務器都不用重啟了。-Xmx4000M-Xms4000M-Xmn600M-XX:PermSize=500M-XX:MaxPermSize=500M-Xss256K-XX:+DisableExplicitGC-XX:SurvivorRatio=1-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M-XX:+UseFastAccessorMethods-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=80-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.logCMSInitiatingOccupancyFraction值與Xmn的關(guān)系公式上面介紹了promontionfaild產(chǎn)生的原因是EDEN空間不足的情況下將EDEN與Fromsurvivor中的存活對象存入Tosurvivor區(qū)時,Tosurvivor區(qū)的空間不足，再次晉升到oldgen區(qū)，而oldgen區(qū)內(nèi)存也不夠的情況下產(chǎn)生了promontionfaild從而導致fullgc.那可以推斷出：eden+fromsurvivor<oldgen區(qū)剩余內(nèi)存時，不會出現(xiàn)promontionfaild的情況，即：(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))進而推斷出：CMSInitiatingOccupancyFraction<=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100例如：當xmx=128xmn=36SurvivorRatior=1時CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100=73.913當xmx=128xmn=24SurvivorRatior=1時CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…當xmx=3000xmn=600SurvivorRatior=1時CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33CMSInitiatingOccupancyFraction低于70%需要調(diào)整xmn或SurvivorRatior值。參考：JAVAHOTSPOTVM（/blog/archives/164）JVM幾個重要的參數(shù)

(校長)javajvm參數(shù)-Xms-Xmx-Xmn-Xss調(diào)優(yōu)總結(jié)JavaHotSpotVMOptions/archiver/tid-2835.htmlFrequentlyAskedQuestionsAbouttheJavaHotSpotVMJavaSEHotSpotataGlanceJava性能調(diào)優(yōu)筆記(內(nèi)附測試例子很有用)說說MaxTenuringThreshold這個參數(shù)生產(chǎn)環(huán)境參數(shù)實例及分析javaapplication項目（非web項目）改進前：-Xms128m-Xmx128m-XX:NewSize=64m-XX:PermSize=64m-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=78-XX:ThreadStackSize=128-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true問題:1. permsize設(shè)置較小,很容易達到報警范圍(0.8)2. 沒有設(shè)置MaxPermSize，堆增長會帶來額外壓力。3. NewSize較大，oldgen剩余空間64m，一方面可能會帶來old區(qū)容易增長到報警范圍（監(jiān)控數(shù)據(jù)顯示oldgenused長期在50m左右，接近78%，容易出現(xiàn)fullgc）,另一方面也存在promontionfail風險改進后：-Xms128m-Xmx128m-Xmn24m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=1-XX:MaxTenuringThreshold=20-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=75-XX:+UseCMSCompactAtFullCollection-XX:+CMSParallelRemarkEnabled-XX:CMSFullGCsBeforeCompaction=2-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true修改點：1. PermSize與MaxPermSize都設(shè)置為80，一方面避免nonheapwarn(報警閥值0.8非對內(nèi)存一般占用到60M以內(nèi)），一方面避免堆伸縮帶來的壓力2. 通過設(shè)置Xmn=24M及SurvivorRatio=1使得Eden區(qū)=fromspace=tospace=8M,降低了Eden區(qū)大小，降低YGC的時間(降低到3-4ms左右),同時通過設(shè)MaxTenuringThreshold=20，使得oldgen的增長很緩慢。帶來的問題是YGC的次數(shù)明顯提高了很多。3. 其他參數(shù)優(yōu)化修改后帶來的好處見JVM參數(shù)設(shè)置再次改進后-Xms128m-Xmx128m-Xmn36m-XX:PermSize=80m-XX:MaxPermSize=80m-Xss256k-XX:SurvivorRatio=1-XX:MaxTenuringThreshold=20-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=73-XX:+UseCMSCompactAtFullCollection-XX:+CMSParallelRemarkEnabled-XX:CMSFullGCsBeforeCompaction=2-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:logs/gc.log-Dsun.rmi.dgc.server.gcInterval=3600000-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.server.exceptionTrace=true修改點：在上面的基礎(chǔ)上調(diào)整Xmn大小到36M，設(shè)置CMSInitiatingOccupancyFraction=73。Dden區(qū)與Survivor區(qū)大小都增加到12M，通過CMSInitiatingOccupancyFraction計算公式,計算得出value為73是，可以避免promotionfaild問題，同時滿足堆內(nèi)存監(jiān)控報警值在80%：內(nèi)存大小128M*80%=102.4M102.4M-36M=66.4M(老生代達到此值報警）老生代達到67.15M（92M*0.73）將發(fā)生FullGC，所以在老生代大小達到66.4M時也就是WARN報警時將很有可能出現(xiàn)FullGC。增大了Eden和Survivor區(qū)的值，會減小YGC的次數(shù)，但由于空間變大理論上也會相應的增加YGC的時間，不過由于新生代本身就很小（才36M）這點兒變化可以忽略掉。實際的監(jiān)控值顯示YGC的時間在4-5ms之間。是可以接受范圍。SurvivorRatio這個值還得在仔細考慮下,有待優(yōu)化中網(wǎng)上某個牛人的配置:每天幾百萬pv一點問題都沒有，網(wǎng)站沒有停頓$JAVA_ARGS.="-Dresin.home=$SERVER_ROOT-server-Xms6000M-Xmx6000M-Xmn500M-XX:PermSize=500M-XX:MaxPermSize=500M-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0-Xnoclassgc-XX:+DisableExplicitGC-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:-CMSParallelRemarkEnabled-XX:CMSInitiatingOccupancyFraction=90-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log";說明一下，-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0就是去掉了救助空間；-Xnoclassgc禁用類垃圾回收，性能會高一點；-XX:+DisableExplicitGC禁止System.gc()，免得程序員誤調(diào)用gc方法影響性能；-XX:+UseParNewGC，對年輕代采用多線程并行回收，這樣收得快；帶CMS參數(shù)的都是和并發(fā)回收相關(guān)的，不明白的可以上網(wǎng)搜索；CMSInitiatingOccupancyFraction，這個參數(shù)設(shè)置有很大技巧，基本上滿足(Xmx-Xmn)*(100–CMSInitiatingOccupancyFraction)/100>=Xmn就不會出現(xiàn)promotionfailed。在我的應用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是年老代有5500兆，CMSInitiatingOccupancyFraction=90說明年老代到90%滿的時候開始執(zhí)行對年老代的并發(fā)垃圾回收（CMS），這時還剩10%的空間是5500*10%=550兆，所以即使Xmn（也就是年輕代共500兆）里所有對象都搬到年老代里，550兆的空間也足夠了，所以只要滿足上面的公式，就不會出現(xiàn)垃圾回收時的promotionfailed；SoftRefLRUPolicyMSPerMB這個參數(shù)我認為可能有點用，官方解釋是softlyreachableobjectswillremainaliveforsomeamountoftimeafterthelasttimetheywerereferenced.Thedefaultvalueisonesecondoflifetimeperfreemegabyteintheheap，我覺得沒必要等1秒；-Xmx4000M-Xms4000M-Xmn600M-XX:PermSize=500M-XX:MaxPermSize=500M-Xss256K-XX:+DisableExplicitGC-XX:SurvivorRatio=1-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M-XX:+UseFastAccessorMethods-