你對(duì)JVM參數(shù)調(diào)優(yōu)的概念了解多少，這里和大家分享一下其方法，如果設(shè)置的不好，JVM不斷執(zhí)行FullGC，將導(dǎo)致整個(gè)系統(tǒng)變得很慢，網(wǎng)站停滯時(shí)間能達(dá)10秒以上，這種情況如果沒隔幾分鐘就來(lái)一次，自己都受不了。

JVM參數(shù)調(diào)優(yōu)實(shí)例解析

關(guān)于JVM參數(shù)調(diào)優(yōu)，對(duì)于很多程序員來(lái)說都是很頭痛的問題，如果設(shè)置的不好，JVM不斷執(zhí)行FullGC，將導(dǎo)致整個(gè)系統(tǒng)變得很慢，網(wǎng)站停滯時(shí)間能達(dá)10秒以上，這種情況如果沒隔幾分鐘就來(lái)一次，自己都受不了。

這種停滯在測(cè)試的時(shí)候看不出來(lái)，只有網(wǎng)站pv達(dá)到數(shù)十萬(wàn)/天的時(shí)候問題就暴露出來(lái)了，要想配置好JVM參數(shù)，需要對(duì)年輕代、年老代、救助空間和***代有一定了解，還要了解JVM內(nèi)存管理邏輯，最終還要根據(jù)自己的應(yīng)用來(lái)做調(diào)整。關(guān)于JVM參數(shù)上網(wǎng)一搜就能搜出一大把，也有很多提供實(shí)踐的例子，我也按照各種例子測(cè)試過，最終還是會(huì)出現(xiàn)問題，經(jīng)過幾個(gè)月的實(shí)踐改善，我就網(wǎng)站（要求無(wú)停滯時(shí)間）的jvm參數(shù)調(diào)優(yōu)給出以下幾條經(jīng)驗(yàn)。

1：建議用64位操作系統(tǒng)，Linux下64位的JDK比32位JDK要慢一些，但是吃得內(nèi)存更多，吞吐量更大。

2：XMX和XMS設(shè)置一樣大，MaxPermSize和MinPermSize設(shè)置一樣大，這樣可以減輕伸縮堆大小帶來(lái)的壓力。

3：調(diào)試的時(shí)候設(shè)置一些打印參數(shù)，如-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log，這樣可以從gc.log里看出一些端倪出來(lái)。

4：系統(tǒng)停頓的時(shí)候可能是GC的問題也可能是程序的問題，多用Jmap和Jstack查看，或者killall-3Java，然后查看Java控制臺(tái)日志，能看出很多問題。有一次，網(wǎng)站突然很慢，Jstack一看，原來(lái)是自己寫的URLConnection連接太多沒有釋放，改一下程序就OK了。

5：仔細(xì)了解自己的應(yīng)用，如果用了緩存，那么年老代應(yīng)該大一些，緩存的HashMap不應(yīng)該無(wú)限制長(zhǎng)，建議采用LRU算法的Map做緩存，LRUMap的***長(zhǎng)度也要根據(jù)實(shí)際情況設(shè)定。

6：垃圾回收時(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ì)象。

7：不管怎樣，***代還是會(huì)逐漸變滿，所以隔三差五重起Java服務(wù)器是必要的，我每天都自動(dòng)重起。

8：采用并發(fā)回收時(shí)，年輕代小一點(diǎn)，年老代要大，因?yàn)槟昀洗笥玫氖遣l(fā)回收，即使時(shí)間長(zhǎng)點(diǎn)也不會(huì)影響其他程序繼續(xù)運(yùn)行，網(wǎng)站不會(huì)停頓，我的最終配置如下（系統(tǒng)8G內(nèi)存），每天幾百萬(wàn)PV一點(diǎn)問題都沒有，網(wǎng)站沒有停頓，2009年網(wǎng)站沒有因?yàn)閮?nèi)存問題down過機(jī)。

$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禁用類垃圾回收，性能會(huì)高一點(diǎn)；
◆-XX:+DisableExplicitGC禁止System.gc()，免得程序員誤調(diào)用gc方法影響性能；
◆-XX:+UseParNewGC，對(duì)年輕代采用多線程并行回收，這樣收得快；帶CMS參數(shù)的都是和并發(fā)回收相關(guān)的。

CMSInitiatingOccupancyFraction

這個(gè)JVM參數(shù)設(shè)置有很大技巧，基本上滿足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不會(huì)出現(xiàn)promotionfailed。在我的應(yīng)用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是年老代有5500兆，CMSInitiatingOccupancyFraction=90說明年老代到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秒；

網(wǎng)上其他介紹JVM參數(shù)的也比較多，估計(jì)其中大部分是沒有遇到PromotionFailed，或者訪問量太小沒有機(jī)會(huì)遇到，(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn這個(gè)公式絕對(duì)是原創(chuàng)，真遇到PromotionFailed了，還得這么處理。
 

【編輯推薦】

1. JVM參數(shù)調(diào)優(yōu)八大技巧
2. 解決JVM***內(nèi)存設(shè)置問題
3. 高手教大家如何配置JVM參數(shù)
4. 詳解Tomcat配置JVM參數(shù)步驟
5. 深入學(xué)習(xí)JVM內(nèi)存設(shè)置原理和調(diào)優(yōu)