不管是YGC還是Full GC
GC過程中都會對導致程序運行中中斷
正確的選擇不同的GC策略
調整JVM
GC的參數
可以極大的減少由於GC工作
而導致的程序運行中斷方面的問題
進而適當的提高Java程序的工作效率
但是調整GC是以個極為復雜的過程
由於各個程序具備不同的特點
如
web和GUI程序就有很大區別（Web可以適當的停頓
但GUI停頓是客戶無法接受的）
而且由於跑在各個機器上的配置不同（主要cup個數
內存不同）
所以使用的GC種類也會不同（如何選擇見GC種類及如何選擇）
本文將注重介紹JVM
GC的一些重要參數的設置來提高系統的性能
JVM內存組成及GC相關內容請見之前的文章
JVM內存組成 GC策略&內存申請
JVM參數的含義 實例見實例分析
參數名稱
含義
默認值
Xms
初始堆大小
物理內存的/(<GB)
默認(MinHeapFreeRatio參數可以調整)空余堆內存小於%時JVM就會增大堆直到Xmx的最大限制
Xmx
最大堆大小
物理內存的/(<GB)
默認(MaxHeapFreeRatio參數可以調整)空余堆內存大於%時JVM會減少堆直到 Xms的最小限制
Xmn
年輕代大小(or lator)
注意此處的大小是（eden+ survivor space)與jmap heap中顯示的New gen是不同的
整個堆大小=年輕代大小 + 年老代大小 + 持久代大小
增大年輕代後將會減小年老代大小此值對系統性能影響較大Sun官方推薦配置為整個堆的/
XX:NewSize
設置年輕代大小(for /)
XX:MaxNewSize
年輕代最大值(for /)
XX:PermSize
設置持久代(perm gen)初始值
物理內存的/
XX:MaxPermSize
設置持久代最大值
物理內存的/
Xss
每個線程的堆棧大小
JDK以後每個線程堆棧大小為M以前每個線程堆棧大小為K更具應用的線程所需內存大小進行 調整在相同物理內存下減小這個值能生成更多的線程但是操作系統對一個進程內的線程數還是有限制的不能無限生成經驗值在~左右
一般小的應用 如果棧不是很深 應該是k夠用的 大的應用建議使用k這個選項對性能影響比較大需要嚴格的測試（校長）
和threadstacksize選項解釋很類似官方文檔似乎沒有解釋在論壇中有這樣一句話:
Xss is translated in a VM flag named ThreadStackSize
一般設置這個值就可以了
XX:ThreadStackSize
Thread Stack Size
( means use default stack size) [Sparc: ; Solaris x: (was prior in and earlier); Sparc bit: ; Linux amd: (was in and earlier); all others ]
XX:NewRatio
年輕代(包括Eden和兩個Survivor區)與年老代的比值(除去持久代)
XX:NewRatio=表示年輕代與年老代所占比值為:年輕代占整個堆棧的/
Xms=Xmx並且設置了Xmn的情況下該參數不需要進行設置
XX:SurvivorRatio
Eden區與Survivor區的大小比值
設置為則兩個Survivor區與一個Eden區的比值為:一個Survivor區占整個年輕代的/
XX:LargePageSizeInBytes
內存頁的大小不可設置過大 會影響Perm的大小
=m
XX:+UseFastAccessorMethods
原始類型的快速優化
XX:+DisableExplicitGC
關閉Systemgc()
這個參數需要嚴格的測試
XX:MaxTenuringThreshold
垃圾最大年齡
如果設置為的話則年輕代對象不經過Survivor區直接進入年老代 對於年老代比較多的應用可以提高效率如果將此值設置為一個較大值則年輕代對象會在Survivor區進行多次復制這樣可以增加對象再年輕代的存活 時間增加在年輕代即被回收的概率
該參數只有在串行GC時才有效
XX:+AggressiveOpts
加快編譯
XX:+UseBiasedLocking
鎖機制的性能改善
Xnoclassgc
禁用垃圾回收
XX:SoftRefLRUPolicyMSPerMB
每兆堆空閒空間中SoftReference的存活時間
s
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
對象超過多大是直接在舊生代分配
單位字節 新生代采用Parallel Scavenge GC時無效
另一種直接在舊生代分配的情況是大的數組對象且數組中無外部引用對象
XX:TLABWasteTargetPercent
TLAB占eden區的百分比
%
XX:+CollectGenFirst
FullGC時是否先YGC
false
並行收集器相關參數
XX:+UseParallelGC
Full GC采用parallel MSC
(此項待驗證)
選擇垃圾收集器為並行收集器此配置僅對年輕代有效即上述配置下年輕代使用並發收集而年老代仍舊使用串行收集(此項待驗證)
XX:+UseParNewGC
設置年輕代為並行收集
可與CMS收集同時使用
JDK
以上
JVM會根據系統配置自行設置
所以無需再設置此值
XX:ParallelGCThreads
並行收集器的線程數
此值最好配置與處理器數目相等 同樣適用於CMS
XX:+UseParallelOldGC
年老代垃圾收集方式為並行收集(Parallel Compacting)
這個是JAVA
出現的參數選項
XX:MaxGCPauseMillis
每次年輕代垃圾回收的最長時間(最大暫停時間)
如果無法滿足此時間
JVM會自動調整年輕代大小
以滿足此值
XX:+UseAdaptiveSizePolicy
自動選擇年輕代區大小和相應的Survivor區比例
設置此選項後
並行收集器會自動選擇年輕代區大小和相應的Survivor區比例
以達到目標系統規定的最低相應時間或者收集頻率等
此值建議使用並行收集器時
一直打開
XX:GCTimeRatio
設置垃圾回收時間占程序運行時間的百分比
公式為
/(
+n)
XX:+
ScavengeBeforeFullGC
Full GC前調用YGC
true
Do young generation GC prior to a full GC
(Introduced in
)
CMS相關參數
XX:+UseConcMarkSweepGC
使用CMS內存收集
測試中配置這個以後XX:NewRatio=的配置失效了原因不明所以此時年輕代大小最好用Xmn設置???
XX:+AggressiveHeap
試圖是使用大量的物理內存
長時間大內存使用的優化能檢查計算資源（內存 處理器數量）
至少需要MB內存
大量的CPU／內存 （在在CPU的機器上已經顯示有提升）
XX:CMSFullGCsBeforeCompaction
多少次後進行內存壓縮
由於並發收集器不對內存空間進行壓縮整理所以運行一段時間以後會產生碎片使得運行效率降低此值設置運行多少次GC以後對內存空間進行壓縮整理
XX:+CMSParallelRemarkEnabled
降低標記停頓
XX+UseCMSCompactAtFullCollection
在FULL GC的時候 對年老代的壓縮
CMS是不會移動內存的 因此 這個非常容易產生碎片 導致內存不夠用 因此 內存的壓縮這個時候就會被啟用 增加這個參數是個好習慣
可能會影響性能但是可以消除碎片
XX:+UseCMSInitiatingOccupancyOnly
使用手動定義初始化定義開始CMS收集
禁止hostspot自行觸發CMS GC
XX:CMSInitiatingOccupancyFraction=
使用cms作為垃圾回收
使用％後開始CMS收集
為了保證不出現promotion failed(見下面介紹)錯誤該值的設置需要滿足以下公式CMSInitiatingOccupancyFraction計算公式
XX:CMSInitiatingPermOccupancyFraction
設置Perm Gen使用到達多少比率時觸發
XX:+CMSIncrementalMode
設置為增量模式
用於單CPU情況
XX:+CMSClassUnloadingEnabled
輔助信息
XX:+PrintGC
輸出形式:
[GC K>K(K) secs]
[Full GC K>K(K) secs]
XX:+PrintGCDetails
輸出形式:[GC [DefNew: K>K(K) secs] K>K(K) secs]
[GC [DefNew: K>K(K) secs][Tenured: K>K(K) secs] K>K(K) secs]
XX:+PrintGCTimeStamps
XX:+PrintGC:PrintGCTimeStamps
可與
XX:+PrintGC
XX:+PrintGCDetails混合使用
輸出形式:
: [GC
K
>
K(
K)
secs]
XX:+PrintGCApplicationStoppedTime
打印垃圾回收期間程序暫停的時間
可與上面混合使用
輸出形式:Total time for which application threads were stopped:
seconds
XX:+PrintGCApplicationConcurrentTime
打印每次垃圾回收前
程序未中斷的執行時間
可與上面混合使用
輸出形式:Application time:
seconds
XX:+PrintHeapAtGC
打印GC前後的詳細堆棧信息
Xloggc:filename
把相關日志信息記錄到文件以便分析
與上面幾個配合使用
XX:+PrintClassHistogram
garbage collects before printing the histogram
XX:+PrintTLAB
查看TLAB空間的使用情況
XX:+PrintTenuringDistribution
查看每次minor GC後新的存活周期的阈值
Desired survivor size bytes new threshold (max )
new threshold 即標識新的存活周期的阈值為
GC性能方面的考慮
對於GC的性能主要有個方面的指標吞吐量throughput（工作時間不算gc的時間占總的時間比）和暫停pause（gc發生時app對外顯示的無法響應）
Total Heap
默認情況下vm會增加/減少heap大小以維持free space在整個vm中占的比例這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定
一般而言server端的app會有以下規則
◆ 對vm分配盡可能多的memory
◆ 將Xms和Xmx設為一樣的值如果虛擬機啟動時設置使用的內存比較小這個時候又需要初始化很多對象虛擬機就必須重復地增加內存
◆ 處理器核數增加內存也跟著增大
The Young Generation
另外一個對於app流暢性運行影響的因素是young generation的大小young generation越大minor collection越少但是在固定heap size情況下更大的young generation就意味著小的tenured generation就意味著更多的major collection（major collection會引發minor collection）
NewRatio反映的是young和tenured generation的大小比例NewSize和MaxNewSize反映的是young generation大小的下限和上限將這兩個值設為一樣就固定了young generation的大小（同Xms和Xmx設為一樣）
如果希望SurvivorRatio也可以優化survivor的大小不過這對於性能的影響不是很大SurvivorRatio是eden和survior大小比例
一般而言server端的app會有以下規則
◆ 首先決定能分配給vm的最大的heap size然後設定最佳的young generation的大小
◆ 如果heap size固定後增加young generation的大小意味著減小tenured generation大小讓tenured generation在任何時候夠大能夠容納所有live的data（留%%的空余）
經驗&&規則
◆ 年輕代大小選擇 ?響應時間優先的應用盡可能設大直到接近系統的最低響應時間限制（根據實際情況選擇）在此種情況下年輕代收集發生的頻率也是最小的同時減少到達年老代的對象
◆ 吞吐量優先的應用盡可能的設置大可能到達Gbit的程度因為對響應時間沒有要求垃圾收集可以並行進行一般適合CPU以上的應用
◆ 避免設置過小當新生代設置過小時會導致YGC次數更加頻繁 可能導致YGC對象直接進入舊生代如果此時舊生代滿了會觸發FGC
◆ 年老代大小選擇 ?響應時間優先的應用年老代使用並發收集器所以其大小需要小心設置一般要考慮並發會話率和會話持續時間等一些參數如果堆設置小了可以會造成內存碎 片高回收頻率以及應用暫停而使用傳統的標記清除方式如果堆大了則需要較長的收集時間最優化的方案一般需要參考以下數據獲得
並發垃圾收集信息持久代並發收集次數傳統GC信息花在年輕代和年老代回收上的時間比例
◆ 吞吐量優先的應用一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代原因是這樣可以盡可能回收掉大部分短期對象減少中期的對象而年老代盡存放長期存活對象
◆ 較小堆引起的碎片問題
因為年老代的並發收集器使用標記清除算法所以不會對堆進行壓縮當收集器回收時他會把相鄰的空間進行合並這樣可以分配給較大的對象但是當堆空間較小時運行一段時間以後就會出現碎片如果並發收集器找不到足夠的空間那麼並發收集器將會停止然後使用傳統的標記清除方式進行回收如果出現碎片可能需要進行如下配置
XX:+UseCMSCompactAtFullCollection:使用並發收集器時開啟對年老代的壓縮
XX:CMSFullGCsBeforeCompaction=:上面配置開啟的情況下這裡設置多少次Full GC後對年老代進行壓縮
◆ 用位操作系統Linux下位的jdk比位jdk要慢一些但是吃得內存更多吞吐量更大
◆ XMX和XMS設置一樣大MaxPermSize和MinPermSize設置一樣大這樣可以減輕伸縮堆大小帶來的壓力
◆ 使用CMS的好處是用盡量少的新生代經驗值是M－M 然後老生代利用CMS並行收集 這樣能保證系統低延遲的吞吐效率 實際上cms的收集停頓時間非常的短G的內存 大約－ms的應用程序停頓時間
◆ 系統停頓的時候可能是GC的問題也可能是程序的問題多用jmap和jstack查看或者killall java然後查看java控制台日志能看出很多問題（相關工具的使用方法將在後面的blog中介紹）
◆ 仔細了解自己的應用如果用了緩存那麼年老代應該大一些緩存的HashMap不應該無限制長建議采用LRU算法的Map做緩存LRUMap的最大長度也要根據實際情況設定
◆ 采用並發回收時年輕代小一點年老代要大因為年老大用的是並發回收即使時間長點也不會影響其他程序繼續運行網站不會停頓
◆ JVM參數的設置（特別是 –Xmx –Xms –Xmn XX:SurvivorRatio XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式需要根據PV old區實際數據 YGC次數等多方面來衡量為了避免promotion faild可能會導致xmn設置偏小也意味著YGC的次數會增多處理並發訪問的能力下降等問題每個參數的調整都需要經過詳細的性能測試才能找到特定應用的最佳配置
promotion failed
垃圾回收時promotion failed是個很頭痛的問題一般可能是兩種原因產生第一個原因是救助空間不夠救助空間裡的對象還不應該被移動到年老代但年輕代又有很多對象需要放入救助空間第二個原因是年老代沒有足夠的空間接納來自年輕代的對象這兩種情況都會轉向Full GC網站停頓時間較長
解決方方案一
第一個原因我的最終解決辦法是去掉救助空間設置XX:SurvivorRatio= XX:MaxTenuringThreshold=即可第二個原因我的解決辦法是設置CMSInitiatingOccupancyFraction為某個值（假設）這樣年老代空間到%時就開始執行CMS年老代有足夠的空間接納來自年輕代的對象
解決方案一的改進方案
又有改進了上面方法不太好因為沒有用到救助空間所以年老代容易滿CMS執行會比較頻繁我改善了一下還是用救助空間但是把救助空間加大這樣也不會有promotion failed具體操作上位Linux和位Linux好像不一樣位系統似乎只要配置MaxTenuringThreshold參數CMS還是有暫停為了解決暫停問題和promotion failed問題最後我設置XX:SurvivorRatio= 並把MaxTenuringThreshold去掉這樣即沒有暫停又不會有promotoin failed而且更重要的是年老代和永久代上升非常慢（因為好多對象到不了年老代就被回收了）所以CMS執行頻率非常低好幾個小時才執行一次這樣服務器都不用重啟了
XmxM XmsM XmnM XX:PermSize=M XX:MaxPermSize=M XssK XX:+DisableExplicitGC XX:SurvivorRatio= XX:+UseConcMarkSweepGC XX:+UseParNewGC XX:+CMSParallelRemarkEnabled XX:+UseCMSCompactAtFullCollection XX:CMSFullGCsBeforeCompaction= XX:+CMSClassUnloadingEnabled XX:LargePageSizeInBytes=M XX:+UseFastAccessorMethods XX:+UseCMSInitiatingOccupancyOnly XX:CMSInitiatingOccupancyFraction= XX:SoftRefLRUPolicyMSPerMB= XX:+PrintClassHistogram XX:+PrintGCDetails XX:+PrintGCTimeStamps XX:+PrintHeapAtGC Xloggc:log/gclog
CMSInitiatingOccupancyFraction值與Xmn的關系公式
上面介紹了promontion faild產生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活對象存入To survivor區時To survivor區的空間不足再次晉升到old gen區而old gen區內存也不夠的情況下產生了promontion faild從而導致full gc那可以推斷出eden+from survivor < old gen區剩余內存時不會出現promontion faild的情況即
（XmxXmn）*（CMSInitiatingOccupancyFraction/）>=（XmnXmn/（SurvivorRatior+）） 進而推斷出
CMSInitiatingOccupancyFraction <=（（XmxXmn）（XmnXmn/（SurvivorRatior+）））/（XmxXmn）*
例如
當xmx= xmn= SurvivorRatior=時 CMSInitiatingOccupancyFraction<=（（）（/（+）））/（）* =
當xmx= xmn= SurvivorRatior=時 CMSInitiatingOccupancyFraction<=（（）（/（+）））/（）*=…
當xmx= xmn= SurvivorRatior=時 CMSInitiatingOccupancyFraction<=（（）（/（+）））/（）*=
CMSInitiatingOccupancyFraction低於% 需要調整xmn或SurvivorRatior值
令
網上一童鞋推斷出的公式是（XmxXmn）*（CMSInitiatingOccupancyFraction）/>=Xmn 這個公式個人認為不是很嚴謹在內存小的時候會影響xmn的計算
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26794.html
