JVM系列三:JVM參數(shù)設(shè)置邀层、分析 - redcreen - 博客園 http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html

不管是YGC還是Full GC,GC過程中都會(huì)對導(dǎo)致程序運(yùn)行中中斷,正確的選擇不同的GC策略,調(diào)整JVM、GC的參數(shù)遂庄，可以極大的減少由于GC工作寥院，而導(dǎo)致的程序運(yùn)行中斷方面的問題，進(jìn)而適當(dāng)?shù)奶岣逬ava程序的工作效率涛目。但是調(diào)整GC是以個(gè)極為復(fù)雜的過程秸谢，由于各個(gè)程序具備不同的特點(diǎn)，如：web和GUI程序就有很大區(qū)別（Web可以適當(dāng)?shù)耐ｎD霹肝，但GUI停頓是客戶無法接受的）估蹄，而且由于跑在各個(gè)機(jī)器上的配置不同（主要cup個(gè)數(shù)，內(nèi)存不同）沫换，所以使用的GC種類也會(huì)不同(如何選擇見GC種類及如何選擇)臭蚁。本文將注重介紹JVM、GC的一些重要參數(shù)的設(shè)置來提高系統(tǒng)的性能苗沧。
JVM內(nèi)存組成及GC相關(guān)內(nèi)容請見之前的文章:JVM內(nèi)存組成 GC策略&內(nèi)存申請刊棕。
**JVM參數(shù)的含義 **實(shí)例見實(shí)例分析
參數(shù)名稱
含義
默認(rèn)值

