• JVM參數(shù)的含義

• 并行收集器相關(guān)參數(shù)

• CMS相關(guān)參數(shù)

• 輔助信息

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

1. Total Heap
默認(rèn)情況下咙鞍，vm會(huì)增加/減少heap大小以維持free space在整個(gè)vm中占的比例，這個(gè)比例 MinHeapFreeRatio和MaxHeapFreeRatio指定趾徽。

一般而言续滋，server端的app會(huì)有以下規(guī)則：

• 對(duì)vm分配盡可能多的memory；
• 將Xms和Xmx設(shè)為一樣的值孵奶。如果虛擬機(jī)啟動(dòng)時(shí)設(shè)置使用的內(nèi)存比較小疲酌，這個(gè)時(shí)候又需要初始化很多對(duì)象，虛擬機(jī)就必須重復(fù)地增加內(nèi)存拒课。
• 處理器核數(shù)增加徐勃，內(nèi)存也跟著增大事示。

2. The Young Generation

另外一個(gè)對(duì)于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的大小余境，不過這對(duì)于性能的影響不是很大。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ī)則

1. 年輕代大小選擇

   • 響應(yīng)時(shí)間優(yōu)先的應(yīng)用：盡可能設(shè)大盯仪，直到接近系統(tǒng)的最低響應(yīng)時(shí)間限制(根據(jù)實(shí)際情況選擇)紊搪。在此種情況下，年輕代收集發(fā)生的頻率也是最小的全景。同時(shí)嗦明，減少到達(dá)年老代的對(duì)象。
   • 吞吐量優(yōu)先的應(yīng)用：盡可能的設(shè)置大蚪燕，可能到達(dá)Gbit的程度娶牌。因?yàn)閷?duì)響應(yīng)時(shí)間沒有要求，垃圾收集可以并行進(jìn)行馆纳，一般適合8 CPU以上的應(yīng)用诗良。
   • 避免設(shè)置過小。當(dāng)新生代設(shè)置過小時(shí)會(huì)導(dǎo)致:

     • YGC次數(shù)更加頻繁
     • 可能導(dǎo)致YGC對(duì)象直接進(jìn)入老年代鲁驶，如果此時(shí)老年代滿了鉴裹，會(huì)觸發(fā)FGC。

2. 年老代大小選擇

   • 1、響應(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í)間比例旭从。

   • 2稳强、吞吐量優(yōu)先的應(yīng)用：一般吞吐量優(yōu)先的應(yīng)用都有一個(gè)很大的年輕代和一個(gè)較小的年老代。原因是和悦，這樣可以盡可能回收掉大部分短期對(duì)象键袱，減少中期的對(duì)象，而年老代盡存放長期存活對(duì)象摹闽。

   • 3、較小堆引起的碎片問題：因?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í)挫掏，開啟對(duì)年老代的壓縮侦另。
     -XX:CMSFullGCsBeforeCompaction=0：上面配置開啟的情況下，這里設(shè)置多少次Full GC后，對(duì)年老代進(jìn)行壓縮

   • 4褒傅、用64位操作系統(tǒng)弃锐，Linux下64位的jdk比32位jdk要慢一些，但是吃得內(nèi)存更多殿托，吞吐量更大

   • 5霹菊、XMX和XMS設(shè)置一樣大，MaxPermSize和MinPermSize設(shè)置一樣大碌尔，這樣可以減輕伸縮堆大小帶來的壓力

   • 6浇辜、使用CMS的好處是用盡量少的新生代，經(jīng)驗(yàn)值是128M－256M唾戚， 然后老生代利用CMS并行收集柳洋， 這樣能保證系統(tǒng)低延遲的吞吐效率。 實(shí)際上cms的收集停頓時(shí)間非常的短叹坦，2G的內(nèi)存熊镣， 大約20－80ms的應(yīng)用程序停頓時(shí)間

   • 7、系統(tǒng)停頓的時(shí)候可能是GC的問題也可能是程序的問題募书，多用jmap和jstack查看绪囱，或者killall -3 java，然后查看java控制臺(tái)日志莹捡，能看出很多問題鬼吵。(相關(guān)工具的使用方法將在后面的blog中介紹)

   • 8、仔細(xì)了解自己的應(yīng)用篮赢，如果用了緩存齿椅，那么年老代應(yīng)該大一些，緩存的HashMap不應(yīng)該無限制長启泣，建議采用LRU算法的Map做緩存涣脚，LRUMap的最大長度也要根據(jù)實(shí)際情況設(shè)定。

   • 9寥茫、采用并發(fā)回收時(shí)遣蚀，年輕代小一點(diǎn)，年老代要大纱耻，因?yàn)槟昀洗笥玫氖遣l(fā)回收芭梯，即使時(shí)間長點(diǎn)也不會(huì)影響其他程序繼續(xù)運(yùn)行，網(wǎng)站不會(huì)停頓

   • 10弄喘、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è)原因是救助空間不夠，救助空間里的對(duì)象還不應(yīng)該被移動(dòng)到年老代旱幼，但年輕代又有很多對(duì)象需要放入救助空間查描；
