JDK5.0垃圾收集優化

 

      作者：江南白衣，最新版鏈接：http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx，版權所有，轉載請保留原文鏈接。

      原本想把題目更簡單的定爲--《不要停》的，但還是自己YY一下就算了。
      Java開發Server最大的障礙，就是JDK1.4版之前的的串行垃圾收集機制會引起長時間的服務暫停，明白原理後，想想那些用JDK1.3寫Server的先輩，不得不後怕。
     好在JDK1.4已開始支持多線程並行的後臺垃圾收集算法，JDK5.0則優化了默認值的設置。

一、參考資料：

1. Tuning Garbage Collection with the 5.0 Java Virtual Machine 官方指南。
2. Hotspot memory management whitepaper 官方白皮書。
3. Java Tuning White Paper 官方文檔。
4. FAQ about Garbage Collection in the Hotspot  官方FAQ，JVM1.4.2。
5. Java HotSpot 虛擬機中的垃圾收集 JavaOne2004上的中文ppt
6. A Collection of JVM Options JVM選項的超完整收集。

二、基本概念

1、堆(Heap)

JVM管理的內存叫堆。在32Bit操作系統上有1.5G-2G的限制，而64Bit的就沒有。

JVM初始分配的內存由-Xms指定，默認是物理內存的1/64但小於1G。

JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4但小於1G。

默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制，可以由-XX:MinHeapFreeRatio=指定。
默認空餘堆內存大於70%時，JVM會減少堆直到-Xms的最小限制，可以由-XX:MaxHeapFreeRatio=指定。

服務器一般設置-Xms、-Xmx相等以避免在每次GC 後調整堆的大小，所以上面的兩個參數沒啥用。 

2.基本收集算法

1. 複製：將堆內分成兩個相同空間，從根(ThreadLocal的對象，靜態對象）開始訪問每一個關聯的活躍對象，將空間A的活躍對象全部複製到空間B，然後一次性回收整個空間A。
   因爲只訪問活躍對象，將所有活動對象複製走之後就清空整個空間，不用去訪問死對象，所以遍歷空間的成本較小，但需要巨大的複製成本和較多的內存。
2. 標記清除(mark-sweep)：收集器先從根開始訪問所有活躍對象，標記爲活躍對象。然後再遍歷一次整個內存區域，把所有沒有標記活躍的對象進行回收處理。該算法遍歷整個空間的成本較大暫停時間隨空間大小線性增大，而且整理後堆裏的碎片很多。
3. 標記整理(mark-sweep-compact)：綜合了上述兩者的做法和優點，先標記活躍對象，然後將其合併成較大的內存塊。

    可見，沒有免費的午餐，無論採用複製還是標記清除算法，自動的東西都要付出很大的性能代價。

3.分代

    分代是Java垃圾收集的一大亮點，根據對象的生命週期長短，把堆分爲3個代：Young，Old和Permanent，根據不同代的特點採用不同的收集算法，揚長避短也。

Young(Nursery)，年輕代。研究表明大部分對象都是朝生暮死，隨生隨滅的。因此所有收集器都爲年輕代選擇了複製算法。
    複製算法優點是隻訪問活躍對象，缺點是複製成本高。因爲年輕代只有少量的對象能熬到垃圾收集，因此只需少量的複製成本。而且複製收集器只訪問活躍對象，對那些佔了最大比率的死對象視而不見，充分發揮了它遍歷空間成本低的優點。

    Young的默認值爲4M，隨堆內存增大，約爲1/15，JVM會根據情況動態管理其大小變化。
    -XX:NewRatio= 參數可以設置Young與Old的大小比例，-server時默認爲1:2，但實際上young啓動時遠低於這個比率？如果信不過JVM，也可以用-Xmn硬性規定其大小，有文檔推薦設爲Heap總大小的1/4。

    Young的大小非常非常重要，見“後面暫停時間優先收集器”的論述。

    Young裏面又分爲3個區域，一個Eden，所有新建對象都會存在於該區，兩個Survivor區，用來實施複製算法。每次複製就是將Eden和第一塊 Survior的活對象複製到第2塊，然後清空Eden與第一塊Survior。Eden與Survivor的比例由-XX:SurvivorRatio =設置，默認爲32。Survivio大了會浪費，小了的話，會使一些年輕對象潛逃到老人區，引起老人區的不安，但這個參數對性能並不重要。 

Old(Tenured)，年老代。年輕代的對象如果能夠挺過數次收集，就會進入老人區。老人區使用標記整理算 法。因爲老人區的對象都沒那麼容易死的，採用複製算法就要反覆的複製對象，很不合算，只好採用標記清理算法，但標記清理算法其實也不輕鬆，每次都要遍歷區 域內所有對象，所以還是沒有免費的午餐啊。

-XX:MaxTenuringThreshold=設置熬過年輕代多少次收集後移入老人區，CMS中默認爲0，熬過第一次GC就轉入，可以用-XX:+PrintTenuringDistribution查看。

Permanent，持久代。裝載Class信息等基礎數據，默認64M，如果是類很多很多的服務程序，需要加 大其設置-XX:MaxPermSize=，否則它滿了之後會引起fullgc()或Out of Memory。 注意Spring，Hibernate這類喜歡AOP動態生成類的框架需要更多的持久代內存。

4.minor/major collection

    每個代滿了之後都會促發collection，（另外Concurrent Low Pause Collector默認在老人區68%的時候促發)。GC用較高的頻率對young進行掃描和回收，這種叫做minor collection。