-Xms
初始堆大小
物理內(nèi)存的1/64(<1GB)
默認(rèn)(MinHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存小于40%時(shí)，JVM就會(huì)增大堆直到-Xmx的最大限制.

-Xmx
最大堆大小
物理內(nèi)存的1/4(<1GB)
默認(rèn)(MaxHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存大于70%時(shí)待逞，JVM會(huì)減少堆直到 -Xms的最小限制

-Xmn
年輕代大小(1.4or lator)

注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不同的甥角。整個(gè)堆大小=年輕代大小 + 年老代大小 + 持久代大小.增大年輕代后,將會(huì)減小年老代大小.此值對系統(tǒng)性能影響較大,Sun官方推薦配置為整個(gè)堆的3/8

-XX:NewSize
設(shè)置年輕代大小(for 1.3/1.4)

-XX:MaxNewSize
年輕代最大值(for 1.3/1.4)

-XX:PermSize
設(shè)置持久代(perm gen)初始值
物理內(nèi)存的1/64

-XX:MaxPermSize
設(shè)置持久代最大值
物理內(nèi)存的1/4

-Xss
每個(gè)線程的堆棧大小

JDK5.0以后每個(gè)線程堆棧大小為1M,以前每個(gè)線程堆棧大小為256K.更具應(yīng)用的線程所需內(nèi)存大小進(jìn)行 調(diào)整.在相同物理內(nèi)存下,減小這個(gè)值能生成更多的線程.但是操作系統(tǒng)對一個(gè)進(jìn)程內(nèi)的線程數(shù)還是有限制的,不能無限生成,經(jīng)驗(yàn)值在3000~5000左右一般小的應(yīng)用， 如果棧不是很深识樱， 應(yīng)該是128k夠用的 大的應(yīng)用建議使用256k嗤无。這個(gè)選項(xiàng)對性能影響比較大震束，需要嚴(yán)格的測試。（校長）和threadstacksize選項(xiàng)解釋很類似,官方文檔似乎沒有解釋,在論壇中有這樣一句話:"”-Xss is translated in a VM flag named ThreadStackSize”一般設(shè)置這個(gè)值就可以了当犯。

-XX:ThreadStackSize
Thread Stack Size

(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]

-XX:NewRatio
年輕代(包括Eden和兩個(gè)Survivor區(qū))與年老代的比值(除去持久代)

-XX:NewRatio=4表示年輕代與年老代所占比值為1:4,年輕代占整個(gè)堆棧的1/5Xms=Xmx并且設(shè)置了Xmn的情況下垢村，該參數(shù)不需要進(jìn)行設(shè)置墓怀。

-XX:SurvivorRatio
Eden區(qū)與Survivor區(qū)的大小比值

設(shè)置為8,則兩個(gè)Survivor區(qū)與一個(gè)Eden區(qū)的比值為2:8,一個(gè)Survivor區(qū)占整個(gè)年輕代的1/10

-XX:LargePageSizeInBytes
內(nèi)存頁的大小不可設(shè)置過大月趟， 會(huì)影響Perm的大小

=128m

-XX:+UseFastAccessorMethods
原始類型的快速優(yōu)化

-XX:+DisableExplicitGC
關(guān)閉System.gc()

這個(gè)參數(shù)需要嚴(yán)格的測試

-XX:MaxTenuringThreshold
垃圾最大年齡

如果設(shè)置為0的話,則年輕代對象不經(jīng)過Survivor區(qū),直接進(jìn)入年老代. 對于年老代比較多的應(yīng)用,可以提高效率.如果將此值設(shè)置為一個(gè)較大值,則年輕代對象會(huì)在Survivor區(qū)進(jìn)行多次復(fù)制,這樣可以增加對象再年輕代的存活 時(shí)間,增加在年輕代即被回收的概率該參數(shù)只有在串行GC時(shí)才有效.

-XX:+AggressiveOpts
加快編譯

-XX:+UseBiasedLocking
鎖機(jī)制的性能改善

-Xnoclassgc
禁用垃圾回收

-XX:SoftRefLRUPolicyMSPerMB
每兆堆空閑空間中SoftReference的存活時(shí)間
1s
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

-XX:PretenureSizeThreshold
對象超過多大是直接在舊生代分配
0
單位字節(jié) 新生代采用Parallel Scavenge GC時(shí)無效另一種直接在舊生代分配的情況是大的數(shù)組對象,且數(shù)組中無外部引用對象.

-XX:TLABWasteTargetPercent
TLAB占eden區(qū)的百分比
1%

-XX:+CollectGen0First
FullGC時(shí)是否先YGC
false

并行收集器相關(guān)參數(shù)
-XX:+UseParallelGC
Full GC采用parallel MSC(此項(xiàng)待驗(yàn)證)

選擇垃圾收集器為并行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用并發(fā)收集,而年老代仍舊使用串行收集.(此項(xiàng)待驗(yàn)證)

-XX:+UseParNewGC
設(shè)置年輕代為并行收集

可與CMS收集同時(shí)使用JDK5.0以上,JVM會(huì)根據(jù)系統(tǒng)配置自行設(shè)置,所以無需再設(shè)置此值

-XX:ParallelGCThreads
并行收集器的線程數(shù)

此值最好配置與處理器數(shù)目相等 同樣適用于CMS

-XX:+UseParallelOldGC
年老代垃圾收集方式為并行收集(Parallel Compacting)

這個(gè)是JAVA 6出現(xiàn)的參數(shù)選項(xiàng)

-XX:MaxGCPauseMillis
每次年輕代垃圾回收的最長時(shí)間(最大暫停時(shí)間)

如果無法滿足此時(shí)間,JVM會(huì)自動(dòng)調(diào)整年輕代大小,以滿足此值.

-XX:+UseAdaptiveSizePolicy
自動(dòng)選擇年輕代區(qū)大小和相應(yīng)的Survivor區(qū)比例

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

-XX:GCTimeRatio
設(shè)置垃圾回收時(shí)間占程序運(yùn)行時(shí)間的百分比

公式為1/(1+n)

-XX:+ScavengeBeforeFullGC
Full GC前調(diào)用YGC
true
Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

CMS相關(guān)參數(shù)
-XX:+UseConcMarkSweepGC
使用CMS內(nèi)存收集

測試中配置這個(gè)以后,-XX:NewRatio=4的配置失效了,原因不明.所以,此時(shí)年輕代大小最好用-Xmn設(shè)置.???

-XX:+AggressiveHeap

試圖是使用大量的物理內(nèi)存長時(shí)間大內(nèi)存使用的優(yōu)化运褪，能檢查計(jì)算資源（內(nèi)存集峦， 處理器數(shù)量）至少需要256MB內(nèi)存大量的CPU／內(nèi)存， （在1.4.1在4CPU的機(jī)器上已經(jīng)顯示有提升）

-XX:CMSFullGCsBeforeCompaction
多少次后進(jìn)行內(nèi)存壓縮

由于并發(fā)收集器不對內(nèi)存空間進(jìn)行壓縮,整理,所以運(yùn)行一段時(shí)間以后會(huì)產(chǎn)生"碎片",使得運(yùn)行效率降低.此值設(shè)置運(yùn)行多少次GC以后對內(nèi)存空間進(jìn)行壓縮,整理.

-XX:+CMSParallelRemarkEnabled
降低標(biāo)記停頓

-XX+UseCMSCompactAtFullCollection
在FULL GC的時(shí)候兆览， 對年老代的壓縮

CMS是不會(huì)移動(dòng)內(nèi)存的勃黍， 因此踱蛀， 這個(gè)非常容易產(chǎn)生碎片奠支， 導(dǎo)致內(nèi)存不夠用馋辈， 因此， 內(nèi)存的壓縮這個(gè)時(shí)候就會(huì)被啟用倍谜。 增加這個(gè)參數(shù)是個(gè)好習(xí)慣迈螟。可能會(huì)影響性能,但是可以消除碎片

-XX:+UseCMSInitiatingOccupancyOnly
使用手動(dòng)定義初始化定義開始CMS收集

禁止hostspot自行觸發(fā)CMS GC

-XX:CMSInitiatingOccupancyFraction=70
使用cms作為垃圾回收使用70％后開始CMS收集
92
為了保證不出現(xiàn)promotion failed(見下面介紹)錯(cuò)誤,該值的設(shè)置需要滿足以下公式CMSInitiatingOccupancyFraction計(jì)算公式

-XX:CMSInitiatingPermOccupancyFraction
設(shè)置Perm Gen使用到達(dá)多少比率時(shí)觸發(fā)
92

-XX:+CMSIncrementalMode
設(shè)置為增量模式

用于單CPU情況

-XX:+CMSClassUnloadingEnabled

輔助信息
-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

可與-XX:+PrintGC -XX:+PrintGCDetails混合使用輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+PrintGCApplicationStoppedTime
打印垃圾回收期間程序暫停的時(shí)間.可與上面混合使用

輸出形式:Total time for which application threads were stopped: 0.0468229 seconds

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

輸出形式:Application time: 0.5291524 seconds

-XX:+PrintHeapAtGC
打印GC前后的詳細(xì)堆棧信息

-Xloggc:filename
把相關(guān)日志信息記錄到文件以便分析.與上面幾個(gè)配合使用

-XX:+PrintClassHistogram

garbage collects before printing the histogram.

-XX:+PrintTLAB
查看TLAB空間的使用情況

XX:+PrintTenuringDistribution
查看每次minor GC后新的存活周期的閾值

Desired survivor size 1048576 bytes, new threshold 7 (max 15)new threshold 7即標(biāo)識新的存活周期的閾值為7尔崔。

GC性能方面的考慮
對于GC的性能主要有2個(gè)方面的指標(biāo)：吞吐量throughput（工作時(shí)間不算gc的時(shí)間占總的時(shí)間比）和暫停pause（gc發(fā)生時(shí)app對外顯示的無法響應(yīng)）答毫。

1. Total Heap
   默認(rèn)情況下，vm會(huì)增加/減少heap大小以維持free space在整個(gè)vm中占的比例您旁，這個(gè)比例由MinHeapFreeRatio和MaxHeapFreeRatio指定烙常。
   一般而言，server端的app會(huì)有以下規(guī)則：
   對vm分配盡可能多的memory鹤盒；
   將Xms和Xmx設(shè)為一樣的值。如果虛擬機(jī)啟動(dòng)時(shí)設(shè)置使用的內(nèi)存比較小侦副，這個(gè)時(shí)候又需要初始化很多對象侦锯，虛擬機(jī)就必須重復(fù)地增加內(nèi)存。
   處理器核數(shù)增加秦驯，內(nèi)存也跟著增大尺碰。

2. The Young Generation
   另外一個(gè)對于app流暢性運(yùn)行影響的因素是young generation的大小。young generation越大译隘，minor collection越少亲桥；但是在固定heap size情況下，更大的young generation就意味著小的tenured generation固耘，就意味著更多的major collection(major collection會(huì)引發(fā)minor collection)题篷。
   NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限厅目，將這兩個(gè)值設(shè)為一樣就固定了young generation的大蟹丁（同Xms和Xmx設(shè)為一樣）法严。
   如果希望，SurvivorRatio也可以優(yōu)化survivor的大小葫笼，不過這對于性能的影響不是很大深啤。SurvivorRatio是eden和survior大小比例。
   一般而言路星，server端的app會(huì)有以下規(guī)則：
   首先決定能分配給vm的最大的heap size溯街，然后設(shè)定最佳的young generation的大小洋丐；
   如果heap size固定后呈昔，增加young generation的大小意味著減小tenured generation大小。讓tenured generation在任何時(shí)候夠大垫挨，能夠容納所有l(wèi)ive的data（留10%-20%的空余）韩肝。

經(jīng)驗(yàn)&&規(guī)則
年輕代大小選擇響應(yīng)時(shí)間優(yōu)先的應(yīng)用:盡可能設(shè)大,直到接近系統(tǒng)的最低響應(yīng)時(shí)間限制(根據(jù)實(shí)際情況選擇).在此種情況下,年輕代收集發(fā)生的頻率也是最小的.同時(shí),減少到達(dá)年老代的對象.
吞吐量優(yōu)先的應(yīng)用:盡可能的設(shè)置大,可能到達(dá)Gbit的程度.因?yàn)閷憫?yīng)時(shí)間沒有要求,垃圾收集可以并行進(jìn)行,一般適合8CPU以上的應(yīng)用.
避免設(shè)置過小.當(dāng)新生代設(shè)置過小時(shí)會(huì)導(dǎo)致:1.YGC次數(shù)更加頻繁 2.可能導(dǎo)致YGC對象直接進(jìn)入舊生代,如果此時(shí)舊生代滿了,會(huì)觸發(fā)FGC.

