這里向大家描述一下JVM參數(shù)配置的具體步驟，比如heapsize的配置，-Xms<n>指定jvm的最小heap大小,如:-Xms=2g，高并發(fā)應(yīng)用，建議和-Xmx一樣，防止因?yàn)閮?nèi)存收縮／突然增大帶來的性能影響。

JVM參數(shù)配置詳解

1:JVM參數(shù)配置之heapsize

a:-Xmx<n>
指定jvm的最大heap大小,如:-Xmx=2g

b:-Xms<n>
指定jvm的最小heap大小,如:-Xms=2g，高并發(fā)應(yīng)用，建議和-Xmx一樣，防止因?yàn)閮?nèi)存收縮／突然增大帶來的性能影響。

c:-Xmn<n>
指定jvm中NewGeneration的大小,如:-Xmn256m。這個(gè)參數(shù)很影響性能，如果你的程序需要比較多的臨時(shí)內(nèi)存，建議設(shè)置到512M，如果用的少，盡量降低這個(gè)數(shù)值，一般來說128／256足以使用了。

d:-XX:PermSize=<n>
指定jvm中PermGeneration的最小值,如:-XX:PermSize=32m。這個(gè)參數(shù)需要看你的實(shí)際情況，?？梢酝ㄟ^jmap命令看看到底需要多少。

e:-XX:MaxPermSize=<n>
指定PermGeneration的最大值,如:-XX:MaxPermSize=64m

f:-Xss<n>
指定線程桟大小,如:-Xss128k，一般來說，webx框架下的應(yīng)用需要256K。如果你的程序有大規(guī)模的遞歸行為，請考慮設(shè)置到512K／1M。這個(gè)需要全面的測試才能知道。不過，256K已經(jīng)很大了。這個(gè)參數(shù)對性能的影響比較大的。

g:-XX:NewRatio=<n>
指定jvm中OldGenerationheapsize與NewGeneration的比例,在使用CMSGC的情況下此參數(shù)失效,如:-XX:NewRatio=2

h:-XX:SurvivorRatio=<n>
指定NewGeneration中EdenSpace與一個(gè)SurvivorSpace的heapsize比例,-XX:SurvivorRatio=8,那么在總共NewGeneration為10m的情況下,EdenSpace為8m

i:-XX:MinHeapFreeRatio=<n>
指定jvmheap在使用率小于n的情況下,heap進(jìn)行收縮,Xmx==Xms的情況下無效,如:-XX:MinHeapFreeRatio=30

j:-XX:MaxHeapFreeRatio=<n>
指定jvmheap在使用率大于n的情況下,heap進(jìn)行擴(kuò)張,Xmx==Xms的情況下無效,如:-XX:MaxHeapFreeRatio=70

k:-XX:LargePageSizeInBytes=<n>
指定Javaheap的分頁頁面大小,如:-XX:LargePageSizeInBytes=128m#p#

2:JVM參數(shù)配置之garbagecollector

a:-XX:+UseParallelGC
指定在NewGeneration使用parallelcollector,并行收集,暫停appthreads,同時(shí)啟動(dòng)多個(gè)垃圾回收thread,不能和CMSgc一起使用.系統(tǒng)噸吐量優(yōu)先,但是會(huì)有較長長時(shí)間的apppause,后臺(tái)系統(tǒng)任務(wù)可以使用此gc

b:-XX:ParallelGCThreads=<n>
指定parallelcollection時(shí)啟動(dòng)的thread個(gè)數(shù),默認(rèn)是物理processor的個(gè)數(shù),

c:-XX:+UseParallelOldGC
指定在OldGeneration使用parallelcollector

d:-XX:+UseParNewGC
指定在NewGeneration使用parallelcollector,是UseParallelGC的gc的升級(jí)版本,有更好的性能或者優(yōu)點(diǎn),可以和CMSgc一起使用

e:-XX:+CMSParallelRemarkEnabled
在使用UseParNewGC的情況下,盡量減少mark的時(shí)間

f:-XX:+UseConcMarkSweepGC
指定在OldGeneration使用concurrentcmarksweepgc,gcthread和appthread并行(在init-mark和remark時(shí)pauseappthread).apppause時(shí)間較短,適合交互性強(qiáng)的系統(tǒng),如webserver

g:-XX:+UseCMSCompactAtFullCollection
在使用concurrentgc的情況下,防止memoryfragmention,對liveobject進(jìn)行整理,使memory碎片減少

h:-XX:CMSInitiatingOccupancyFraction=<n>
指示在oldgeneration在使用了n%的比例后,啟動(dòng)concurrentcollector,默認(rèn)值是68,如:-XX:CMSInitiatingOccupancyFraction=70
有個(gè)bug,在低版本(1.5.09andearly)的jvm上出現(xiàn),http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089

i:-XX:+UseCMSInitiatingOccupancyOnly
指示只有在oldgeneration在使用了初始化的比例后concurrentcollector啟動(dòng)收集#p#

3:JVM參數(shù)配置之其他

