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

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

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

gclogFGCold空間不足perm空間不足

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

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

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

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