年老代大小選擇響應(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)記清除方式;如果堆大了,則需要較長的收集時(shí)間.最優(yōu)化的方案,一般需要參考以下數(shù)據(jù)獲得:并發(fā)垃圾收集信息、持久代并發(fā)收集次數(shù)九榔、傳統(tǒng)GC信息哀峻、花在年輕代和年老代回收上的時(shí)間比例。
吞吐量優(yōu)先的應(yīng)用:一般吞吐量優(yōu)先的應(yīng)用都有一個(gè)很大的年輕代和一個(gè)較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象.

較小堆引起的碎片問題因?yàn)槟昀洗牟l(fā)收集器使用標(biāo)記,清除算法,所以不會(huì)對堆進(jìn)行壓縮.當(dāng)收集器回收時(shí),他會(huì)把相鄰的空間進(jìn)行合并,這樣可以分配給較大的對象.但是,當(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í),開啟對年老代的壓縮.-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設(shè)置多少次Full GC后,對年老代進(jìn)行壓縮
用64位操作系統(tǒng)哲泊，Linux下64位的jdk比32位jdk要慢一些剩蟀，但是吃得內(nèi)存更多，吞吐量更大
XMX和XMS設(shè)置一樣大切威，MaxPermSize和MinPermSize設(shè)置一樣大育特，這樣可以減輕伸縮堆大小帶來的壓力
****使用CMS的好處是用盡量少的新生代，經(jīng)驗(yàn)值是128M－256M先朦， 然后老生代利用CMS并行收集缰冤， 這樣能保證系統(tǒng)低延遲的吞吐效率。 實(shí)際上cms的收集停頓時(shí)間非常的短喳魏，2G的內(nèi)存棉浸， 大約20－80ms的應(yīng)用程序停頓時(shí)間
系統(tǒng)停頓的時(shí)候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看刺彩，或者killall -3 java迷郑，然后查看java控制臺日志，能看出很多問題创倔。(相關(guān)工具的使用方法將在后面的blog中介紹)
仔細(xì)了解自己的應(yīng)用嗡害，如果用了緩存，那么年老代應(yīng)該大一些畦攘，緩存的HashMap不應(yīng)該無限制長霸妹，建議采用LRU算法的Map做緩存，LRUMap的最大長度也要根據(jù)實(shí)際情況設(shè)定念搬。
采用并發(fā)回收時(shí)抑堡，年輕代小一點(diǎn)摆出，年老代要大，因?yàn)槟昀洗笥玫氖遣l(fā)回收首妖，即使時(shí)間長點(diǎn)也不會(huì)影響其他程序繼續(xù)運(yùn)行偎漫，網(wǎng)站不會(huì)停頓
JVM參數(shù)的設(shè)置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數(shù)的設(shè)置沒有一個(gè)固定的公式，需要根據(jù)PV old區(qū)實(shí)際數(shù)據(jù) YGC次數(shù)等多方面來衡量有缆。為了避免promotion faild可能會(huì)導(dǎo)致xmn設(shè)置偏小象踊，也意味著YGC的次數(shù)會(huì)增多，處理并發(fā)訪問的能力下降等問題棚壁。每個(gè)參數(shù)的調(diào)整都需要經(jīng)過詳細(xì)的性能測試杯矩，才能找到特定應(yīng)用的最佳配置。

