對(duì)于有2塊CPU和2GB內(nèi)存及更佳配置的服務(wù)器，Sun的hotspot jdk默認(rèn)設(shè)置了如下參數(shù)：

典型設(shè)置（例子中的堆分配的都比較大，注意自己平臺(tái)的限制，下文同）：

-Xms3550m：設(shè)置JVM促使內(nèi)存為3550m。此值可以設(shè)置與-Xmx相同，以避免每次垃圾回收完成后JVM重新分配內(nèi)存（就是收縮和擴(kuò)張，分代回收加上Sun內(nèi)存分配的算法，避免了IBM JDK最小堆和最大堆一樣上的缺陷，但是這對(duì)-Xms和-Xmx的設(shè)置有了更高的要求，應(yīng)該是多次試驗(yàn)確定一個(gè)合適的大小）。

-Xmn2g：設(shè)置年輕代大小為2G。整個(gè)堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，所以增大年輕代后，將會(huì)減小年老代大小。此值對(duì)系統(tǒng)性能影響較大，Sun官方推薦配置為整個(gè)堆的3/8。從下圖，應(yīng)該可以看到整個(gè)堆大小=年輕代大小 + 年老代大小，Xms和Xmx不包括Perm Size。

線程棧的大小是個(gè)雙刃劍，如果設(shè)置過小，可能會(huì)出現(xiàn)棧溢出，特別是在該線程內(nèi)有遞歸、大的循環(huán)時(shí)

時(shí)出現(xiàn)溢出的可能性更大，如果該值設(shè)置過大，就有影響到創(chuàng)建棧的數(shù)量，如果是多線程的應(yīng)用，就會(huì)

出現(xiàn)內(nèi)存溢出的錯(cuò)誤

-XX:SurvivorRatio=4：設(shè)置年輕代中Eden區(qū)與Survivor區(qū)的大小比值。設(shè)置為4，則兩個(gè)Survivor區(qū)與一個(gè)Eden區(qū)的比值為2:4，一個(gè)Survivor區(qū)占整個(gè)年輕代的1/6

-XX:MaxPermSize=16m:設(shè)置持久代大小為16m。

-XX:MaxTenuringThreshold=0：設(shè)置垃圾最大年齡。如果設(shè)置為0的話，則年輕代對(duì)象不經(jīng)過Survivor區(qū)，直接進(jìn)入年老代。對(duì)于年老代比較多的應(yīng)用，可以提高效率。如果將此值設(shè)置為一個(gè)較大值，則年輕代對(duì)象會(huì)在Survivor區(qū)進(jìn)行多次復(fù)制，這樣可以增加對(duì)象再年輕代的存活時(shí)間，增加在年輕代即被回收的概率。下面要介紹的CMS（并發(fā)）收集器，SurvivorRatio默認(rèn)為1024 MaxTenuringThreshold默認(rèn)為0，可以手動(dòng)調(diào)整，降低年老代的回收壓力，即照顧到吞吐率，又關(guān)注到相應(yīng)時(shí)間。

典型配置：

-XX:ParallelGCThreads=20：配置并行收集器的線程數(shù)，即：同時(shí)多少個(gè)線程一起進(jìn)行垃圾回收。此值最好配置與處理器數(shù)目相等。應(yīng)該等于或者小于cpu數(shù)量（核），否則沒有意義，而當(dāng)服務(wù)器的CPU數(shù)小于等于2時(shí)，用并發(fā)收集和串行收集效率一樣。

典型配置：

-XX:+UseParNewGC:設(shè)置年輕代為并行收集。可與CMS收集同時(shí)使用。JDK5.0以上，JVM會(huì)根據(jù)系統(tǒng)配置自行設(shè)置，所以無需再設(shè)置此值。

-XX:+UseCMSCompactAtFullCollection：打開對(duì)年老代的壓縮。可能會(huì)影響性能，但是可以消除碎片

34.702: [GC {Heap before gc invocations=7:

def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)

eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)

from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000)

to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)

tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)

the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)

compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)

the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)

ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)

rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)

34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:

def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)

eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)

from space 6144K,  55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)

to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)

tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)

the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)

compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)

the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)

ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)

rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)

}

, 0.0757599 secs]

四、調(diào)優(yōu)總結(jié)

減少年輕代和年老代花費(fèi)的時(shí)間，一般會(huì)提高應(yīng)用的效率

五、PDF中提到的另外一些參數(shù)

-XX:+AggressiveOpts：作用如其名（aggressive），啟用這個(gè)參數(shù)，則每當(dāng)JDK版本升級(jí)時(shí)，你的JVM都會(huì)使用最新加入的優(yōu)化技術(shù)（如果有的話）

-XX:+UseBiasedLocking：不是很理解，請(qǐng)自行閱讀http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2.5

五、參考資料

Java HotSpot VM Options

Java Tuning White Paper

Diagnosing a Garbage Collection problem

J2SE 5.0 Performance White Paper

Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine

Garbage Collector Ergonomics

Can anyone help me understand UseAdaptiveSizePolicy flag?