99热在线精品一区二区三区_国产伦精品一区二区三区女破破_亚洲一区二区三区无码_精品国产欧美日韩另类一区

堆大小設(shè)置
JVM 中最大堆大小有三方面限制:相關(guān)操作系統(tǒng)的數(shù)據(jù)模型(32-bt還是64-bit)限制;系統(tǒng)的可用虛擬內(nèi)存限制;系統(tǒng)的可用物理內(nèi)存限制.32位系統(tǒng) 下,一般限制在1.5G~2G;64為操作系統(tǒng)對(duì)內(nèi)存無(wú)限制.我在Windows Server 2003 系統(tǒng),3.5G物理內(nèi)存,JDK5.0下測(cè)試,最大可設(shè)置為1478m.
典型設(shè)置: 
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m:設(shè)置JVM最大可用內(nèi)存為3550M.
-Xms3550m:設(shè)置JVM促使內(nèi)存為3550m.此值可以設(shè)置與-Xmx相同,以避免每次垃圾回收完成后JVM重新分配內(nèi)存.
-Xmn2g:設(shè)置年輕代大小為2G.整個(gè)堆大小=年輕代大小 + 年老代大小 + 持久代大小.持久代一般固定大小為64m,所以增大年輕代后,將會(huì)減小年老代大小.此值對(duì)系統(tǒng)性能影響較大,Sun官方推薦配置為整個(gè)堆的3/8.
-Xss128k: 設(shè)置每個(gè)線程的堆棧大小.JDK5.0以后每個(gè)線程堆棧大小為1M,以前每個(gè)線程堆棧大小為256K.更具應(yīng)用的線程所需內(nèi)存大小進(jìn)行 調(diào)整.在相同物理內(nèi)存下,減小這個(gè)值能生成更多的線程.但是操作系統(tǒng)對(duì)一個(gè)進(jìn)程內(nèi)的線程數(shù)還是有限制的,不能無(wú)限生成,經(jīng)驗(yàn)值在3000~5000左右.

屏南ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書(shū)未來(lái)市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書(shū)銷售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書(shū)合作）期待與您的合作！

java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:設(shè)置年輕代(包括Eden和兩個(gè)Survivor區(qū))與年老代的比值(除去持久代).設(shè)置為4,則年輕代與年老代所占比值為1:4,年輕代占整個(gè)堆棧的1/5
-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)過(guò)Survivor區(qū),直接進(jìn)入年老代. 對(duì)于年老代比較多的應(yīng)用,可以提高效率.如果將此值設(shè)置為一個(gè)較大值,則年輕代對(duì)象會(huì)在Survivor區(qū)進(jìn)行多次復(fù)制,這樣可以增加對(duì)象再年輕代的存活 時(shí)間,增加在年輕代即被回收的概論.
回收器選擇
JVM給了三種選擇:串行收集器,并行收集器,并發(fā)收集器,但是串行收集器只適用于小數(shù)據(jù)量的情況,所以這里的選擇主要針對(duì)并行收集器和并發(fā)收集器.默認(rèn) 情況下,JDK5.0以前都是使用串行收集器,如果想使用其他收集器需要在啟動(dòng)時(shí)加入相應(yīng)參數(shù).JDK5.0以后,JVM會(huì)根據(jù)當(dāng)前系統(tǒng)配置進(jìn)行判斷. 
吞吐量?jī)?yōu)先的并行收集器
如上文所述,并行收集器主要以到達(dá)一定的吞吐量為目標(biāo),適用于科學(xué)技術(shù)和后臺(tái)處理等.
典型配置: 
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC:選擇垃圾收集器為并行收集器.此配置僅對(duì)年輕代有效.即上述配置下,年輕代使用并發(fā)收集,而年老代仍舊使用串行收集.
-XX:ParallelGCThreads=20:配置并行收集器的線程數(shù),即:同時(shí)多少個(gè)線程一起進(jìn)行垃圾回收.此值最好配置與處理器數(shù)目相等.

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC:配置年老代垃圾收集方式為并行收集.JDK6.0支持對(duì)年老代并行收集.

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:設(shè)置每次年輕代垃圾回收的最長(zhǎng)時(shí)間,如果無(wú)法滿足此時(shí)間,JVM會(huì)自動(dòng)調(diào)整年輕代大小,以滿足此值.

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy:設(shè)置此選項(xiàng)后,并行收集器會(huì)自動(dòng)選擇年輕代區(qū)大小和相應(yīng)的Survivor區(qū)比例,以達(dá)到目標(biāo)系統(tǒng)規(guī)定的最低相應(yīng)時(shí)間或者收集頻率等,此值建議使用并行收集器時(shí),一直打開(kāi).

