JVM內存配置詳解

前段時間在一個項目的性能測試中又發生了一次OOM（Out of swap sapce），情形和之前網店版的那次差很少，比上次更奇怪的是，這次搞了幾天以後啥都沒調整系統就自動好了，死活無法再重現以前的OOM了！問題雖然蹊 蹺，但也趁此機會再次對JVM堆模型、GC垃圾算法等進行了一次系統梳理；

基本概念

一：堆/Heap 

JVM管理的內存叫堆；在32Bit操做系統上有4G的限制，通常來講Windows下爲2G，而Linux 下爲3G；64Bit的就沒有這個限制。
JVM初始分配的內存由-Xms指定，默認是物理內存的1/64但小於1G。
JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4但小於1G。
默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制，能夠由 -XX:MinHeapFreeRatio=指定。
默認空餘堆內存大於70%時，JVM會減小堆直到-Xms的最小限制，能夠由 -XX:MaxHeapFreeRatio=指定。
服務器通常設置-Xms、-Xmx相等以免在每次GC後調整堆的大小，因此上面的兩個參數沒啥用。

二：分代/堆模型
分代是Java垃圾收集的一大亮點，根據對象的生命週期長短，把堆分爲3個代：Young，Old和Permanent，根據不一樣代的特色採用不一樣的收集算法，能夠揚長避短。可參考以下的模型圖：

Young(Nursery)：年輕代
研究代表大部分對象都是朝生暮死，隨生隨滅的。因此對於年輕代在GC時都採起復制收集算法，具體算法參考下面的描述；
Young的默認值爲4M，隨堆內存增大，約爲1/15，JVM會根據狀況動態管理其大小變化。
Young裏面又分爲3 個區域，一個Eden，全部新建對象都會存在於該區，兩個Survivor區，用來實施複製算法。
-XX:NewRatio= 參數能夠設置Young與Old的大小比例，-server時默認爲1:2，但實際上young啓動時遠低於這個比率？若是信不過JVM，也能夠用 -Xmn硬性規定其大小，有文檔推薦設爲Heap總大小的1/4。
-XX:SurvivorRatio= 參數能夠設置Eden與Survivor的比例，默認爲32。Survivio大了會浪費，小了的話，會使一些年輕對象潛逃到老人區，引發老人區的不安，但這個參數對性能並不過重要。

Old(Tenured)：年老代
年輕代的對象若是可以挺過數次收集，就會進入老人區。老人區使用標記整理算法。由於老人區的對象都沒那麼容易死的，採用複製算法就要反覆的複製對象，很不合算，只好採用標記清理算法，但標記清理算法其實也不輕鬆，每次都要遍歷區域內全部對象，因此仍是沒有免費的午飯啊。
-XX:MaxTenuringThreshold= 設置熬過年輕代多少次收集後移入老人區，CMS中默認爲0，熬過第一次GC就轉入，能夠用-XX:+PrintTenuringDistribution 查看。

Permanent：持久代
裝載Class信息等基礎數據，默認64M，若是是類不少不少的服務程序，須要加大其設置 -XX:MaxPermSize=，不然它滿了以後會引發fullgc()或Out of Memory。 注意Spring，Hibernate這類喜歡AOP動態生成類的框架須要更多的持久代內存。通常狀況下，持久代是不會進行GC的，除非經過 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled進行強制設置。

GC的類型
當每一個代滿了以後都會自動促發collection，各收集器觸發的條件不同，固然也能夠經過一些參數進行強制設定。主要分爲兩種類型：

Minor Collection：GC用較高的頻率對young進行掃描和回收，採用複製算法。
Major Collection：同時對Young和Old進行內存收集，也叫Full GC；由於成本關係對Old的檢查回收頻率要比Young低不少，採用標記清除/標記整理算法。能夠經過調用代碼System.gc()引起major collection，使用-XX:+DisableExplicitGC禁止它，或設爲CMS併發 -XX:+ExplicitGCInvokesConcurrent。
更爲具體的闡述以下：
因爲年輕代進進出出的人多而頻繁，因此年輕代的GC也就頻繁一點，但涉及範圍也就年輕代這點彈丸之地內的對象，其特色就是少許，屢次，但快速，稱之爲 Minor Collection。當年輕代的內存使用達到必定的閥值時，Minor Collection就被觸發，Eden及某一Survior space（from space）以內存活的的對象被移到另外一個空的Survior space（to space）中，而後from space和to space角色對調。當一個對象在兩個survivor space之間移動過必定次數（達到預設的閥值）時，它就足夠old了，夠資格呆在年老代了。固然，若是survivor space比較小不足以容下全部live objects時，部分live objects也會直接晉升到年老代。
Survior spaces能夠看做是Eden和年老代之間的緩衝，經過該緩衝能夠檢驗一個對象生命週期是否足夠的長，由於某些對象雖然逃過了一次Minor Collection，並不能說明其生命週期足夠長，說不定在下一次Minor Collection以前就掛了。這樣必定程度上確保了進入年老代的對象是貨真價實的，減小了年老代空間使用的增加速度，也就下降年老代GC的頻率。
當年老代或者永久代的內存使用達到必定閥值時，一次基於全部代的GC就觸發了，其特定是涉及範圍廣（量大），耗費的時間相對較長（較慢），可是頻率比較低 （次數少），稱之爲Major Collection(Full Collection)。一般，首先使用針對年輕代的GC算法進行年輕代的GC，而後使用針對年老代的GC算法對年老代和永久代進行GC。

