1.1.2. 瞭解JVM各種參數及調優

tomcat啓動參數，將JVM GC信息寫入tomcat_gc.log

CATALINA_OPTS='-Xms512m -Xmx4096m -XX:PermSize=64M -XX:MaxNewSize=128m -XX:MaxPermSize=64m -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC -Xloggc:/var/log/search/tomcat_gc.log'

各個參數含義，以及GC機制，參考下文：

一、相關概念

基本回收算法

1. 引用計數（Reference Counting） 
   比較古老的回收算法。原理是此對象有一個引用，即增加一個計數，刪除一個引用則減少一個計數。垃圾回收時，只用收集計數爲0的對象。此算法最致命的是無法處理循環引用的問題。
2. 標記-清除（Mark-Sweep） 
   此算法執行分兩階段。第一階段從引用根節點開始標記所有被引用的對象，第二階段遍歷整個堆，把未標記的對象清除。此算法需要暫停整個應用，同時，會產生內存碎片。
3. 複製（Copying） 
   此 算法把內存空間劃爲兩個相等的區域，每次只使用其中一個區域。垃圾回收時，遍歷當前使用區域，把正在使用中的對象複製到另外一個區域中。次算法每次只處理 正在使用中的對象，因此複製成本比較小，同時複製過去以後還能進行相應的內存整理，不過出現“碎片”問題。當然，此算法的缺點也是很明顯的，就是需要兩倍 內存空間。
4. 標記-整理（Mark-Compact） 
   此算法結合了“標記-清除”和“復 制”兩個算法的優點。也是分兩階段，第一階段從根節點開始標記所有被引用對象，第二階段遍歷整個堆，把清除未標記對象並且把存活對象“壓縮”到堆的其中一 塊，按順序排放。此算法避免了“標記-清除”的碎片問題，同時也避免了“複製”算法的空間問題。
5. 增量收集（Incremental Collecting） 
   實施垃圾回收算法，即：在應用進行的同時進行垃圾回收。不知道什麼原因JDK5.0中的收集器沒有使用這種算法的。
6. 分代（Generational Collecting） 
   基於對對象生命週期分析後得出的垃圾回收算法。把對象分爲年青代、年老代、持久代，對不同生命週期的對象使用不同的算法（上述方式中的一個）進行回收。現在的垃圾回收器（從J2SE1.2開始）都是使用此算法的。

分代垃圾回收詳述

1. Young（年輕代） 
   年 輕代分三個區。一個Eden區，兩個Survivor區。大部分對象在Eden區中生成。當Eden區滿時，還存活的對象將被複制到Survivor區 （兩個中的一個），當這個Survivor區滿時，此區的存活對象將被複制到另外一個Survivor區，當這個Survivor去也滿了的時候，從第一 個Survivor區複製過來的並且此時還存活的對象，將被複制“年老區(Tenured)”。需要注意，Survivor的兩個區是對稱的，沒先後關 系，所以同一個區中可能同時存在從Eden複製過來 對象，和從前一個Survivor複製過來的對象，而複製到年老區的只有從第一個Survivor去過來的對象。而且，Survivor區總有一個是空 的。
2. Tenured（年老代） 
   年老代存放從年輕代存活的對象。一般來說年老代存放的都是生命期較長的對象。
3. Perm（持久代） 
   用 於存放靜態文件，如今Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者調用一些class，例如Hibernate等， 在這種時候需要設置一個比較大的持久代空間來存放這些運行過程中新增的類。持久代大小通過-XX:MaxPermSize=進行設置。

GC類型 
GC有兩種類型：Scavenge GC和Full GC。

1. Scavenge GC 
   一般情況下，當新對象生成，並且在Eden申請空間失敗時，就好觸發Scavenge GC，堆Eden區域進行GC，清除非存活對象，並且把尚且存活的對象移動到Survivor區。然後整理Survivor的兩個區。
2. Full GC 
   對整個堆進行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此應該儘可能減少Full GC。有如下原因可能導致Full GC：
   • Tenured被寫滿
   • Perm域被寫滿
   • System.gc()被顯示調用
   • 上一次GC之後Heap的各域分配策略動態變化

二、垃圾回收器

目前的收集器主要有三種：串行收集器、並行收集器、併發收集器。

