實(shí)例講解JVM參數(shù)調(diào)優(yōu)的八條經(jīng)驗(yàn)
要想配置好JVM參數(shù)，需要對(duì)年輕代、年老代、救助空間和***代有一定了解，還要了解jvm內(nèi)存管理邏輯，最終還要根據(jù)自己的應(yīng)用來(lái)做調(diào)整。關(guān)于JVM參數(shù)上網(wǎng)一搜就能搜出一大把，也有很多提供實(shí)踐的例子，我也按照各種例子測(cè)試過(guò)，最終還是會(huì)出現(xiàn)問(wèn)題。
經(jīng)過(guò)幾個(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的問(wèn)題也可能是程序的問(wèn)題，多用jmap和jstack查看，或者killall -3 java，然后查看java控制臺(tái)日志，能看出很多問(wèn)題。有一次，網(wǎng)站突然很慢，jstack一看，原來(lái)是自己寫(xiě)的URLConnection連接太多沒(méi)有釋放，改一下程序就OK了。
5：仔細(xì)了解自己的應(yīng)用，如果用了緩存，那么年老代應(yīng)該大一些，緩存的HashMap不應(yīng)該無(wú)限制長(zhǎng)，建議采用LRU算法的Map做緩存，LRUMap的***長(zhǎng)度也要根據(jù)實(shí)際情況設(shè)定。
6：垃圾回收時(shí)promotion failed是個(gè)很頭痛的問(wèn)題，一般可能是兩種原因產(chǎn)生，***個(gè)原因是救助空間不夠，救助空間里的對(duì)象還不應(yīng)該被移動(dòng)到年老代，但年輕代又有很多對(duì)象需要放入救助空間；第二個(gè)原因是年老代沒(méi)有足夠的空間接納來(lái)自年輕代的對(duì)象；這兩種情況都會(huì)轉(zhuǎn)向Full GC，網(wǎng)站停頓時(shí)間較長(zhǎng)。***個(gè)原因我的最終解決辦法是去掉救助空間，設(shè)置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二個(gè)原因我的解決辦法是設(shè)置CMSInitiatingOccupancyFraction為某個(gè)值（假設(shè)70），這樣年老代空間到70%時(shí)就開(kāi)始執(zhí)行CMS，年老代有足夠的空間接納來(lái)自年輕代的對(duì)象。
7：不管怎樣，***代還是會(huì)逐漸變滿(mǎn)，所以隔三差五重起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èn)題都沒(méi)有，網(wǎng)站沒(méi)有停頓，2009年網(wǎng)站沒(méi)有因?yàn)閮?nèi)存問(wèn)題down過(guò)機(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 ";
說(shuō)明一下， -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0就是去掉了救助空間；
-Xnoclassgc禁用類(lèi)垃圾回收，性能會(huì)高一點(diǎn)；
-XX:+DisableExplicitGC禁止System.gc()，免得程序員誤調(diào)用gc方法影響性能；
-XX:+UseParNewGC，對(duì)年輕代采用多線(xiàn)程并行回收，這樣收得快；
帶CMS參數(shù)的都是和并發(fā)回收相關(guān)的，不明白的可以上網(wǎng)搜索；
CMSInitiatingOccupancyFraction，這個(gè)參數(shù)設(shè)置有很大技巧，基本上滿(mǎn)足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn就不會(huì)出現(xiàn)promotion failed。在我的應(yīng)用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是年老代有5500兆，CMSInitiatingOccupancyFraction=90說(shuō)明年老代到90%滿(mǎn)的時(shí)候開(kāi)始執(zhí)行對(duì)年老代的并發(fā)垃圾回收（CMS），這時(shí)還剩10%的空間是5500*10%=550兆，所以即使Xmn（也就是年輕代共500兆）里所有對(duì)象都搬到年老代里，550兆的空間也足夠了，所以只要滿(mǎn)足上面的公式，就不會(huì)出現(xiàn)垃圾回收時(shí)的promotion failed；
SoftRefLRUPolicyMSPerMB這個(gè)參數(shù)我認(rèn)為可能有點(diǎn)用，官方解釋是softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap，我覺(jué)得沒(méi)必要等1秒；
網(wǎng)上其他介紹JVM參數(shù)的也比較多，估計(jì)其中大部分是沒(méi)有遇到promotion failed，或者訪問(wèn)量太小沒(méi)有機(jī)會(huì)遇到，(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn這個(gè)公式絕對(duì)是原創(chuàng)，真遇到promotion failed了，還得這么處理。
【編輯推薦】