基本GC收集算法
複製(copying)：將堆內分紅兩個相同空間，從根(ThreadLocal的對象，靜態對象）開始訪問每個關聯的活躍對象，將空間A的活躍對象所有複製到空間B，而後一次性回收整個空間A。
由於只訪問活躍對象，將全部活動對象複製走以後就清空整個空間，不用去訪問死對象，因此遍歷空間的成本較小，但須要巨大的複製成本和較多的內存。可參考以下的示例圖：

標記清除(mark-sweep)：收集器先從根開始訪問全部活躍對象，標記爲活躍對象。而後再遍歷一次整個內存區域，把全部沒有標記活躍的對象進行回收處理。該算法遍歷整個空間的成本較大暫停時間隨空間大小線性增大，並且整理後堆裏的碎片不少。可參考以下的示例圖：

標記整理(mark-sweep-compact)：綜合了上述二者的作法和優勢，先標記活躍對象，而後將其合併成較大的內存塊。可參考以下的示例圖：

GC收集器類型
古老的串行收集器(Serial Collector)
-XX:+UseSerialGC：策略爲年輕代串行復制，年老代串行標記整理。可參考以下的示例圖：
吞吐量優先的並行收集器(Throughput Collector)
-XX:+UseParallelGC：這是JDK5 -server的默認值。策略爲：
年輕代：暫停應用程序，多個垃圾收集線程並行的複製收集，線程數默認爲CPU個數，CPU不少時，可用 -XXarallelGCThreads= 設定線程數。
年老代：暫停應用程序，與串行收集器同樣，單垃圾收集線程標記整理。
如上可知該收集器須要2+的CPU時纔會優於串行收集器，適用於後臺處理，科學計算。
可使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 來調整GC的時間。可參考以下的示例圖：
暫停時間優先的併發收集器(Concurrent Low Pause Collector-CMS)
-XX:+UseConcMarkSweepGC：這是以上兩種策略的升級版，策略爲：
年輕代：一樣是暫停應用程序，多個垃圾收集線程並行的複製收集。
年老代：則只有兩次短暫停，其餘時間應用程序與收集線程併發的清除。
若要採用標記整理算法，則能夠經過設置參數實現；可參考以下的示例圖：
增量併發收集器(Incremental Concurrent-Mark-Sweep/i-CMS)：雖然CMS收集算法在最爲耗時的內存區域遍歷時採用多線程併發操做，但對於服務器CPU資源 不夠的狀況下，其實對性能是沒有提高的，反而會致使系統吞吐量的降低，爲了儘可能避免這種狀況的出現，就有了增量CMS收集算法，就是在併發標記、清理的時 候讓GC線程、用戶線程交叉運行，儘可能減小GC線程的全程獨佔式執行；可參考以下的示例圖：
對於以上的GC收集器的詳細設置參數，能夠參考 JVM選項的超完整收集《A Collection of JVM Options》，這裏就不一一詳述了。

並行、併發的區別
並行(Parallel)與併發(Concurrent)僅一字之差，但體現的意思卻徹底不一樣，這可能也是不少同窗很是困惑的地方，要想深入體會這其中的差異，能夠多揣摩下上面關於GC收集器的示例圖；

並行：指多條垃圾收集線程並行，此時用戶線程是沒有運行的；
併發：指用戶線程與垃圾收集線程併發執行，程序在繼續運行，而垃圾收集程序運行於另外一個個CPU上。
併發收集一開始會很短暫的中止一次全部線程來開始初始標記根對象，而後標記線程與應用線程一塊兒併發運行，最後又很短的暫停一次，多線程並行的從新標記以前 可能由於併發而漏掉的對象，而後就開始與應用程序併發的清除過程。可見，最長的兩個遍歷過程都是與應用程序併發執行的，比之前的串行算法改進太多太多 了！！！
串行標記清除是等年老代滿了再開始收集的，而併發收集由於要與應用程序一塊兒運行，若是滿了才收集，應用程序就無內存可用，因此係統默認68%滿的時候就開 始收集。內存已設得較大，吃內存又沒有這麼快的時候，能夠用 -XX:CMSInitiatingOccupancyFraction=恰當增大該比率。

年輕代的痛
因爲對年輕代的複製收集，依然必須中止全部應用程序線程，原理如此，只能靠多CPU，多收集線程併發來提升收集速度，但除非你的 Server獨佔整臺服務器，不然若是服務器上自己還有不少其餘線程時，切換起來速度就..... 因此，搞到最後，暫停時間的瓶頸就落在了年輕代的複製算法上。
所以Young的大小設置挺重要的，大點就不用頻繁GC，並且增大GC的間隔後，可讓多點對象本身死掉而不用複製了。但Young增大時，GC 形成的停頓時間攀升得很是恐怖，據某人的測試結果顯示：默認8M的Young，只須要幾毫秒的時間，64M就升到90毫秒，而升到256M時，就要到 300毫秒了，峯值還會攀到恐怖的800ms。誰叫複製算法，要等Young滿了纔開始收集，開始收集就要中止全部線程呢。

參考資料
主要參考：JDK5.0垃圾收集優化之--Don't Pause
官方指南：Tuning Garbage Collection with the 5.0 Java Virtual Machine

Sun HotSpot 1.4.1 JVM堆大小的調整

Sun HotSpot 1.4.1使用分代收集器，它把堆分爲三個主要的域：新域、舊域以及永久域。Jvm生成的全部新對象放在新域中。一旦對象經歷了必定數量的垃圾收集循環 後，便得到使用期並進入舊域。在永久域中jvm則存儲class和method對象。就配置而言，永久域是一個獨立域而且不認爲是堆的一部分。

下面介紹如何控制這些域的大小。可以使用-Xms和-Xmx 控制整個堆的原始大小或最大值。

下面的命令是把初始大小設置爲128M：

java –Xms128m

–Xmx256m爲控制新域的大小，可以使用 -XX:NewRatio設置新域在堆中所佔的比例。

下面的命令把整個堆設置成128m，新域比率設置成3，即新域與舊域比例爲 1：3，新域爲堆的1/4或32M：

java –Xms128m –Xmx128m

–XX:NewRatio =3可以使用-XX:NewSize和-XX:MaxNewsize設置新域的初始值和最大值。

下面的命令把新域的初始值和最大值設置成64m:

java –Xms256m –Xmx256m –Xmn64m

永久域默認大小爲4m。運行程序時，jvm會調整永久域的大小以知足須要。每次調整時，jvm會對堆進行一次徹底的垃圾收集。

使用-XX:MaXPerSize標誌來增長永久域搭大小。在WebLogic Server應用程序加載較多類時，常常須要增長永久域的最大值。當jvm加載類時，永久域中的對象急劇增長，從而使jvm不斷調整永久域大小。爲了不調整，可以使用-XXerSize標誌設置初始值。

下面把永久域初始值設置成32m，最大值設置成64m。

java -Xms512m -Xmx512m -Xmn128m -XXermSize=32m -XX:MaxPermSize=64m

默認狀態下，HotSpot在新域中使用複製收集器。該域通常分爲三個部分。第一部分爲Eden，用於生成新的對象。另兩部分稱爲救助空間，當 Eden佈滿時，收集器中止應用程序，把全部可到達對象複製到當前的from救助空間，一旦當前的from救助空間佈滿，收集器則把可到達對象複製到當前 的to救助空間。From和to救助空間互換角色。維持活動的對象將在救助空間不斷複製，直到它們得到使用期並轉入舊域。使用 -XX:SurvivorRatio可控制新域子空間的大小。

同NewRation同樣，SurvivorRation規定某救助域與Eden空間的比值。好比，如下命令把新域設置成64m，Eden佔32m，每一個救助域各佔16m：

java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRation =2

如前所述，默認狀態下 HotSpot對新域使用複製收集器，對舊域使用標記－清除－壓縮收集器。在新域中使用複製收集器有不少意義，由於應用程序生成的大部分對象是短壽命的。 理想狀態下，全部過渡對象在移出Eden空間時將被收集。假如可以這樣的話，而且移出Eden空間的對象是長壽命的，那麼理論上能夠當即把它們移進舊域， 避免在救助空間反覆複製。可是，應用程序不能適合這種理想狀態，由於它們有一小部分中長壽命的對象。最好是保持這些中長壽命的對象並放在新域中，由於複製 小部分的對象總比壓縮舊域廉價。爲控制新域中對象的複製，可用-XX:TargetSurvivorRatio控制救助空間的比例（該值是設置救助空間的 使用比例。如救助空間位1M，該值50表示可用500K）。該值是一個百分比，默認值是50。當較大的堆棧使用較低的sruvivorratio時，應增 加該值到80至90，以更好利用救助空間。用-XX:maxtenuring threshold可控制上限。

爲放置全部的複製所有發生以及但願對象從eden擴展到舊域，能夠把MaxTenuring Threshold設置成0。設置完成後，實際上就再也不使用救助空間了，所以應把SurvivorRatio設成最大值以最大化Eden空間，設置以下：

java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝50000 …



-Xmx4000M -Xms4000M -Xmn600M -XXermSize=64M -XX:MaxPermSize=128M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XXargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log



jdk1.4.2 JVM官方地址：http://java.sun.com/j2se/1.4.2/docs/guide/vm/index.html
標準和非標註參數(for windows)：http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html
非 stable參數：http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

中文地址：
http://blog.csdn.net/sfdev/archive/2008/01/23/2062042.aspx                           



前面咱們提到用-XX做爲前綴的參數列表在jvm中多是不健壯的，SUN也不推薦使用，後續可能會在沒有通知的狀況下就直接取消了；可是因爲這些參數中的確有不少是對咱們頗有用的，好比咱們常常會見到的-XXermSize、-XX:MaxPermSize等等；
下面咱們將就 Java HotSpot VM中-XX:的可配置參數列表進行描述；


這些參數能夠被鬆散的聚合成三類：
行爲參數（Behavioral Options）：用於改變jvm的一些基礎行爲；
性能調優（Performance Tuning）：用於jvm的性能調優；
調試參數（Debugging Options）：通常用於打開跟蹤、打印、輸出等jvm參數，用於顯示jvm更加詳細的信息；

因爲sun官方文檔中對各參數的描述也都很是少（大多隻有一句話），並且大多涉及OS層面的東西，很難描述清楚，因此如下是挑選了一些咱們開發中可能會用 得比較多的配置項，若須要查看全部參數列表，能夠點擊HotSpot VM Specific Options.查看原文；

首先來介紹行爲參數：




參數及其默認值 描述
-XX:-DisableExplicitGC 禁止調用System.gc()；但jvm的gc仍然有效
-XX:+MaxFDLimit 最大化文件描述符的數量限制
-XX:+ScavengeBeforeFullGC 新生代GC優先於Full GC執行
-XX:+UseGCOverheadLimit 在拋出OOM以前限制jvm耗費在GC上的時間比例
-XX:-UseConcMarkSweepGC 對老生代採用併發標記交換算法進行GC
-XX:-UseParallelGC 啓用並行GC
-XX:-UseParallelOldGC 對Full GC啓用並行，當-XX:-UseParallelGC啓用時該項自動啓用
-XX:-UseSerialGC 啓用串行GC
-XX:+UseThreadPriorities 啓用本地線程優先級


上面表格中黑體的三個參數表明着jvm中GC執行的三種方式，即串行、並行、併發；
串行（SerialGC）是jvm的默認GC方式，通常適用於小型應用和單處理器，算法比較簡單，GC效率也較高，但可能會給應用帶來停頓；
並行（ParallelGC）是指GC運行時，對應用程序運行沒有影響，GC和app二者的線程在併發執行，這樣能夠最大限度不影響app的運行；
併發（ConcMarkSweepGC）是指多個線程併發執行GC，通常適用於多處理器系統中，能夠提升GC的效率，但算法複雜，系統消耗較大；




性能調優參數列表：
參數及其默認值 描述
-XXargePageSizeInBytes=4m 設置用於Java堆的大頁面尺寸
-XX:MaxHeapFreeRatio=70 GC後java堆中空閒量佔的最大比例
-XX:MaxNewSize=size 新生成對象能佔用內存的最大值
-XX:MaxPermSize=64m 老生代對象能佔用內存的最大值
-XX:MinHeapFreeRatio=40 GC後java堆中空閒量佔的最小比例
-XX:NewRatio=2 新生代內存容量與老生代內存容量的比例
-XX:NewSize=2.125m 新生代對象生成時佔用內存的默認值
-XX:ReservedCodeCacheSize=32m 保留代碼佔用的內存容量
-XX:ThreadStackSize=512 設置線程棧大小，若爲0則使用系統默認值
-XX:+UseLargePages 使用大頁面內存

咱們在平常性能調優中基本上都會用到以上黑體的這幾個屬性；



調試參數列表：
參數及其默認值 描述
-XX:-CITime 打印消耗在JIT編譯的時間
-XX:ErrorFile=./hs_err_pid<pid>.log 保存錯誤日誌或者數據到文件中
-XX:-ExtendedDTraceProbes 開啓solaris特有的dtrace探針
-XX:HeapDumpPath=./java_pid<pid>.hprof 指定導出堆信息時的路徑或文件名
-XX:-HeapDumpOnOutOfMemoryError 當首次遭遇OOM時導出此時堆中相關信息
-XX:OnError="<cmd args>;<cmd args>" 出現致命ERROR以後運行自定義命令
-XX:OnOutOfMemoryError="<cmd args>;<cmd args>" 當首次遭遇OOM時執行自定義命令
-XX:-PrintClassHistogram 遇到Ctrl-Break後打印類實例的柱狀信息，與jmap -histo功能相同
-XX:-PrintConcurrentLocks 遇到Ctrl-Break後打印併發鎖的相關信息，與jstack -l功能相同
-XX:-PrintCommandLineFlags 打印在命令行中出現過的標記
-XX:-PrintCompilation 當一個方法被編譯時打印相關信息
-XX:-PrintGC 每次GC時打印相關信息
-XX:-PrintGC Details 每次GC時打印詳細信息
-XX:-PrintGCTimeStamps 打印每次GC的時間戳
-XX:-TraceClassLoading 跟蹤類的加載信息
-XX:-TraceClassLoadingPreorder 跟蹤被引用到的全部類的加載信息
-XX:-TraceClassResolution 跟蹤常量池
-XX:-TraceClassUnloading 跟蹤類的卸載信息
-XX:-TraceLoaderConstraints 跟蹤類加載器約束的相關信息

-XX:+UseAdaptiveSizePolicy：設置此選項後，並行收集器會自動選擇年輕代區大小和相應的Survivor區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用並行收集器時，一直打開。

-XX:MaxTenuringThreshold=0：設置垃圾最大年齡。若是設置爲0的話，則年輕代對象不通過Survivor區，直接進入年老代。 對於年老代比較多的應用，能夠提升效率。若是將此值設置爲一個較大值，則年輕代對象會在Survivor區進行屢次複製，這樣能夠增長對象再年輕代的存活 時間，增長在年輕代即被回收的概論。

-XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間，若是沒法知足此時間，JVM會自動調全年輕代大小，以知足此值。

/usr/local/jdk/bin/java -Dresin.home=/usr/local/resin -server -Xms1800M -Xmx1800M -Xmn300M -Xss512K -XXermSize=300M -XX:MaxPermSize=300M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:GCTimeRatio=19 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

堆大小設置

JVM 中最大堆大小有三方面限制：相關操做系統的數據模型（32-bt仍是64-bit）限制；系統的可用虛擬內存限制；系統的可用物理內存限制。32位系統 下，通常限制在1.5G~2G；64爲操做系統對內存無限制。我在Windows Server 2003 系統，3.5G物理內存，JDK5.0下測試，最大可設置爲1478m。

典型JVM參數設置：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k

-Xmx3550m：設置JVM最大可用內存爲3550M。

-Xms3550m：設置JVM促使內存爲3550m。此值能夠設置與-Xmx相同，以免每次垃圾回收完成後JVM從新分配內存。

-Xmn2g：設置年輕代大小爲2G。整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代通常固定大小爲64m，因此增大年輕代後，將會減少年老代大小。此值對系統性能影響較大，Sun官方推薦配置爲整個堆的3/8。

-Xss128k：設置每一個線程的堆棧大小。JDK5.0之後每一個線程堆棧大小爲1M，之前每一個線程堆棧大小爲256K。更具應用的線程所需內存大小進行 調整。在相同物理內存下，減少這個值能生成更多的線程。可是操做系統對一個進程內的線程數仍是有限制的，不能無限生成，經驗值在 3000~5000 左右。

java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0

-XX:NewRatio=4:設置年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設置爲4，則年輕代與年老代所佔比值爲1：4，年輕代佔整個堆棧的1/5

-XX:SurvivorRatio=4：設置年輕代中Eden區與Survivor區的大小比值。設置爲4，則兩個Survivor區與一個 Eden區的比值爲2:4，一個Survivor區佔整個年輕代的1/6

-XX:MaxPermSize=16m:設置持久代大小爲16m。

-XX:MaxTenuringThreshold=0：設置垃圾最大年齡。若是設置爲0的話，則年輕代對象不通過Survivor區，直接進入年老代。 對於年老代比較多的應用，能夠提升效率。若是將此值設置爲一個較大值，則年輕代對象會在Survivor區進行屢次複製，這樣能夠增長對象再年輕代的存活 時間，增長在年輕代即被回收的概論。

回收器選擇

JVM給了三種選擇：串行收集器、並行收集器、併發收集器，可是串行收集器只適用於小數據量的狀況，因此這裏的選擇主要針對並行收集器和併發收集器。默認 狀況下，JDK5.0之前都是使用串行收集器，若是想使用其餘收集器須要在啓動時加入相應參數。JDK5.0之後，JVM會根據當前系統配置進行判斷。

吞吐量優先的並行收集器

如上文所述，並行收集器主要以到達必定的吞吐量爲目標，適用於科學技術和後臺處理等。

典型JVM參數配置：

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XXarallelGCThreads=20

-XX:+UseParallelGC：選擇垃圾收集器爲並行收集器。此配置僅對年輕代有效。即上述配置下，年輕代使用併發收集，而年老代仍舊使用串行收集。

-XXarallelGCThreads=20：配置並行收集器的線程數，即：同時多少個線程一塊兒進行垃圾回收。此值最好配置與處理器數目相等。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XXarallelGCThreads=20 -XX:+UseParallelOldGC

-XX:+UseParallelOldGC：配置年老代垃圾收集方式爲並行收集。JDK6.0支持對年老代並行收集。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100

-XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間，若是沒法知足此時間，JVM會自動調全年輕代大小，以知足此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy：設置此選項後，並行收集器會自動選擇年輕代區大小和相應的Survivor區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用並行收集器時，一直打開。

響應時間優先的併發收集器

如上文所述，併發收集器主要是保證系統的響應時間，減小垃圾收集時的停頓時間。適用於應用服務器、電信領域等。

典型JVM參數配置：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XXarallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

-XX:+UseConcMarkSweepGC：設置年老代爲併發收集。測試中配置這個之後，-XX:NewRatio=4的配置失效了，緣由不明。因此，此時年輕代大小最好用-Xmn設置。

-XX:+UseParNewGC:設置年輕代爲並行收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，因此無需再設置此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction：因爲併發收集器不對內存空間進行壓縮、整理，因此運行一段時間之後會產生「碎片」，使得運行效率下降。此值設置運行多少次GC之後對內存空間進行壓縮、整理。

-XX:+UseCMSCompactAtFullCollection：打開對年老代的壓縮。可能會影響性能，可是能夠消除碎片

輔助信息

JVM提供了大量命令行參數，打印信息，供調試使用。主要有如下一些：

-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可與上面兩個混合使用

輸出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中斷的執行時間。可與上面混合使用

輸出形式：Application time: 0.5291524 seconds

-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期間程序暫停的時間。可與上面混合使用

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

-XX:PrintHeapAtGC:打印GC先後的詳細堆棧信息

輸出形式：

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:與上面幾個配合使用，把相關日誌信息記錄到文件以便分析。

常見JVM參數配置彙總

堆設置

-Xms:初始堆大小

-Xmx:最大堆大小

-XX:NewSize=n:設置年輕代大小

-XX:NewRatio=n:設置年輕代和年老代的比值。如:爲3，表示年輕代與年老代比值爲1：3，年輕代佔整個年輕代年老代和的1/4

-XX:SurvivorRatio=n:年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如：3，表示 Eden：Survivor=3：2，一個Survivor區佔整個年輕代的1/5

-XX:MaxPermSize=n:設置持久代大小

收集器設置

-XX:+UseSerialGC:設置串行收集器

-XX:+UseParallelGC:設置並行收集器

-XX:+UseParalledlOldGC:設置並行年老代收集器

-XX:+UseConcMarkSweepGC:設置併發收集器

垃圾回收統計信息

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

並行收集器設置

-XX:ParallelGCThreads=n:設置並行收集器收集時使用的CPU數。並行收集線程數。

-XX:MaxGCPauseMillis=n:設置並行收集最大暫停時間

-XX:GCTimeRatio=n:設置垃圾回收時間佔程序運行時間的百分比。公式爲1/(1+n)

併發收集器設置

-XX:+CMSIncrementalMode:設置爲增量模式。適用於單CPU狀況。

-XX:ParallelGCThreads=n:設置併發收集器年輕代收集方式爲並行收集時，使用的CPU數。並行收集線程數。

4、調優總結

年輕代大小選擇

響應時間優先的應用：儘量設大，直到接近系統的最低響應時間限制（根據實際狀況選擇）。在此種狀況下，年輕代收集發生的頻率也是最小的。同時，減小到達年老代的對象。

吞吐量優先的應用：儘量的設置大，可能到達Gbit的程度。由於對響應時間沒有要求，垃圾收集能夠並行進行，通常適合8CPU以上的應用。

年老代大小選擇

響應時間優先的應用：年老代使用併發收集器，因此其大小須要當心設置，通常要考慮併發會話率和會話持續時間等一些參數。若是堆設置小了，能夠會形成內存碎 片、高回收頻率以及應用暫停而使用傳統的標記清除方式；若是堆大了，則須要較長的收集時間。最優化的方案，通常須要參考如下數據得到：

併發垃圾收集信息

持久代併發收集次數

傳統GC信息

花在年輕代和年老代回收上的時間比例

減小年輕代和年老代花費的時間，通常會提升應用的效率

吞吐量優先的應用：通常吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。緣由是，這樣能夠儘量回收掉大部分短時間對象，減小中期的對象，而年老代盡存放長期存活對象。

較小堆引發的碎片問題

由於年老代的併發收集器使用標記、清除算法，因此不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合併，這樣能夠分配給較大的對象。可是，當堆空 間較小時，運行一段時間之後，就會出現「碎片」，若是併發收集器找不到足夠的空間，那麼併發收集器將會中止，而後使用傳統的標記、清除方式進行回收。若是 出現「碎片」，可能須要進行以下JVM參數配置：

-XX:+UseCMSCompactAtFullCollection：使用併發收集器時，開啓對年老代的壓縮。

-XX:CMSFullGCsBeforeCompaction=0：上面配置開啓的狀況下，這裏設置多少次Full GC後，對年老代進行壓縮

1: heap size

a: -Xmx<n>                     

指定 jvm 的最大 heap 大小 , 如 :-Xmx=2g

b: -Xms<n>                     

指定 jvm 的最小 heap 大小 , 如 :-Xms=2g ， 高併發應用， 建議和-Xmx同樣， 防止由於內存收縮／忽然增大帶來的性能影響。

c: -Xmn<n>                     

指定 jvm 中 New Generation 的大小 , 如 :-Xmn256m。 這個參數很影響性能， 若是你的程序須要比較多的臨時內存， 建議設置到512M， 若是用的少， 儘可能下降這個數值， 通常來講128／256足以使用了。

d: -XX:PermSize=<n>

指定 jvm 中 Perm Generation 的最小值 , 如 :-XX:PermSize=32m。 這個參數須要看你的實際狀況，。 能夠經過jmap 命令看看到底須要多少。

e: -XX:MaxPermSize=<n>         

指定 Perm Generation 的最大值 , 如 :-XX:MaxPermSize=64m

f: -Xss<n>                     

指定線程桟大小 , 如 :-Xss128k， 通常來講，webx框架下的應用須要256K。 若是你的程序有大規模的遞歸行爲， 請考慮設置到512K／1M。 這個須要全面的測試才能知道。 不過， 256K已經很大了。 這個參數對性能的影響比較大的。

g: -XX:NewRatio=<n>

指定 jvm 中 Old Generation heap size 與 New Generation 的比例 , 在使用 CMS GC 的狀況下此參數失效 , 如 :-XX:NewRatio=2

h: -XX:SurvivorRatio=<n>

指定 New Generation 中 Eden Space 與一個 Survivor Space 的 heap size 比例 ,-XX:SurvivorRatio=8, 那麼在總共 New Generation 爲 10m 的狀況下 ,Eden Space 爲 8m

i: -XX:MinHeapFreeRatio=<n>

指定 jvm heap 在使用率小於 n 的狀況下 ,heap 進行收縮 ,Xmx==Xms 的狀況下無效 , 如 :-XX:MinHeapFreeRatio=30

j: -XX:MaxHeapFreeRatio=<n>

指定 jvm heap 在使用率大於 n 的狀況下 ,heap 進行擴張 ,Xmx==Xms 的狀況下無效 , 如 :-XX:MaxHeapFreeRatio=70

k: -XXargePageSizeInBytes=<n>

指定 Java heap 的分頁頁面大小 , 如 :-XXargePageSizeInBytes=128m

2: garbage collector

a: -XX:+UseParallelGC

指定在 New Generation 使用 parallel collector, 並行收集 , 暫停 app threads, 同時啓動多個垃圾回收 thread, 不能和 CMS gc 一塊兒使用 . 系統噸吐量優先 , 可是會有較長長時間的 app pause, 後臺系統任務可使用此 gc

b: -XX:ParallelGCThreads=<n>

指定 parallel collection 時啓動的 thread 個數 , 默認是物理 processor 的個數 ,

c: -XX:+UseParallelOldGC

指定在 Old Generation 使用 parallel collector

d: -XX:+UseParNewGC

指定在 New Generation 使用 parallel collector, 是 UseParallelGC 的 gc 的升級版本 , 有更好的性能或者優勢 , 能夠和 CMS gc 一塊兒使用

e: -XX:+CMSParallelRemarkEnabled

在使用 UseParNewGC 的狀況下 , 儘可能減小 mark 的時間

f: -XX:+UseConcMarkSweepGC

指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 並行 ( 在 init-mark 和 remark 時 pause app thread). app pause 時間較短 , 適合交互性強的系統 , 如 web server

g: -XX:+UseCMSCompactAtFullCollection

在使用 concurrent gc 的狀況下 , 防止 memory fragmention, 對 live object 進行整理 , 使 memory 碎片減小

h: -XX:CMSInitiatingOccupancyFraction=<n>

指示在 old generation 在使用了 n% 的比例後 , 啓動 concurrent collector, 默認值是 68, 如 :-XX:CMSInitiatingOccupancyFraction=70

有個 bug, 在低版本(1.5.09 and early)的 jvm 上出現 , http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089

i: -XX:+UseCMSInitiatingOccupancyOnly

指示只有在 old generation 在使用了初始化的比例後 concurrent collector 啓動收集

3thers

a: -XX:MaxTenuringThreshold=<n>

指定一個 object 在經歷了 n 次 young gc 後轉移到 old generation 區 , 在 linux64 的 java6 下默認值是 15, 此參數對於 throughput collector 無效 , 如 :-XX:MaxTenuringThreshold=31

b: -XX:+DisableExplicitGC

禁止 java 程序中的 full gc, 如 System.gc() 的調用. 最好加上麼， 防止程序在代碼裏誤用了。對性能形成衝擊。

c: -XX:+UseFastAccessorMethods

get,set 方法轉成本地代碼

d: -XX:+PrintGCDetails

打應垃圾收集的狀況如 :

[GC 15610.466: [ParNew: 229689K->20221K(235968K), 0.0194460 secs] 1159829K->953935K(2070976K), 0.0196420 secs]

e: -XX:+PrintGCTimeStamps

打應垃圾收集的時間狀況 , 如 :

[Times: user=0.09 sys=0.00, real=0.02 secs]

f: -XX:+PrintGCApplicationStoppedTime

打應垃圾收集時 , 系統的停頓時間 , 如 :

Total time for which application threads were stopped: 0.0225920 seconds

4: a web server product sample and process

JAVA_OPTS=" -server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XXargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "

最初的時候咱們用 UseParallelGC 和 UseParallelOldGC,heap 開了 3G,NewRatio 設成 1. 這樣的配置下 young gc 發生頻率約 12,3 妙一次 , 平均每次花費 80ms 左右 ,full gc 發生的頻率極低 , 每次消耗 1s 左右 . 從全部 gc 消耗系統時間看 , 系統使用率仍是滿高的 , 可是不管是 young gc 仍是 old gc,applicaton thread pause 的時間比較長 , 不合適 web 應用 . 咱們也調小 New Generation 的 , 可是這樣會使 full gc 時間加長 .

後來咱們就用 CMS gc(-XX:+UseConcMarkSweepGC), 當時的總 heap 仍是 3g, 新生代 1.5g 後 , 觀察不是很理想 , 改成 jvm heap 爲 2g 新生代設置 -Xmn1g, 在這樣的狀況下 young gc 發生的頻率變成 ,7,8 妙一次 , 平均每次時間 40~50 毫秒左右 ,CMS gc 不多發生 , 每次時間在 init-mark 和 remark(two steps stop all app thread) 總共平均花費 80~90ms 左右 .

在這裏咱們曾經 New Generation 調大到 1400m, 總共 2g 的 jvm heap, 平均每次 ygc 花費時間 60~70ms 左右 ,CMS gc 的 init-mark 和 remark 之和平均在 50ms 左右 , 這裏咱們意識到錯誤的方向 , 或者說 CMS 的做用 , 因此進行了修改

最後咱們調小 New Generation 爲 256m,young gc 2,3 秒發生一次 , 平均停頓時間在 25 毫秒左右 ,CMS gc 的 init-mark 和 remark 之和平均在 50ms 左右 , 這樣使系統比較平滑 , 經壓力測試 , 這個配置下系統性能是比較高的

在使用 CMS gc 的時候他有兩種觸發 gc 的方式 :gc 估算觸發和 heap 佔用觸發 . 咱們的 1.5.0.09 環境下有次 old 區 heap 佔用再 30% 左右 , 她就頻繁 gc, 我的感受系統估算觸發這種方式不靠譜 , 仍是用 heap 使用比率觸發比較穩妥 .

這些數據都來自 64 位測試機 , 過程當中的數據都是我在 jboss log 找的 , 當時沒有記下來 , 可能存在一點點誤差 , 但不會很大 , 基本過程就是這樣 .

5: 總結

web server 做爲交互性要求較高的應用 , 咱們應該使用 Parallel+CMS,UseParNewGC 這個在 jdk6 -server 上是默認的 ,new generation gc, 新生代不能太大 , 這樣每次 pause 會短一些 .CMS mark-sweep generation 能夠大一些 , 能夠根據 pause time 實際狀況控制。