1. 串行收集器 
   使用單線程處理所有垃圾回收工作，因爲無需多線程交互，所以效率比較高。但是，也無法使用多處理器的優勢，所以此收集器適合單處理器機器。當然，此收集器也可以用在小數據量（100M左右）情況下的多處理器機器上。可以使用-XX:+UseSerialGC打開。
2. 並行收集器 
   
   1. 對年輕代進行並行垃圾回收，因此可以減少垃圾回收時間。一般在多線程多處理器機器上使用。使用-XX:+UseParallelGC.打開。並行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中進行了增強--可以堆年老代進行並行收集。如果年老代不使用併發收集的話，是使用單線程進行垃圾回收，因此會制約擴展能力。使用-XX:+UseParallelOldGC打開。
   2. 使用-XX:ParallelGCThreads=設置並行垃圾回收的線程數。此值可以設置與機器處理器數量相等。
   3. 此收集器可以進行如下配置：
      • 最大垃圾回收暫停:指定垃圾回收時的最長暫停時間，通過-XX:MaxGCPauseMillis=指定。爲毫秒.如果指定了此值的話，堆大小和垃圾回收相關參數會進行調整以達到指定值。設定此值可能會減少應用的吞吐量。
      • 吞吐量:吞吐量爲垃圾回收時間與非垃圾回收時間的比值，通過-XX:GCTimeRatio=來設定，公式爲1/（1+N）。例如，-XX:GCTimeRatio=19時，表示5%的時間用於垃圾回收。默認情況爲99，即1%的時間用於垃圾回收。
3. 併發收集器 
   可以保證大部分工作都併發進行（應用不停止），垃圾回收只暫停很少的時間，此收集器適合對響應時間要求比較高的中、大規模應用。使用-XX:+UseConcMarkSweepGC打開。
   1. 並 發收集器主要減少年老代的暫停時間，他在應用不停止的情況下使用獨立的垃圾回收線程，跟蹤可達對象。在每個年老代垃圾回收週期中，在收集初期併發收集器會 對整個應用進行簡短的暫停，在收集中還會再暫停一次。第二次暫停會比第一次稍長，在此過程中多個線程同時進行垃圾回收工作。
   2. 併發收集器使用處理器換來短暫的停頓時間。在一個N個處理器的系統上，併發收集部分使用K/N個可用處理器進行回收，一般情況下1<=K<=N/4。
   3. 在只有一個處理器的主機上使用併發收集器，設置爲incremental mode模式也可獲得較短的停頓時間。
   4. 浮動垃圾：由於在應用運行的同時進行垃圾回收，所以有些垃圾可能在垃圾回收進行完成時產生，這樣就造成了“Floating Garbage”，這些垃圾需要在下次垃圾回收週期時才能回收掉。所以，併發收集器一般需要20%的預留空間用於這些浮動垃圾。
   5. Concurrent Mode Failure：併發收集器在應用運行時進行收集，所以需要保證堆在垃圾回收的這段時間有足夠的空間供程序使用，否則，垃圾回收還未完成，堆空間先滿了。這種情況下將會發生“併發模式失敗”，此時整個應用將會暫停，進行垃圾回收。
   6. 啓動併發收集器：因爲併發收集在應用運行時進行收集，所以必須保證收集完成之前有足夠的內存空間供程序使用，否則會出現“Concurrent Mode Failure”。通過設置-XX:CMSInitiatingOccupancyFraction=指定還有多少剩餘堆時開始執行併發收集
4. 小結
   • 串行處理器： 
     --適用情況：數據量比較小（100M左右）；單處理器下並且對響應時間無要求的應用。 
     --缺點：只能用於小型應用
   • 並行處理器： 
     --適用情況：“對吞吐量有高要求”，多CPU、對應用響應時間無要求的中、大型應用。舉例：後臺處理、科學計算。 
     --缺點：應用響應時間可能較長
   • 併發處理器： 
     --適用情況：“對響應時間有高要求”，多CPU、對應用響應時間有較高要求的中、大型應用。舉例：Web服務器/應用服務器、電信交換、集成開發環境。

三、常見配置舉例