a:-XX:MaxTenuringThreshold=<n>
指定一個(gè)object在經(jīng)歷了n次younggc后轉(zhuǎn)移到oldgeneration區(qū),在linux64的java6下默認(rèn)值是15,此參數(shù)對于throughputcollector無效,如:-XX:MaxTenuringThreshold=31

b:-XX:+DisableExplicitGC
禁止java程序中的fullgc,如System.gc()的調(diào)用.最好加上么，防止程序在代碼里誤用了。對性能造成沖擊。

c:-XX:+UseFastAccessorMethods
get,set方法轉(zhuǎn)成本地代碼

d:-XX:+PrintGCDetails
打應(yīng)垃圾收集的情況如:
[GC15610.466:[ParNew:229689K->20221K(235968K),0.0194460secs]1159829K->953935K(2070976K),0.0196420secs]

e:-XX:+PrintGCTimeStamps
打應(yīng)垃圾收集的時(shí)間情況,如:
[Times:user=0.09sys=0.00,real=0.02secs]

f:-XX:+PrintGCApplicationStoppedTime
打應(yīng)垃圾收集時(shí),系統(tǒng)的停頓時(shí)間,如:
Totaltimeforwhichapplicationthreadswerestopped:0.0225920seconds

4:awebserverproductsampleandprocess

JAVA_OPTS="-server-Xmx2g-Xms2g-Xmn256m  
-XX:PermSize=128m-Xss256k-XX:+DisableExplicitGC  
-XX:+UseConcMarkSweepGC-XX:+UseParNewGC  
-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection  
-XX:LargePageSizeInBytes=128m-XX:+UseFastAccessorMethods  
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70"  

最初的時(shí)候我們用UseParallelGC和UseParallelOldGC,heap開了3G,NewRatio設(shè)成1.這樣的配置下younggc發(fā)生頻率約12,3秒一次,平均每次花費(fèi)80ms左右,fullgc發(fā)生的頻率極低,每次消耗1s左右.從所有g(shù)c消耗系統(tǒng)時(shí)間看,系統(tǒng)使用率還是滿高的,但是不論是younggc還是oldgc,applicatonthreadpause的時(shí)間比較長,不合適web應(yīng)用.我們也調(diào)小NewGeneration的,但是這樣會(huì)使fullgc時(shí)間加長.

后來我們就用CMSgc(-XX:+UseConcMarkSweepGC),當(dāng)時(shí)的總heap還是3g,新生代1.5g后,觀察不是很理想,改為jvmheap為2g新生代設(shè)置-Xmn1g,在這樣的情況下younggc發(fā)生的頻率變成,7,8妙一次,平均每次時(shí)間40~50毫秒左右,CMSgc很少發(fā)生,每次時(shí)間在init-mark和remark(twostepsstopallappthread)總共平均花費(fèi)80~90ms左右.

在這里我們曾經(jīng)NewGeneration調(diào)大到1400m,總共2g的jvmheap,平均每次ygc花費(fèi)時(shí)間60~70ms左右,CMSgc的init-mark和remark之和平均在50ms左右,這里我們意識(shí)到錯(cuò)誤的方向,或者說CMS的作用,所以進(jìn)行了修改

最后我們調(diào)小NewGeneration為256m,younggc2,3秒發(fā)生一次,平均停頓時(shí)間在25毫秒左右,CMSgc的init-mark和remark之和平均在50ms左右,這樣使系統(tǒng)比較平滑,經(jīng)壓力測試,這個(gè)配置下系統(tǒng)性能是比較高的

在使用CMSgc的時(shí)候他有兩種觸發(fā)gc的方式:gc估算觸發(fā)和heap占用觸發(fā).我們的1.5.0.09環(huán)境下有次old區(qū)heap占用再30%左右,她就頻繁gc,個(gè)人感覺系統(tǒng)估算觸發(fā)這種方式不靠譜,還是用heap使用比率觸發(fā)比較穩(wěn)妥.

這些數(shù)據(jù)都來自64位測試機(jī),過程中的數(shù)據(jù)都是我在jbosslog找的,當(dāng)時(shí)沒有記下來,可能存在一點(diǎn)點(diǎn)偏差,但不會(huì)很大,基本過程就是這樣.

5:JVM參數(shù)配置總結(jié)

webserver作為交互性要求較高的應(yīng)用,我們應(yīng)該使用Parallel+CMS,UseParNewGC這個(gè)在jdk6-server上是默認(rèn)的,newgenerationgc,新生代不能太大,這樣每次pause會(huì)短一些.CMSmark-sweepgeneration可以大一些,可以根據(jù)pausetime實(shí)際情況控制

【編輯推薦】

1. JVM啟動(dòng)參數(shù)的類別及使用
2. JVM安裝與Tomcat配置具體步驟
3. JVM參數(shù)設(shè)置使用技巧
4. 配置JVM內(nèi)存分配的妙招
5. JVM啟動(dòng)參數(shù)中標(biāo)準(zhǔn)參數(shù)列表速查手冊