響應(yīng)時(shí)間優(yōu)先的并發(fā)收集器
如上文所述,并發(fā)收集器主要是保證系統(tǒng)的響應(yīng)時(shí)間,減少垃圾收集時(shí)的停頓時(shí)間.適用于應(yīng)用服務(wù)器,電信領(lǐng)域等.
典型配置: 
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC:設(shè)置年老代為并發(fā)收集.測(cè)試中配置這個(gè)以后,-XX:NewRatio=4的配置失效了,原因不明.所以,此時(shí)年輕代大小最好用-Xmn設(shè)置.
-XX:+UseParNewGC:設(shè)置年輕代為并行收集.可與CMS收集同時(shí)使用.JDK5.0以上,JVM會(huì)根據(jù)系統(tǒng)配置自行設(shè)置,所以無(wú)需再設(shè)置此值. 
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction:由于并發(fā)收集器不對(duì)內(nèi)存空間進(jìn)行壓縮,整理,所以運(yùn)行一段時(shí)間以后會(huì)產(chǎn)生"碎片",使得運(yùn)行效率降低.此值設(shè)置運(yùn)行多少次GC以后對(duì)內(nèi)存空間進(jìn)行壓縮,整理.
-XX:+UseCMSCompactAtFullCollection:打開(kāi)對(duì)年老代的壓縮.可能會(huì)影響性能,但是可以消除碎片

輔助信息
JVM提供了大量命令行參數(shù),打印信息,供調(diào)試使用.主要有以下一些: 
-XX:+PrintGC
輸出形式:[GC 118250K->113543K(130112K), 0.0094143 secs] 
[Full GC 121376K->10414K(130112K), 0.0650971 secs]

-XX:+PrintGCDetails
輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] 
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]

-XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps可與上面兩個(gè)混合使用
輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前,程序未中斷的執(zhí)行時(shí)間.可與上面混合使用
輸出形式:Application time: 0.5291524 seconds

-XX:+PrintGCApplicationStoppedTime:打印垃圾回收期間程序暫停的時(shí)間.可與上面混合使用
輸出形式:Total time for which application threads were stopped: 0.0468229 seconds

-XX:PrintHeapAtGC:打印GC前后的詳細(xì)堆棧信息
輸出形式:
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]

-Xloggc:filename:與上面幾個(gè)配合使用,把相關(guān)日志信息記錄到文件以便分析.
常見(jiàn)配置匯總 
堆設(shè)置 
-Xms:初始堆大小 
-Xmx:最大堆大小 
-XX:NewSize=n:設(shè)置年輕代大小 
-XX:NewRatio=n:設(shè)置年輕代和年老代的比值.如:為3,表示年輕代與年老代比值為1:3,年輕代占整個(gè)年輕代年老代和的1/4 
-XX:SurvivorRatio=n:年輕代中Eden區(qū)與兩個(gè)Survivor區(qū)的比值.注意Survivor區(qū)有兩個(gè).如:3,表示Eden:Survivor=3:2,一個(gè)Survivor區(qū)占整個(gè)年輕代的1/5 
-XX:MaxPermSize=n:設(shè)置持久代大小
收集器設(shè)置 
-XX:+UseSerialGC:設(shè)置串行收集器 
-XX:+UseParallelGC:設(shè)置并行收集器 
-XX:+UseParalledlOldGC:設(shè)置并行年老代收集器 
-XX:+UseConcMarkSweepGC:設(shè)置并發(fā)收集器
垃圾回收統(tǒng)計(jì)信息 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-Xloggc:filename
并行收集器設(shè)置 
-XX:ParallelGCThreads=n:設(shè)置并行收集器收集時(shí)使用的CPU數(shù).并行收集線程數(shù). 
-XX:MaxGCPauseMillis=n:設(shè)置并行收集最大暫停時(shí)間 
-XX:GCTimeRatio=n:設(shè)置垃圾回收時(shí)間占程序運(yùn)行時(shí)間的百分比.公式為1/(1+n)
并發(fā)收集器設(shè)置 
-XX:+CMSIncrementalMode:設(shè)置為增量模式.適用于單CPU情況. 
-XX:ParallelGCThreads=n:設(shè)置并發(fā)收集器年輕代收集方式為并行收集時(shí),使用的CPU數(shù).并行收集線程數(shù).