1. 堆大小設置 
   JVM 中最大堆大小有三方面限制：相關操作系統的數據模型（32-bt還是64-bit）限制；系統的可用虛擬內存限制；系統的可用物理內存限制。32位系統 下，一般限制在1.5G~2G；64爲操作系統對內存無限制。我在Windows Server 2003 系統，3.5G物理內存，JDK5.0下測試，最大可設置爲1478m。 
   典型設置：
   • 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區進行多次複製，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。
2. 回收器選擇 
   JVM給了三種選擇：串行收集器、並行收集器、併發收集器，但是串行收集器只適用於小數據量的情況，所以這裏的選擇主要針對並行收集器和併發收集器。默認情況下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在啓動時加入相應參數。JDK5.0以後，JVM會根據當前系統配置進行判斷。
   1. 吞吐量優先的並行收集器 
      如上文所述，並行收集器主要以到達一定的吞吐量爲目標，適用於科學技術和後臺處理等。 
      典型配置：
      • 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區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用並行收集器時，一直打開。
   2. 響應時間優先的併發收集器 
      如上文所述，併發收集器主要是保證系統的響應時間，減少垃圾收集時的停頓時間。適用於應用服務器、電信領域等。 
      典型配置：
      • 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：打開對年老代的壓縮。可能會影響性能，但是可以消除碎片
3. 輔助信息 
   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:與上面幾個配合使用，把相關日誌信息記錄到文件以便分析。
4. 常見配置彙總
   1. 堆設置
      • -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:設置持久代大小
   2. 收集器設置
      • -XX:+UseSerialGC:設置串行收集器
      • -XX:+UseParallelGC:設置並行收集器
      • -XX:+UseParalledlOldGC:設置並行年老代收集器
      • -XX:+UseConcMarkSweepGC:設置併發收集器
   3. 垃圾回收統計信息
      • -XX:+PrintGC
      • -XX:+PrintGCDetails
      • -XX:+PrintGCTimeStamps
      • -Xloggc:filename
   4. 並行收集器設置
      • -XX:ParallelGCThreads=n:設置並行收集器收集時使用的CPU數。並行收集線程數。
      • -XX:MaxGCPauseMillis=n:設置並行收集最大暫停時間
      • -XX:GCTimeRatio=n:設置垃圾回收時間佔程序運行時間的百分比。公式爲1/(1+n)
   5. 併發收集器設置
      • -XX:+CMSIncrementalMode:設置爲增量模式。適用於單CPU情況。
      • -XX:ParallelGCThreads=n:設置併發收集器年輕代收集方式爲並行收集時，使用的CPU數。並行收集線程數。

四、調優總結

1. 年輕代大小選擇
   • 響應時間優先的應用：儘可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的對象。
   • 吞吐量優先的應用：儘可能的設置大，可能到達Gbit的程度。因爲對響應時間沒有要求，垃圾收集可以並行進行，一般適合8CPU以上的應用。
2. 年老代大小選擇
   • 響應時間優先的應用：年老代使用併發收集器，所以其大小需要小心設置，一般要考慮併發會話率和會話持續時間等一些參數。如果堆設置小了，可以會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；如果堆大了，則需要較長的收集時間。最優化的方案，一般需要參考以下數據獲得：
     • 併發垃圾收集信息
     • 持久代併發收集次數
     • 傳統GC信息
     • 花在年輕代和年老代回收上的時間比例
     減少年輕代和年老代花費的時間，一般會提高應用的效率
   • 吞吐量優先的應用：一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是，這樣可以儘可能回收掉大部分短期對象，減少中期的對象，而年老代盡存放長期存活對象。
3. 較小堆引起的碎片問題 
   因 爲年老代的併發收集器使用標記、清除算法，所以不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合併，這樣可以分配給較大的對象。但是，當堆空間 較小時，運行一段時間以後，就會出現“碎片”，如果併發收集器找不到足夠的空間，那麼併發收集器將會停止，然後使用傳統的標記、清除方式進行回收。如果出 現“碎片”，可能需要進行如下配置：
   • -XX:+UseCMSCompactAtFullCollection：使用併發收集器時，開啓對年老代的壓縮。
   • -XX:CMSFullGCsBeforeCompaction=0：上面配置開啓的情況下，這裏設置多少次Full GC後，對年老代進行壓縮

 

