JVM記憶體配置詳解
阿新 • • 發佈：2019-02-13
前段時間在一個專案的效能測試中又發生了一次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很多時，可用 -XX:ParallelGCThreads= 設定執行緒數。
年老代：暫停應用程式，與序列收集器一樣，單垃圾收集執行緒標記整理。
如上可知該收集器需要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不斷調整永久域大小。為了避免調整，可使用-XX:PerSize標誌設定初始值。
下面把永久域初始值設定成32m，最大值設定成64m。
java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=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 -XX:PermSize=64M -XX:MaxPermSize=128M -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
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也不推薦使用，後續可能會在沒有通知的情況下就直接取消了；但是由於這些引數中的確有很多是對我們很有用的，比如我們經常會見到的-XX:PermSize、-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的效率，但演算法複雜，系統消耗較大；
效能調優引數列表：
引數及其預設值 描述
-XX:LargePageSizeInBytes=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 -XX:PermSize=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 -XX:ParallelGCThreads=20
-XX:+UseParallelGC：選擇垃圾收集器為並行收集器。此配置僅對年輕代有效。即上述配置下，年輕代使用併發收集，而年老代仍舊使用序列收集。
-XX:ParallelGCThreads=20：配置並行收集器的執行緒數，即：同時多少個執行緒一起進行垃圾回收。此值最好配置與處理器數目相等。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=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 -XX:ParallelGCThreads=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數。並行收集執行緒數。
四、調優總結
年輕代大小選擇
響應時間優先的應用：儘可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的物件。
吞吐量優先的應用：儘可能的設定大，可能到達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: -XX:LargePageSizeInBytes=<n>
指定 Java heap 的分頁頁面大小 , 如 :-XX:LargePageSizeInBytes=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 啟動收集
3:others
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 -XX:LargePageSizeInBytes=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 實際情況控制。
原文地址：
基本概念
堆/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很多時，可用 -XX:ParallelGCThreads= 設定執行緒數。
年老代：暫停應用程式，與序列收集器一樣，單垃圾收集執行緒標記整理。
如上可知該收集器需要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不斷調整永久域大小。為了避免調整，可使用-XX:PerSize標誌設定初始值。
下面把永久域初始值設定成32m，最大值設定成64m。
java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=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 -XX:PermSize=64M -XX:MaxPermSize=128M -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
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也不推薦使用，後續可能會在沒有通知的情況下就直接取消了；但是由於這些引數中的確有很多是對我們很有用的，比如我們經常會見到的-XX:PermSize、-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的效率，但演算法複雜，系統消耗較大；
效能調優引數列表：
引數及其預設值 描述
-XX:LargePageSizeInBytes=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 -XX:PermSize=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 -XX:ParallelGCThreads=20
-XX:+UseParallelGC：選擇垃圾收集器為並行收集器。此配置僅對年輕代有效。即上述配置下，年輕代使用併發收集，而年老代仍舊使用序列收集。
-XX:ParallelGCThreads=20：配置並行收集器的執行緒數，即：同時多少個執行緒一起進行垃圾回收。此值最好配置與處理器數目相等。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=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 -XX:ParallelGCThreads=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數。並行收集執行緒數。
四、調優總結
年輕代大小選擇
響應時間優先的應用：儘可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的物件。
吞吐量優先的應用：儘可能的設定大，可能到達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: -XX:LargePageSizeInBytes=<n>
指定 Java heap 的分頁頁面大小 , 如 :-XX:LargePageSizeInBytes=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 啟動收集
3:others
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 -XX:LargePageSizeInBytes=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 實際情況控制。
原文地址：