調(diào)優(yōu)總結(jié) 
年輕代大小選擇 
響應(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í)間沒(méi)有要求,垃圾收集可以并行進(jìn)行,一般適合8CPU以上的應(yīng)用.
年老代大小選擇 
響應(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í)間比例
減少年輕代和年老代花費(fèi)的時(shí)間,一般會(huì)提高應(yīng)用的效率

吞吐量?jī)?yōu)先的應(yīng)用:一般吞吐量?jī)?yōu)先的應(yīng)用都有一個(gè)很大的年輕代和一個(gè)較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對(duì)象,減少中期的對(duì)象,而年老代盡存放長(zhǎng)期存活對(duì)象.
較小堆引起的碎片問(wèn)題
因?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í),開(kāi)啟對(duì)年老代的壓縮. 
-XX:CMSFullGCsBeforeCompaction=0:上面配置開(kāi)啟的情況下,這里設(shè)置多少次Full GC后,對(duì)年老代進(jìn)行壓縮

在同一個(gè)工程下,有兩個(gè)類,這兩個(gè)類中只有很少的變動(dòng),而最關(guān)健的FOR卻沒(méi)有一點(diǎn)變動(dòng),可是當(dāng)我分別運(yùn)行這兩個(gè)程序的時(shí)候卻出現(xiàn)一個(gè)很嚴(yán)重的問(wèn)題,一個(gè)程序循環(huán)的快,一個(gè)循環(huán)的慢.這到底是怎么回事呢~???苦苦尋找了半天也沒(méi)有想到是為什么,因?yàn)槌绦蚋淖兊牟糠指挥绊懳已h(huán)的速度,可是結(jié)果卻是有很大的差別,一個(gè)大約是在一分鐘這內(nèi)就可以循環(huán)完,可是另一個(gè)卻需要六七分鐘,這根本就不是一個(gè)數(shù)據(jù)理級(jí)的麻.兩個(gè)完全一樣的循環(huán),從代碼上根本上是看不出有什么問(wèn)題.不得以求助同事吧,可是同事看了也感覺(jué)很詭異,兩個(gè)人在那訂著代碼又看了一個(gè)多小時(shí),最后同事讓我來(lái)個(gè)干凈點(diǎn)的,關(guān)機(jī)重啟.我到也聽(tīng)話,就順著同事的意思去了,可就在關(guān)機(jī)的這個(gè)時(shí)候他突然說(shuō)是不是內(nèi)存的問(wèn)題,我也空然想到了,還真的有可能是內(nèi)存的問(wèn)題,因?yàn)榭斓哪莻€(gè)在我之前運(yùn)行程序之前可給過(guò)1G的內(nèi)存啊,而后來(lái)的這個(gè)我好像是沒(méi)有設(shè)過(guò)內(nèi)存啊,機(jī)器起來(lái)了,有了這個(gè)想法進(jìn)去看看吧,結(jié)果正中要害,果真是慢的那個(gè)沒(méi)有開(kāi)內(nèi)存,程序運(yùn)行時(shí)只不過(guò)是JVM默認(rèn)開(kāi)的內(nèi)存.我初步分析是因?yàn)閮?nèi)存太小,而我的程序所用內(nèi)存又正好卡在JVM所開(kāi)內(nèi)存邊上,不至于溢出.當(dāng)程序運(yùn)行時(shí)就得花費(fèi)大部分時(shí)間去調(diào)用GC去,這樣就導(dǎo)致了為什么相同的循環(huán)出現(xiàn)兩種不同的效率~!
順便把內(nèi)存使用情況的方法也貼出來(lái):
public static String getMemUsage() {
long free = java.lang.Runtime.getRuntime().freeMemory();
long total = java.lang.Runtime.getRuntime().totalMemory(); 
StringBuffer buf = new StringBuffer();
buf.append("[Mem: used ").append((total-free)>>20)
.append("M free ").append(free>>20)
.append("M total ").append(total>>20).append("M]");
return buf.toString();
}