而因爲成本關係對Old的檢查回收頻率要低很多，同時對Young和Old的收集稱爲major collection。
    System.gc()會引發major collection，使用-XX:+DisableExplicitGC禁止它，或設爲CMS併發-XX:+ExplicitGCInvokesConcurrent。

5.小結

Young -- minor collection -- 複製算法

Old(Tenured) -- major colletion -- 標記清除/標記整理算法

三、收集器

1.古老的串行收集器(Serial Collector)

    使用 -XX:+UseSerialGC，策略爲年輕代串行復制，年老代串行標記整理。

2.吞吐量優先的並行收集器(Throughput Collector)

    使用 -XX:+UseParallelGC ，也是JDK5 -server的默認值。策略爲：
    1.年輕代暫停應用程序，多個垃圾收集線程並行的複製收集，線程數默認爲CPU個數，CPU很多時，可用–XX:ParallelGCThreads=減少線程數。
    2.年老代暫停應用程序，與串行收集器一樣，單垃圾收集線程標記整理。

    所以需要2+的CPU時纔會優於串行收集器，適用於後臺處理，科學計算。

    可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 來調整GC的時間。

3.暫停時間優先的併發收集器(Concurrent Low Pause Collector-CMS)

    前面說了這麼多，都是爲了這節做鋪墊......

    使用-XX:+UseConcMarkSweepGC，策略爲：
    1.年輕代同樣是暫停應用程序，多個垃圾收集線程並行的複製收集。
    2.年老代則只有兩次短暫停，其他時間應用程序與收集線程併發的清除。

3.1 年老代詳述

    並行(Parallel)與併發(Concurrent)僅一字之差，並行指多條垃圾收集線程並行，併發指用戶線程與垃圾收集線程併發，程序在繼續運行，而垃圾收集程序運行於另一個個CPU上。

    併發收集一開始會很短暫的停止一次所有線程來開始初始標記根對象，然後標記線程與應用線程一起併發運行，最後又很短的暫停一次，多線程並行的重新標記之前可能因爲併發而漏掉的對象，然後就開始與應用程序併發的清除過程。可見，最長的兩個遍歷過程都是與應用程序併發執行的，比以前的串行算法改進太多太多了！！！

    串行標記清除是等年老代滿了再開始收集的，而併發收集因爲要與應用程序一起運行，如果滿了才收集，應用程序就無內存可用，所以系統默認68%滿的時候就開 始收集。內存已設得較大，吃內存又沒有這麼快的時候，可以用-XX:CMSInitiatingOccupancyFraction=恰當增大該比率。

3.2 年輕代詳述

   可惜對年輕代的複製收集，依然必須停止所有應用程序線程，原理如此，只能靠多CPU，多收集線程併發來提高收集速度，但除非你的Server 獨佔整臺服務器，否則如果服務器上本身還有很多其他線程時，切換起來速度就..... 所以，搞到最後，暫停時間的瓶頸就落在了年輕代的複製算法上。

    因此Young的大小設置挺重要的，大點就不用頻繁GC，而且增大GC的間隔後，可以讓多點對象自己死掉而不用複製了。但Young增大時，GC造成的停 頓時間攀升得非常恐怖，比如在我的機器上，默認8M的Young，只需要幾毫秒的時間，64M就升到90毫秒，而升到256M時，就要到300毫秒了，峯 值還會攀到恐怖的800ms。誰叫複製算法，要等Young滿了纔開始收集，開始收集就要停止所有線程呢。

3.3 持久代