• 第二個(gè)原因是年老代沒有足夠的空間接納來自年輕代的對(duì)象；這兩種情況都會(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，年老代有足夠的空間接納來自年輕代的對(duì)象桥滨。

解決方案一的改進(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)楹枚鄬?duì)象到不了年老代就被回收了），所以CMS執(zhí)行頻率非常低眯分，好幾個(gè)小時(shí)才執(zhí)行一次拌汇，這樣，服務(wù)器都不用重啟了弊决。

-Xmx 4000M
-Xms 4000M
-Xmn 600M   年輕代大小
-XX:PermSize=500M  永久代初始值大小
-XX:MaxPermSize=500M  永久代最大值
-Xss 256K  線程大小
-XX:+DisableExplicitGC  關(guān)閉system.gc
-XX:SurvivorRatio=1 年輕代比值
-XX:+UseConcMarkSweepGC 使用CMS內(nèi)存收集
-XX:+UseParNewGC  設(shè)置年輕代使用并行收集
-XX:+CMSParallelRemarkEnabled 
-XX:+UseCMSCompactAtFullCollection 老年代壓縮
-XX:CMSFullGCsBeforeCompaction=0 每次進(jìn)行壓縮
-XX:+CMSClassUnloadingEnabled 
-XX:LargePageSizeInBytes=128M 
-XX:+UseFastAccessorMethods 原始類型快速優(yōu)化
-XX:+UseCMSInitiatingOccupancyOnly 手動(dòng)觸發(fā)
-XX:CMSInitiatingOccupancyFraction=80 80%開始回收
-XX:SoftRefLRUPolicyMSPerMB=0 軟應(yīng)用存活時(shí)間
-XX:+PrintClassHistogram 
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC 
-Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值與Xmn的關(guān)系公式

上面介紹了promontion faild產(chǎn)生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活對(duì)象存入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ì)算。

實(shí)例：

• java application項(xiàng)目（非web）
  改進(jìn)前：

-Xms128m
-Xmx128m
-XX:NewSize=64m
-XX:PermSize=64m
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=78
-XX:ThreadStackSize=128
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true

問題：

permsize 設(shè)置較小净响，很容易達(dá)到報(bào)警范圍(0.8)
沒有設(shè)置MaxPermSize少欺，堆增長會(huì)帶來額外壓力片排。
NewSize較大登下，old gen 剩余空間64m笋婿，一方面可能會(huì)帶來old區(qū)容易增長到報(bào)警范圍（監(jiān)控?cái)?shù)據(jù)顯示oldgenused長期在50m左右滋尉，接近78%家卖，容易出現(xiàn) full gc）潮剪，另一方面也存在 promontion fail 風(fēng)險(xiǎn)

改進(jìn)后：

-Xms128m
-Xmx128m
-Xmn24m
-XX:PermSize=80m
-XX:MaxPermSize=80m
-Xss256k
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=20
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSParallelRemarkEnabled
-XX:CMSFullGCsBeforeCompaction=2
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true

修改點(diǎn)：