google一下,大概就說(shuō)JVM是這樣來(lái)操作內(nèi)存:
堆(Heap)和非堆(Non-heap)內(nèi)存
按照官方的說(shuō)法:"Java 虛擬機(jī)具有一個(gè)堆,堆是運(yùn)行時(shí)數(shù)據(jù)區(qū)域,所有類實(shí)例和數(shù)組的內(nèi)存均從此處分配.堆是在 Java 虛擬機(jī)啟動(dòng)時(shí)創(chuàng)建的.""在JVM中堆之外的內(nèi)存稱為非堆內(nèi)存(Non-heap memory)".可以看出JVM主要管理兩種類型的內(nèi)存:堆和非堆.簡(jiǎn)單來(lái)說(shuō)堆就是Java代碼可及的內(nèi)存,是留給開(kāi)發(fā)人員使用的;非堆就是JVM留給自己用的,所以方法區(qū),JVM內(nèi)部處理或優(yōu)化所需的內(nèi)存(如JIT編譯后的代碼緩存),每個(gè)類結(jié)構(gòu)(如運(yùn)行時(shí)常數(shù)池,字段和方法數(shù)據(jù))以及方法和構(gòu)造方法的代碼都在非堆內(nèi)存中.
堆內(nèi)存分配
JVM初始分配的內(nèi)存由-Xms指定,默認(rèn)是物理內(nèi)存的1/64;JVM最大分配的內(nèi)存由-Xmx指定,默認(rèn)是物理內(nèi)存的1/4.默認(rèn)空余堆內(nèi)存小于40%時(shí),JVM就會(huì)增大堆直到-Xmx的最大限制;空余堆內(nèi)存大于70%時(shí), JVM會(huì)減少堆直到-Xms的最小限制.因此服務(wù)器一般設(shè)置-Xms,-Xmx相等以避免在每次GC 后調(diào)整堆的大小.
非堆內(nèi)存分配
JVM使用-XX:PermSize設(shè)置非堆內(nèi)存初始值,默認(rèn)是物理內(nèi)存的1/64;由XX:MaxPermSize設(shè)置最大非堆內(nèi)存的大小,默認(rèn)是物理內(nèi)存的1/4.
JVM內(nèi)存限制(最大值)
首先JVM內(nèi)存首先受限于實(shí)際的最大物理內(nèi)存,假設(shè)物理內(nèi)存無(wú)限大的話,JVM內(nèi)存的最大值跟操作系統(tǒng)有很大的關(guān)系.簡(jiǎn)單的說(shuō)就32位處理器雖然可控內(nèi)存空間有4GB,但是具體的操作系統(tǒng)會(huì)給一個(gè)限制,這個(gè)限制一般是 2GB-3GB(一般來(lái)說(shuō)Windows系統(tǒng)下為1.5G-2G,Linux系統(tǒng)下為2G-3G),而64bit以上的處理器就不會(huì)有限制了
JVM內(nèi)存的調(diào)優(yōu)
1. Heap設(shè)定與垃圾回收J(rèn)ava Heap分為3個(gè)區(qū),Young,Old和Permanent.Young保存剛實(shí)例化的對(duì)象.當(dāng)該區(qū)被填滿時(shí),GC會(huì)將對(duì)象移到Old 區(qū).Permanent區(qū)則負(fù)責(zé)保存反射對(duì)象,本文不討論該區(qū).JVM的Heap分配可以使用-X參數(shù)設(shè)定,
-Xms
初始Heap大小
-Xmx
java heap最大值
-Xmn
young generation的heap大小
JVM有2個(gè)GC線程.第一個(gè)線程負(fù)責(zé)回收Heap的Young區(qū).第二個(gè)線程在Heap不足時(shí),遍歷Heap,將Young 區(qū)升級(jí)為Older區(qū).Older區(qū)的大小等于-Xmx減去-Xmn,不能將-Xms的值設(shè)的過(guò)大,因?yàn)榈诙€(gè)線程被迫運(yùn)行會(huì)降低JVM的性能.
為什么一些程序頻繁發(fā)生GC?有如下原因:
l 程序內(nèi)調(diào)用了System.gc()或Runtime.gc().
l 一些中間件軟件調(diào)用自己的GC方法,此時(shí)需要設(shè)置參數(shù)禁止這些GC.
l Java的Heap太小,一般默認(rèn)的Heap值都很小.
l 頻繁實(shí)例化對(duì)象,Release對(duì)象.此時(shí)盡量保存并重用對(duì)象,例如使用StringBuffer()和String().
如果你發(fā)現(xiàn)每次GC后,Heap的剩余空間會(huì)是總空間的50%,這表示你的Heap處于健康狀態(tài).許多Server端的Java程序每次GC后最好能有65%的剩余空間.經(jīng)驗(yàn)之談:
1．Server端JVM最好將-Xms和-Xmx設(shè)為相同值.為了優(yōu)化GC,最好讓-Xmn值約等于-Xmx的1/3[2].
2．一個(gè)GUI程序最好是每10到20秒間運(yùn)行一次GC,每次在半秒之內(nèi)完成[2].
注意:
1．增加Heap的大小雖然會(huì)降低GC的頻率,但也增加了每次GC的時(shí)間.并且GC運(yùn)行時(shí),所有的用戶線程將暫停,也就是GC期間,Java應(yīng)用程序不做任何工作.
2．Heap大小并不決定進(jìn)程的內(nèi)存使用量.進(jìn)程的內(nèi)存使用量要大于-Xmx定義的值,因?yàn)镴ava為其他任務(wù)分配內(nèi)存,例如每個(gè)線程的Stack等.
2．Stack的設(shè)定
每個(gè)線程都有他自己的Stack.
-Xss
每個(gè)線程的Stack大小
Stack的大小限制著線程的數(shù)量.如果Stack過(guò)大就好導(dǎo)致內(nèi)存溢漏.-Xss參數(shù)決定Stack大小,例如-Xss1024K.如果Stack太小,也會(huì)導(dǎo)致Stack溢漏.
3．硬件環(huán)境
硬件環(huán)境也影響GC的效率,例如機(jī)器的種類,內(nèi)存,swap空間,和CPU的數(shù)量.
如果你的程序需要頻繁創(chuàng)建很多transient對(duì)象,會(huì)導(dǎo)致JVM頻繁GC.這種情況你可以增加機(jī)器的內(nèi)存,來(lái)減少Swap空間的使用[2].
4．4種GC
第一種：?jiǎn)尉€程GC,也是默認(rèn)的GC.,該GC適用于單CPU機(jī)器.
第二種：Throughput GC,是多線程的GC,適用于多CPU,使用大量線程的程序.第二種GC與第一種GC相似,不同在于GC在收集

                Young區(qū)是多線程的,但在Old區(qū)和第一種一樣,仍然采用單線程.-XX:+UseParallelGC參數(shù)啟動(dòng)該GC.
第三種：Concurrent Low Pause GC,類似于第一種,適用于多CPU,并要求縮短因GC造成程序停滯的時(shí)間.這種GC可以在Old區(qū)的

               回收同時(shí),運(yùn)行應(yīng)用程序.-XX:+UseConcMarkSweepGC參數(shù)啟動(dòng)該GC.
第四種：Incremental Low Pause GC,適用于要求縮短因GC造成程序停滯的時(shí)間.這種GC可以在Young區(qū)回收的同時(shí),回收

               一部分Old區(qū)對(duì)象.-Xincgc參數(shù)啟動(dòng)該GC.
4種GC的具體描述參見(jiàn)[3].
參考文章:
1. JVM Tuning.

     http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp#garbage-collection
2. Performance tuning Java: Tuning steps
     http://h31007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html
3. Tuning Garbage Collection with the 1.4.2 JavaTM Virtual Machine .
     http://java.sun.com/docs/hotspot/gc1.4.2/

網(wǎng)頁(yè)標(biāo)題：javajvm參數(shù)-Xms-Xmx-Xmn-Xss調(diào)優(yōu)總結(jié)
轉(zhuǎn)載注明：http://ef60e0e.cn/article/psjscd.html