JVM參數調優是一個很頭痛的問題，可能和應用有關係，下面是本人一些調優的實踐經驗，希望對讀者能有幫助，環境LinuxAS4,resin2.1.17,JDK6.0,2CPU,4G內存,dell2950服務器，網站是http://shedewang.com

一：串行垃圾回收，也就是默認配置，完成10萬request用時153秒，JVM參數配置如下
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps ";
這種配置一般在resin啓動24小時內似乎沒有大問題，網站可以正常訪問，但查看日誌發現，在接近24小時時，Full GC執行越來越頻繁，大約每隔3分鐘就有一次Full GC，每次Full GC系統會停頓6秒左右，作爲一個網站來說，用戶等待6秒恐怕太長了，所以這種方式有待改善。MaxTenuringThreshold=7表示一個對象如果在救助空間移動7次還沒有被回收就放入年老代，GCTimeRatio=19表示java可以用5%的時間來做垃圾回收，1/(1+19)=1 /20=5%。

二：並行回收，完成10萬request用時117秒，配置如下：
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xmx2048M -Xms2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC -XX:MaxGCPauseMillis=500 -XX:+UseAdaptiveSizePolicy -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 ";
並行回收我嘗試過多種組合配置，似乎都沒什麼用，resin啓動3小時左右就會停頓，時間超過10 秒。也有可能是參數設置不夠好的原因，MaxGCPauseMillis表示GC最大停頓時間，在resin剛啓動還沒有執行Full GC時系統是正常的，但一旦執行Full GC，MaxGCPauseMillis根本沒有用，停頓時間可能超過20秒，之後會發生什麼我也不再關心了，趕緊重啓resin，嘗試其他回收策略。

三：併發回收，完成10萬request用時60秒，比並行回收差不多快一倍，是默認回收策略性能的2.5倍，配置如下：
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 ";
這個配置雖然不會出現10秒連不上的情況，但系統重啓3個小時左右，每隔幾分鐘就會有5秒連不上的情況，查看gc.log，發現在執行ParNewGC時有個promotion failed錯誤，從而轉向執行Full GC，造成系統停頓，而且會很頻繁，每隔幾分鐘就有一次，所以還得改善。UseCMSCompactAtFullCollection是表是執行Full GC後對內存進行整理壓縮，免得產生內存碎片，CMSFullGCsBeforeCompaction=N表示執行N次Full GC後執行內存壓縮。

四：增量回收，完成10萬request用時171秒，太慢了，配置如下
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xincgc ";
似乎回收得也不太乾淨，而且也對性能有較大影響，不值得試。

五：併發回收的I-CMS模式，和增量回收差不多，完成10萬request用時170秒。
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:-TraceClassUnloading ";
採用了sun推薦的參數，回收效果不好，照樣有停頓，數小時之內就會頻繁出現停頓，什麼sun推薦的參數，照樣不好使。

六：遞增式低暫停收集器，還叫什麼火車式回收，不知道屬於哪個系，完成10萬request用時153秒
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseTrainGC ";
該配置效果也不好，影響性能，所以沒試。

七：相比之下，還是併發回收比較好，性能比較高，只要能解決ParNewGC（並行回收年輕代）時的promotion failed錯誤就一切好辦了，查了很多文章，發現引起promotion failed錯誤的原因是CMS來不及回收（CMS默認在年老代佔到90%左右纔會執行），年老代又沒有足夠的空間供GC把一些活的對象從年輕代移到年老代，所以執行Full GC。CMSInitiatingOccupancyFraction=70表示年老代佔到約70%時就開始執行CMS，這樣就不會出現Full GC了。SoftRefLRUPolicyMSPerMB這個參數也是我認爲比較有用的，官方解釋是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秒，所以設置成0。配置如下
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -Xloggc:log/gc.log ";
上面這個配置內存上升的很慢，24小時之內幾乎沒有停頓現象，最長的只停滯了0.8s，ParNew GC每30秒左右才執行一次，每次回收約0.2秒，看來問題應該暫時解決了。

參數不明白的可以上網查，本人認爲比較重要的幾個參數是：-Xms -Xmx -Xmn MaxTenuringThreshold GCTimeRatio UseConcMarkSweepGC CMSInitiatingOccupancyFraction SoftRefLRUPolicyMSPerMB