PermSize與MaxPermSize都設(shè)置為80裁良，一方面避免non heap warn(報(bào)警閥值0.8 非對(duì)內(nèi)存一般占用到60M以內(nèi)）衷恭，一方面避免堆伸縮帶來的壓力
通過設(shè)置Xmn=24M及SurvivorRatio=1 使得Eden區(qū)=from space=to space=8M,降低了Eden區(qū)大小扰付，降低YGC的時(shí)間(降低到3-4ms左右)堤撵，同時(shí)通過設(shè)MaxTenuringThreshold=20，使得old gen的增長很緩慢羽莺。帶來的問題是YGC的次數(shù)明顯提高了很多实昨。

再次改進(jìn)后

-Xms128m
-Xmx128m
-Xmn36m
-XX:PermSize=80m
-XX:MaxPermSize=80m
-Xss256k
-XX:SurvivorRatio=1
-XX:MaxTenuringThreshold=20
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=73
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSParallelRemarkEnabled
-XX:CMSFullGCsBeforeCompaction=2
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:logs/gc.log
-Dsun.rmi.dgc.server.gcInterval=3600000
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.server.exceptionTrace=true

修改點(diǎn)：

在上面的基礎(chǔ)上調(diào)整Xmn大小到36M，設(shè)置CMSInitiatingOccupancyFraction=73盐固。
Dden區(qū)與Survivor區(qū)大小都增加到12M荒给，通過下文的CMSInitiatingOccupancyFraction計(jì)算得出value為73是可以避免promotion faild問題，同時(shí)滿足堆內(nèi)存監(jiān)控報(bào)警值在80%：內(nèi)存大小128M80%=102.4M 102.4M-36M=66.4M(老年代達(dá)到此值報(bào)警） 老年代達(dá)到67.15M（92M0.73）將發(fā)生Full GC刁卜，所以在老生代大小達(dá)到66.4M時(shí)也就是WARN報(bào)警時(shí)將很有可能出現(xiàn)Full GC志电。

增大了Eden和Survivor區(qū)的值，會(huì)減小YGC的次數(shù)蛔趴，但由于空間變大理論上也會(huì)相應(yīng)的增加YGC的時(shí)間挑辆，不過由于新生代本身就很小（才36M）這點(diǎn)兒變化可以忽略掉孝情。實(shí)際的監(jiān)控值顯示YGC的時(shí)間在4-5ms之間鱼蝉。是可以接受范圍。

SurvivorRatio 這個(gè)值還得在仔細(xì)考慮下,有待優(yōu)化中

網(wǎng)上某個(gè)牛人的配置 :每天幾百萬pv一點(diǎn)問題都沒有箫荡，網(wǎng)站沒有停頓

-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

說明一下魁亦，
-XX:SurvivorRatio=65536
-XX:MaxTenuringThreshold=0
就是去掉了救助空間；

-Xnoclassgc禁用類垃圾回收羔挡，性能會(huì)高一點(diǎn)洁奈；

-XX:+DisableExplicitGC禁止System.gc()间唉，免得程序員誤調(diào)用gc方法影響性能；

-XX:+UseParNewGC睬魂，對(duì)年輕代采用多線程并行回收终吼，這樣收得快；

帶CMS參數(shù)的都是和并發(fā)回收相關(guān)的际跪，不明白的可以上網(wǎng)搜索姆打；

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闲延，我覺得沒必要等1秒垒玲；

-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

改進(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)楹枚鄬?duì)象到不了年老代就被回收了）抡笼，所以CMS執(zhí)行頻率非常低推姻，好幾個(gè)小時(shí)才執(zhí)行一次藏古，這樣拧晕，服務(wù)器都不用重啟了输玷。

某網(wǎng)友:

-server
-Xmx3000M
-Xms3000M
-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=70
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log

64位jdk參考設(shè)置饲嗽，年老代漲得很慢，CMS執(zhí)行頻率變小裙犹，CMS沒有停滯袄膏，也不會(huì)有promotion failed問題沉馆，內(nèi)存回收得很干凈

參考：

JVM參數(shù)調(diào)優(yōu)，無停滯實(shí)踐

JVM系列三:JVM參數(shù)設(shè)置锌奴、分析

JVM系列四:生產(chǎn)環(huán)境參數(shù)實(shí)例及分析【生產(chǎn)環(huán)境實(shí)例增加中】

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ù)