可設置-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled，使CMS收集持久代的類，而不是fullgc，netbeans5.5 performance文檔的推薦。

4.增量(train算法)收集器(Incremental Collector)

已停止維護，–Xincgc選項默認轉爲併發收集器。

四、暫停時間顯示

 加入下列參數 (請將PrintGC和Details中間的空格去掉，CSDN很怪的認爲是禁止字句） 

-verbose:gc -XX:+PrintGC Details  -XX:+PrintGCTimeStamps

會程序運行過程中將顯示如下輸出

 9.211: [GC 9.211: [ParNew: 7994K->0K(8128K), 0.0123935 secs] 427172K->419977K(524224K), 0.0125728 secs]

 顯示在程序運行的9.211秒發生了Minor的垃圾收集，前一段數據針對新生區，從7994k整理爲0k，新生區總大小爲8128k，程序暫停了12ms，而後一段數據針對整個堆。

對於年老代的收集，暫停發生在下面兩個階段，CMS-remark的中斷是17毫秒：

[GC [1 CMS-initial-mark: 80168K(196608K)] 81144K(261184K), 0.0059036 secs] 

[1 CMS-remark: 80168K(196608K)] 82493K(261184K),0.0168943 secs]

再加兩個參數 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime對暫停時間看得更清晰。

五、真正不停的BEA JRockit 與Sun RTS2.0

   Bea的JRockit 5.0 R27 的特色之一是動態決定的垃圾收集策略，用戶可以決定自己關心的是吞吐量，暫停時間還是確定的暫停時間，再由JVM在運行時動態決定、改變改變垃圾收集策略。
   
   它的Deterministic GC的選項是-Xgcprio: deterministic，號稱可以把暫停可以控制在10-30毫秒，非常的牛，一句Deterministic道盡了RealTime的真諦。 不過細看一下文檔，30ms的測試環境是1 GB heap 和 平均  30% 的活躍對象(也就是300M)活動對象，2 個 Xeon 3.6 GHz  4G內存 ，或者是4 個Xeon 2.0 GHz，8G內存。

  最可惜JRockt的license很奇怪，雖然平時使用免費，但這個30ms的選項就需要購買整個Weblogic Real Time Server的license。 

  其他免費選項，有：

• -Xgcprio:pausetime -Xpausetarget=210ms 
    因爲免費，所以最低只能設置到200ms pause target。 200ms是Sun認爲Real-Time的分界線。
• -Xgc:gencon
  普通的併發做法，效率也不錯。

  JavaOne2007上有Sun的 Java Real-Time System 2.0 的介紹，RTS2.0基於JDK1.5，在Real-Time  Garbage Collctor上又有改進，但還在beta版狀態，只供給OEM，更怪。

六、JDK 6.0的改進

因爲JDK5.0在Young較大時的表現還是不夠讓人滿意，又繼續看JDK6.0的改進，結果稍稍失望，不涉及我最頭痛的年輕代複製收集改良。

1.年老代的標識-清除收集，並行執行標識
  JDK5.0只開了一條收集進程與應用線程併發標識，而6.0可以開多條收集線程來做標識，縮短標識老人區所有活動對象的時間。

2.加大了Young區的默認大小
默認大小從4M加到16M，從堆內存的1/15增加到1/7

3.System.gc()可以與應用程序併發執行
使用-XX:+ExplicitGCInvokesConcurrent 設置

七、小結

1. JDK5.0/6.0

對於服務器應用，我們使用Concurrent Low Pause Collector，對年輕代，暫停時多線程並行複製收集；對年老代，收集器與應用程序並行標記--整理收集，以達到儘量短的垃圾收集時間。

本着沒有深刻測試前不要胡亂優化的宗旨，命令行屬性只需簡單寫爲：

-server -Xms<heapsize>M -Xmx<heapsize>M -XX:+UseConcMarkSweepGC  -XX:+PrintGC Details  -XX:+PrintGCTimeStamps

然後要根據應用的情況，在測試軟件輔助可以下看看有沒有JVM的默認值和自動管理做的不夠的地方可以調整，如-xmn 設Young的大小，-XX:MaxPermSize設持久代大小等。

2. JRockit 6.0 R27.2

但因爲JDK5的測試結果實在不能滿意，後來又嘗試了JRockit，總體效果要好些。
 JRockit的特點是動態垃圾收集器是根據用戶關心的特徵動態決定收集算法的，參數如下

 -Xms<heapsize>M -Xmx<heapsize>M -Xgcprio:pausetime -Xpausetarget=200ms -XgcReport -XgcPause -Xverbose:memory