作者：江南白衣，最新版鏈接：http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx，版權所有，轉載請保留原文鏈接。
原本想把題目更簡單的定為--《不要停》的，但還是自己YY一下就算了。
Java開發(fā)Server最大的障礙，就是JDK1.4版之前的的串行垃圾收集機制會引起長時間的服務暫停，明白原理后，想想那些用JDK1.3寫Server的先輩，不得不后怕。
好在JDK1.4已開始支持多線程并行的后臺垃圾收集算法，JDK5.0則優(yōu)化了默認值的設置。
一、參考資料：
二、基本概念
1、堆(Heap)
JVM管理的內存叫堆。在32Bit操作系統(tǒng)上有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 后調整堆的大小，所以上面的兩個參數(shù)沒啥用。
2.基本收集算法
可見，沒有免費的午餐，無論采用復制還是標記清除算法，自動的東西都要付出很大的性能代價。
3.分代
分代是Java垃圾收集的一大亮點，根據(jù)對象的生命周期長短，把堆分為3個代：Young，Old和Permanent，根據(jù)不同代的特點采用不同的收集算法，揚長避短也。
Young(Nursery)，年輕代。研究表明大部分對象都是朝生暮死，隨生隨滅的。因此所有收集器都為年輕代選擇了復制算法。
復制算法優(yōu)點是只訪問活躍對象，缺點是復制成本高。因為年輕代只有少量的對象能熬到垃圾收集，因此只需少量的復制成本。而且復制收集器只訪問活躍對象，對那些占了最大比率的死對象視而不見，充分發(fā)揮了它遍歷空間成本低的優(yōu)點。
Young的默認值為4M，隨堆內存增大，約為1/15，JVM會根據(jù)情況動態(tài)管理其大小變化。
-XX:NewRatio= 參數(shù)可以設置Young與Old的大小比例，-server時默認為1:2，但實際上young啟動時遠低于這個比率？如果信不過JVM，也可以用-Xmn硬性規(guī)定其大小，有文檔推薦設為Heap總大小的1/4。
Young的大小非常非常重要，見“后面暫停時間優(yōu)先收集器”的論述。
Young里面又分為3個區(qū)域，一個Eden，所有新建對象都會存在于該區(qū)，兩個Survivor區(qū)，用來實施復制算法。每次復制就是將Eden和第一塊Survior的活對象復制到第2塊，然后清空Eden與第一塊Survior。Eden與Survivor的比例由-XX:SurvivorRatio=設置，默認為32。Survivio大了會浪費，小了的話，會使一些年輕對象潛逃到老人區(qū)，引起老人區(qū)的不安，但這個參數(shù)對性能并不重要。
Old(Tenured)，年老代。年輕代的對象如果能夠挺過數(shù)次收集，就會進入老人區(qū)。老人區(qū)使用標記整理算法。因為老人區(qū)的對象都沒那么容易死的，采用復制算法就要反復的復制對象，很不合算，只好采用標記清理算法，但標記清理算法其實也不輕松，每次都要遍歷區(qū)域內所有對象，所以還是沒有免費的午餐啊。
-XX:MaxTenuringThreshold=設置熬過年輕代多少次收集后移入老人區(qū)，CMS中默認為0，熬過第一次GC就轉入，可以用-XX:+PrintTenuringDistribution查看。
Permanent，持久代。裝載Class信息等基礎數(shù)據(jù)，默認64M，如果是類很多很多的服務程序，需要加大其設置-XX:MaxPermSize=，否則它滿了之后會引起fullgc()或Out of Memory。 注意Spring，Hibernate這類喜歡AOP動態(tài)生成類的框架需要更多的持久代內存。
4.minor/major collection
每個代滿了之后都會促發(fā)collection，（另外Concurrent Low Pause Collector默認在老人區(qū)68%的時候促發(fā))。GC用較高的頻率對young進行掃描和回收，這種叫做minor collection。
而因為成本關系對Old的檢查回收頻率要低很多，同時對Young和Old的收集稱為major collection。
System.gc()會引發(fā)major collection，使用-XX:+DisableExplicitGC禁止它，或設為CMS并發(fā)-XX:+ExplicitGCInvokesConcurrent。
5.小結
Young -- minor collection -- 復制算法
Old(Tenured) -- major colletion -- 標記清除/標記整理算法
三、收集器
1.古老的串行收集器(Serial Collector)
使用 -XX:+UseSerialGC，策略為年輕代串行復制，年老代串行標記整理。
2.吞吐量優(yōu)先的并行收集器(Throughput Collector)
使用 -XX:+UseParallelGC ，也是JDK5 -server的默認值。策略為：
1.年輕代暫停應用程序，多個垃圾收集線程并行的復制收集，線程數(shù)默認為CPU個數(shù)，CPU很多時，可用–XX:ParallelGCThreads=減少線程數(shù)。
2.年老代暫停應用程序，與串行收集器一樣，單垃圾收集線程標記整理。
所以需要2+的CPU時才會優(yōu)于串行收集器，適用于后臺處理，科學計算。
可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 來調整GC的時間。
3.暫停時間優(yōu)先的并發(fā)收集器(Concurrent Low Pause Collector-CMS)
前面說了這么多，都是為了這節(jié)做鋪墊......
使用-XX:+UseConcMarkSweepGC，策略為：
1.年輕代同樣是暫停應用程序，多個垃圾收集線程并行的復制收集。
2.年老代則只有兩次短暫停，其他時間應用程序與收集線程并發(fā)的清除。
3.1 年老代詳述
并行(Parallel)與并發(fā)(Concurrent)僅一字之差，并行指多條垃圾收集線程并行，并發(fā)指用戶線程與垃圾收集線程并發(fā)，程序在繼續(xù)運行，而垃圾收集程序運行于另一個個CPU上。
并發(fā)收集一開始會很短暫的停止一次所有線程來開始初始標記根對象，然后標記線程與應用線程一起并發(fā)運行，最后又很短的暫停一次，多線程并行的重新標記之前可能因為并發(fā)而漏掉的對象，然后就開始與應用程序并發(fā)的清除過程?？梢?，最長的兩個遍歷過程都是與應用程序并發(fā)執(zhí)行的，比以前的串行算法改進太多太多了?。?！
串行標記清除是等年老代滿了再開始收集的，而并發(fā)收集因為要與應用程序一起運行，如果滿了才收集，應用程序就無內存可用，所以系統(tǒng)默認68%滿的時候就開始收集。內存已設得較大，吃內存又沒有這么快的時候，可以用-XX:CMSInitiatingOccupancyFraction=恰當增大該比率。
3.2 年輕代詳述
可惜對年輕代的復制收集，依然必須停止所有應用程序線程，原理如此，只能靠多CPU，多收集線程并發(fā)來提高收集速度，但除非你的Server獨占整臺服務器，否則如果服務器上本身還有很多其他線程時，切換起來速度就..... 所以，搞到最后，暫停時間的瓶頸就落在了年輕代的復制算法上。
因此Young的大小設置挺重要的，大點就不用頻繁GC，而且增大GC的間隔后，可以讓多點對象自己死掉而不用復制了。但Young增大時，GC造成的停頓時間攀升得非?？植溃热缭谖业臋C器上，默認8M的Young，只需要幾毫秒的時間，64M就升到90毫秒，而升到256M時，就要到300毫秒了，峰值還會攀到恐怖的800ms。誰叫復制算法，要等Young滿了才開始收集，開始收集就要停止所有線程呢。
3.3 持久代
可設置-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled，使CMS收集持久代的類，而不是fullgc，netbeans5.5 performance文檔的推薦。
4.增量(train算法)收集器(Incremental Collector)
已停止維護，–Xincgc選項默認轉為并發(fā)收集器。
四、暫停時間測試
加入下列參數(shù) (請將PrintGC和Details中間的空格去掉，CSDN很怪的認為是禁止字句）
會程序運行過程中將顯示如下輸出
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對暫停時間看得更清晰。
五、小結
對于服務器應用，我們使用JDK5的Concurrent Low Pause Collector，對年輕代，暫停時多線程并行復制收集；對年老代，收集器與應用程序并行標記--整理收集，以達到盡量短的垃圾收集時間。
本著沒有深刻測試前不要胡亂優(yōu)化的宗旨，命令行屬性只需簡單寫為：
然后要根據(jù)應用的情況，在測試軟件輔助可以下看看有沒有JVM的默認值和自動管理做的不夠的地方可以調整，如-xmn 設Young的大小，-XX:MaxPermSize設持久代大小等。
六、真正不停的BEA JRockit 與Sun RTS2.0
Bea的JRockit 5.0 R27 有Deterministic GC的選項-Xgcprio: deterministic，通過動態(tài)的垃圾收集機制而不是等代滿了才收集，號稱可以把暫?？梢钥刂圃?0-30毫秒，非常的牛，一句Deterministic道盡了RealTime的真諦。而JDK6如果上到2G Heap、64MYoung、4CPU、8G內存，就鐵定是幾百ms上上下下。
細看一下文檔，30ms的測試環(huán)境是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。 其他免費選項，最低只能設置到200ms pause target。
JavaOne2007上有Sun的 Java Real-Time System 2.0 的介紹，RTS2.0基于JDK1.5，在Real-Time Garbage Collctor上又有改進，但還在beta版狀態(tài)，而且也是要錢的。
七、JDK 6.0的改進
因為JDK5.0在Young較大時的表現(xiàn)還是不夠讓人滿意，又繼續(xù)看JDK6.0的改進，結果稍稍失望，不涉及我最頭痛的年輕代復制收集改良。
1.年老代的標識-清除收集，并行執(zhí)行標識
JDK5.0只開了一條收集進程與應用線程并發(fā)標識，而6.0可以開多條收集線程來做標識，縮短標識老人區(qū)所有活動對象的時間。
2.加大了Young區(qū)的默認大小
默認大小從4M加到16M，從堆內存的1/15增加到1/7
3.System.gc()可以與應用程序并發(fā)執(zhí)行
使用-XX:+ExplicitGCInvokesConcurrent 設置
