????? 作者： 江南白衣 ，最新版鏈接： http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx ，版權(quán)所有，轉(zhuǎn)載請保留原文鏈接。
????? 原本想把題目更簡單的定為--《不要停》的，但還是自己YY一下就算了。
????? Java開發(fā)Server最大的障礙，就是JDK1.4版之前的的串行垃圾收集機制會引起長時間的服務(wù)暫停，明白原理后，想想那些用JDK1.3寫Server的先輩，不得不后怕。
?????好在JDK1.4已開始支持多線程并行的后臺垃圾收集算法，JDK5.0則優(yōu)化了默認(rèn)值的設(shè)置。
一、參考資料：
- Tuning Garbage Collection with the 5.0 Java Virtual Machine ?官方指南。
- Hotspot memory management whitepaper ?官方白皮書。
- Java Tuning White Paper 官方文檔。
- FAQ about Garbage Collection in the Hotspot? 官方FAQ，JVM1.4.2。
- Java HotSpot 虛擬機中的垃圾收集 ?JavaOne2004上的中文ppt
- A Collection of JVM Options ?JVM選項的超完整收集。
二、基本概念
1、堆(Heap)
JVM管理的內(nèi)存叫堆。在32Bit操作系統(tǒng)上有1.5G-2G的限制，而64Bit的就沒有。
JVM初始分配的內(nèi)存由-Xms指定，默認(rèn)是物理內(nèi)存的1/64但小于1G。
JVM最大分配的內(nèi)存由-Xmx指定，默認(rèn)是物理內(nèi)存的1/4但小于1G。
默認(rèn)空余堆內(nèi)存小于40%時，JVM就會增大堆直到-Xmx的最大限制，可以由-XX:MinHeapFreeRatio=指定。
默認(rèn)空余堆內(nèi)存大于70%時，JVM會減少堆直到-Xms的最小限制，可以由-XX:MaxHeapFreeRatio=指定。
服務(wù)器一般設(shè)置-Xms、-Xmx相等以避免在每次GC 后調(diào)整堆的大小，所以上面的兩個參數(shù)沒啥用。?
2.基本收集算法
-
復(fù)制
：將堆內(nèi)分成兩個相同空間，從根(ThreadLocal的對象，靜態(tài)對象）開始訪問每一個關(guān)聯(lián)的活躍對象，將空間A的活躍對象全部復(fù)制到空間B，然后一次性回收整個空間A。
因為只訪問活躍對象，將所有活動對象復(fù)制走之后就清空整個空間，不用去訪問死對象，所以遍歷空間的成本較小，但需要巨大的復(fù)制成本和較多的內(nèi)存。 - 標(biāo)記清除(mark-sweep)： 收集器先從根開始訪問所有活躍對象，標(biāo)記為活躍對象。然后再遍歷一次整個內(nèi)存區(qū)域，把所有沒有標(biāo)記活躍的對象進(jìn)行回收處理。該算法遍歷整個空間的成本較大暫停時間隨空間大小線性增大，而且整理后堆里的碎片很多。
- 標(biāo)記整理(mark-sweep-compact)： 綜合了上述兩者的做法和優(yōu)點，先標(biāo)記活躍對象，然后將其合并成較大的內(nèi)存塊。
??? 可見，沒有免費的午餐，無論采用復(fù)制還是標(biāo)記清除算法，自動的東西都要付出很大的性能代價。
3.分代
??? 分代是Java垃圾收集的一大亮點，根據(jù)對象的生命周期長短，把堆分為3個代：Young，Old和Permanent，根據(jù)不同代的特點采用不同的收集算法，揚長避短也。
Young(Nursery)，年輕代
。研究表明大部分對象都是朝生暮死，隨生隨滅的。因此所有收集器都為年輕代選擇了復(fù)制算法。
??? 復(fù)制算法優(yōu)點是只訪問活躍對象，缺點是復(fù)制成本高。因為年輕代只有少量的對象能熬到垃圾收集，因此只需少量的復(fù)制成本。而且復(fù)制收集器只訪問活躍對象，對那些占了最大比率的死對象視而不見，充分發(fā)揮了它遍歷空間成本低的優(yōu)點。
??? Young的默認(rèn)值為4M，隨堆內(nèi)存增大，約為1/15，JVM會根據(jù)情況動態(tài)管理其大小變化。
??? -XX:NewRatio= 參數(shù)可以設(shè)置Young與Old的大小比例，-server時默認(rèn)為1:2，但實際上young啟動時遠(yuǎn)低于這個比率？如果信不過JVM，也可以用-Xmn硬性規(guī)定其大小，有文檔推薦設(shè)為Heap總大小的1/4。
????Young的大小非常非常重要，見“后面暫停時間優(yōu)先收集器”的論述。
??? Young里面又分為3個區(qū)域，一個Eden，所有新建對象都會存在于該區(qū)，兩個Survivor區(qū)，用來實施復(fù)制算法。每次復(fù)制就是將Eden和第一塊 Survior的活對象復(fù)制到第2塊，然后清空Eden與第一塊Survior。Eden與Survivor的比例由 -XX:SurvivorRatio=設(shè)置，默認(rèn)為32。Survivio大了會浪費，小了的話，會使一些年輕對象潛逃到老人區(qū)，引起老人區(qū)的不安，但這 個參數(shù)對性能并不重要。?
Old(Tenured)，年老代 。年輕代的對象如果能夠挺過數(shù)次收集，就會進(jìn)入老人區(qū)。老人區(qū)使用標(biāo)記整理算 法。因為老人區(qū)的對象都沒那么容易死的，采用復(fù)制算法就要反復(fù)的復(fù)制對象，很不合算，只好采用標(biāo)記清理算法，但標(biāo)記清理算法其實也不輕松，每次都要遍歷區(qū) 域內(nèi)所有對象，所以還是沒有免費的午餐啊。
-XX:MaxTenuringThreshold=設(shè)置熬過年輕代多少次收集后移入老人區(qū)，CMS中默認(rèn)為0，熬過第一次GC就轉(zhuǎn)入，可以用-XX:+PrintTenuringDistribution查看。
Permanent，持久代。 裝載Class信息等基礎(chǔ)數(shù)據(jù)，默認(rèn)64M，如果是類很多很多的服務(wù)程序，需要加 大其設(shè)置-XX:MaxPermSize=，否則它滿了之后會引起fullgc()或Out of Memory。 注意Spring，Hibernate這類喜歡AOP動態(tài)生成類的框架需要更多的持久代內(nèi)存。
4.minor/major collection
??? 每個代滿了之后都會促發(fā)collection，（另外Concurrent Low Pause Collector默認(rèn)在老人區(qū)68%的時候促發(fā))。GC用較高的頻率對young進(jìn)行掃描和回收，這種叫做minor collection
。
而因為成本關(guān)系對Old的檢查回收頻率要低很多，同時對Young和Old的收集稱為major collection。
??? System.gc()會引發(fā)major collection，使用-XX:+DisableExplicitGC禁止它，或設(shè)為CMS并發(fā)-XX:+ExplicitGCInvokesConcurrent。
5.小結(jié)
Young -- minor collection -- 復(fù)制算法
Old(Tenured) -- major colletion -- 標(biāo)記清除/標(biāo)記整理算法
三、收集器
1.古老的串行收集器(Serial Collector)
??? 使用 -XX:+UseSerialGC，策略為年輕代串行復(fù)制，年老代串行標(biāo)記整理。
2.吞吐量優(yōu)先的并行收集器(Throughput Collector)
??? 使用 -XX:+UseParallelGC ，也是JDK5 -server的默認(rèn)值。策略為：
??? 1.年輕代暫停應(yīng)用程序，多個垃圾收集線程并行的復(fù)制收集，線程數(shù)默認(rèn)為CPU個數(shù)，CPU很多時，可用–XX:ParallelGCThreads=減少線程數(shù)。
??? 2.年老代暫停應(yīng)用程序，與串行收集器一樣，單垃圾收集線程標(biāo)記整理。
??? 所以需要2+的CPU時才會優(yōu)于串行收集器，適用于后臺處理，科學(xué)計算。
??? 可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 來調(diào)整GC的時間。
3.暫停時間優(yōu)先的并發(fā)收集器(Concurrent Low Pause Collector-CMS )
??? 前面說了這么多，都是為了這節(jié)做鋪墊......
??? 使用-XX:+UseConcMarkSweepGC，策略為：
??? 1.年輕代同樣是暫停應(yīng)用程序，多個垃圾收集線程并行的復(fù)制收集。
????2.年老代則只有兩次短暫停，其他時間應(yīng)用程序與收集線程并發(fā)的清除。
3.1 年老代詳述
??? 并行(Parallel)與并發(fā)(Concurrent)僅一字之差，并行指多條垃圾收集線程并行，并發(fā)指用戶線程與垃圾收集線程并發(fā)，程序在繼續(xù)運行，而垃圾收集程序運行于另一個個CPU上。
????并發(fā)收集一開始會很短暫的停止一次所有線程來開始初始標(biāo)記根對象，然后標(biāo)記線程與應(yīng)用線程一起并發(fā)運行，最后又很短的暫停一次，多線程 并行 的重新標(biāo)記之前可能因為并發(fā)而漏掉的對象，然后就開始與應(yīng)用程序并發(fā)的清除過程。可見，最長的兩個遍歷過程都是與應(yīng)用程序并發(fā)執(zhí)行的，比以前的串行算法改進(jìn)太多太多了！！！
??? 串行標(biāo)記清除是等年老代滿了再開始收集的，而并發(fā)收集因為要與應(yīng)用程序一起運行，如果滿了才收集，應(yīng)用程序就無內(nèi)存可用，所以系統(tǒng)默認(rèn)68%滿的時候就開 始收集。內(nèi)存已設(shè)得較大，吃內(nèi)存又沒有這么快的時候，可以用-XX:CMSInitiatingOccupancyFraction=恰當(dāng)增大該比率。
3.2 年輕代詳述
???可惜對年輕代的復(fù)制收集，依然必須停止所有應(yīng)用程序線程，原理如此，只能靠多CPU，多收集線程并發(fā)來提高收集速度，但除非你的Server 獨占整臺服務(wù)器，否則如果服務(wù)器上本身還有很多其他線程時，切換起來速度就..... 所以，搞到最后，暫停時間的瓶頸就落在了年輕代的復(fù)制算法上。
??? 因此Young的大小設(shè)置挺重要的，大點就不用頻繁GC，而且增大GC的間隔后，可以讓多點對象自己死掉而不用復(fù)制了。但Young增大時，GC造成的停 頓時間攀升得非常恐怖，比如在我的機器上，默認(rèn)8M的Young，只需要幾毫秒的時間，64M就升到90毫秒，而升到256M時，就要到300毫秒了，峰 值還會攀到恐怖的800ms。誰叫復(fù)制算法，要等Young滿了才開始收集，開始收集就要停止所有線程呢。
3.3 持久代
可設(shè)置-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled，使CMS收集持久代的類，而不是fullgc，netbeans5.5 performance文檔的推薦。
4.增量(train算法)收集器(Incremental Collector)
已停止維護(hù)，–Xincgc選項默認(rèn)轉(zhuǎn)為并發(fā)收集器。
四、暫停時間顯示
?加入下列參數(shù) (請將PrintGC和Details中間的空格去掉，CSDN很怪的認(rèn)為是禁止字句）?
-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秒發(fā)生了Minor的垃圾收集，前一段數(shù)據(jù)針對新生區(qū)，從7994k整理為0k，新生區(qū)總大小為8128k，程序暫停了12ms，而后一段數(shù)據(jù)針對整個堆。
對于年老代的收集，暫停發(fā)生在下面兩個階段，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]
再加兩個參數(shù) -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime對暫停時間看得更清晰。
五、真正不停的BEA JRockit 與Sun RTS2.0
? ?Bea的
JRockit 5.0 R27
的特色之一是動態(tài)決定的垃圾收集策略，用戶可以決定自己關(guān)心的是吞吐量，暫停時間還是確定的暫停時間，再由JVM在運行時動態(tài)決定、改變改變垃圾收集策略。
???
?? 它的Deterministic GC的選項是-Xgcprio: deterministic，號稱可以把暫停可以控制在10-30毫秒，非常的牛，一句Deterministic道盡了RealTime的真諦。 不過細(xì)看一下文檔，30ms的測試環(huán)境是1 GB heap 和 平均 ?30% 的活躍對象(也就是300M)活動對象，2?個 Xeon 3.6 GHz? 4G內(nèi)存?，或者是4 個Xeon 2.0 GHz，8G內(nèi)存。
? 最可惜JRockt的license很奇怪，雖然平時使用免費，但這個30ms的選項就需要購買整個Weblogic Real Time Server的license。?
??其他免費選項，有：
-
-Xgcprio:pausetime -Xpausetarget=210ms?
??因為免費，所以最低只能設(shè)置到200ms pause target。?200ms是Sun認(rèn)為Real-Time的分界線。 -
-Xgc:gencon
普通的并發(fā)做法，效率也不錯。
??JavaOne2007上有Sun的 Java Real-Time System 2.0 的介紹，RTS2.0基于JDK1.5，在Real-Time? Garbage Collctor上又有改進(jìn)，但還在beta版狀態(tài)，只供給OEM，更怪。
六、JDK 6.0的改進(jìn)
因為JDK5.0在Young較大時的表現(xiàn)還是不夠讓人滿意，又繼續(xù)看JDK6.0的改進(jìn)，結(jié)果稍稍失望，不涉及我最頭痛的年輕代復(fù)制收集改良。
1.年老代的標(biāo)識-清除收集，并行執(zhí)行標(biāo)識
? JDK5.0只開了一條收集進(jìn)程與應(yīng)用線程并發(fā)標(biāo)識，而6.0可以開多條收集線程來做標(biāo)識，縮短標(biāo)識老人區(qū)所有活動對象的時間。
2.加大了Young區(qū)的默認(rèn)大小
默認(rèn)大小從4M加到16M，從堆內(nèi)存的1/15增加到1/7
3.System.gc()可以與應(yīng)用程序并發(fā)執(zhí)行
使用-XX:+ExplicitGCInvokesConcurrent 設(shè)置
七、小結(jié)
1. JDK5.0/6.0
對于服務(wù)器應(yīng)用，我們使用Concurrent Low Pause Collector，對年輕代，暫停時多線程并行復(fù)制收集；對年老代，收集器與應(yīng)用程序并行標(biāo)記--整理收集，以達(dá)到盡量短的垃圾收集時間。
本著沒有深刻測試前不要胡亂優(yōu)化的宗旨，命令行屬性只需簡單寫為：
-server?-Xms<heapsize>M?-Xmx<heapsize>M?-XX:
+
UseConcMarkSweepGC??-XX:+PrintGC Details??-XX:+PrintGCTimeStamps
然后要根據(jù)應(yīng)用的情況，在測試軟件輔助可以下看看有沒有JVM的默認(rèn)值和自動管理做的不夠的地方可以調(diào)整，如-xmn 設(shè)Young的大小，-XX:MaxPermSize設(shè)持久代大小等。
2. JRockit 6.0?R27.2
但因為JDK5的測試結(jié)果實在不能滿意，后來又嘗試了JRockit，總體效果要好些。
?JRockit的特點是動態(tài)垃圾收集器是根據(jù)用戶關(guān)心的特征動態(tài)決定收集算法的，參數(shù)如下
?-Xms<heapsize>M?-Xmx<heapsize>M
-Xgcprio
:pausetime
?-Xpausetarget
=
200ms -XgcReport -XgcPause -Xverbose:memory
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