promotion failed:
垃圾回收時(shí)promotion failed是個(gè)很頭痛的問題袖外，一般可能是兩種原因產(chǎn)生史隆，第一個(gè)原因是救助空間不夠，救助空間里的對象還不應(yīng)該被移動(dòng)到年老代曼验，但年輕代又有很多對象需要放入救助空間泌射；第二個(gè)原因是年老代沒有足夠的空間接納來自年輕代的對象；這兩種情況都會(huì)轉(zhuǎn)向Full GC鬓照，網(wǎng)站停頓時(shí)間較長熔酷。
解決方方案一：
第一個(gè)原因我的最終解決辦法是去掉救助空間，設(shè)置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可豺裆，第二個(gè)原因我的解決辦法是設(shè)置CMSInitiatingOccupancyFraction為某個(gè)值（假設(shè)70）拒秘，這樣年老代空間到70%時(shí)就開始執(zhí)行CMS，年老代有足夠的空間接納來自年輕代的對象臭猜。
解決方案一的改進(jìn)方案：
又有改進(jìn)了躺酒，上面方法不太好，因?yàn)闆]有用到救助空間蔑歌，所以年老代容易滿阴颖，CMS執(zhí)行會(huì)比較頻繁。我改善了一下丐膝，還是用救助空間，但是把救助空間加大钾菊，這樣也不會(huì)有promotion failed帅矗。具體操作上，32位Linux和64位Linux好像不一樣煞烫，64位系統(tǒng)似乎只要配置MaxTenuringThreshold參數(shù)浑此，CMS還是有暫停。為了解決暫停問題和promotion failed問題滞详，最后我設(shè)置-XX:SurvivorRatio=1 凛俱，并把MaxTenuringThreshold去掉紊馏，這樣即沒有暫停又不會(huì)有promotoin failed，而且更重要的是蒲犬，年老代和永久代上升非常慢（因?yàn)楹枚鄬ο蟮讲涣四昀洗捅换厥樟耍┲旒啵訡MS執(zhí)行頻率非常低，好幾個(gè)小時(shí)才執(zhí)行一次原叮，這樣赫编，服務(wù)器都不用重啟了。
-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值與Xmn的關(guān)系公式
上面介紹了promontion faild產(chǎn)生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活對象存入To survivor區(qū)時(shí),To survivor區(qū)的空間不足奋隶，再次晉升到old gen區(qū)擂送，而old gen區(qū)內(nèi)存也不夠的情況下產(chǎn)生了promontion faild從而導(dǎo)致full gc.那可以推斷出：eden+from survivor < old gen區(qū)剩余內(nèi)存時(shí)，不會(huì)出現(xiàn)promontion faild的情況唯欣，即：(Xmx-Xmn)(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 進(jìn)而推斷出：
CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)100
例如：
當(dāng)xmx=128 xmn=36 SurvivorRatior=1時(shí) CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)100 =73.913
當(dāng)xmx=128 xmn=24 SurvivorRatior=1時(shí) CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)100=84.615…
當(dāng)xmx=3000 xmn=600 SurvivorRatior=1時(shí) CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)100=83.33
CMSInitiatingOccupancyFraction低于70% 需要調(diào)整xmn或SurvivorRatior值嘹吨。
令：
網(wǎng)上一童鞋推斷出的公式是：:(Xmx-Xmn)(100-CMSInitiatingOccupancyFraction)/100>=Xmn 這個(gè)公式個(gè)人認(rèn)為不是很嚴(yán)謹(jǐn)，在內(nèi)存小的時(shí)候會(huì)影響xmn的計(jì)算境氢。

關(guān)于實(shí)際環(huán)境的GC參數(shù)配置見:實(shí)例分析 監(jiān)測工具見JVM監(jiān)測
參考：
JAVA HOTSPOT VM（http://www.helloying.com/blog/archives/164）
JVM 幾個(gè)重要的參數(shù) (校長)
java jvm 參數(shù) -Xms -Xmx -Xmn -Xss 調(diào)優(yōu)總結(jié)
Java HotSpot VM Options
http://bbs.weblogicfans.net/archiver/tid-2835.html
Frequently Asked Questions About the Java HotSpot VM
Java SE HotSpot at a Glance
Java性能調(diào)優(yōu)筆記(內(nèi)附測試?yán)?很有用)
說說MaxTenuringThreshold這個(gè)參數(shù)

相關(guān)文章推薦:
GC調(diào)優(yōu)方法總結(jié)
Java 6 JVM參數(shù)選項(xiàng)大全（中文版）

redcreen