哪些內(nèi)存需要回收？
哪些內(nèi)存需要回收是垃圾回收機(jī)制第一個(gè)要考慮的問題，所謂“要回收的垃圾”無非就是那些不可能再被任何途徑使用的對(duì)象。那么如何找到這些對(duì)象？
1、引用計(jì)數(shù)法
這個(gè)算法的實(shí)現(xiàn)是，給對(duì)象中添加一個(gè)引用計(jì)數(shù)器，每當(dāng)一個(gè)地方引用這個(gè)對(duì)象時(shí)，計(jì)數(shù)器值+1；當(dāng)引用失效時(shí)，計(jì)數(shù)器值-1。任何時(shí)刻計(jì)數(shù)值為0的對(duì)象就是不可能再被使用的。這種算法使用場(chǎng)景很多，但是，Java中卻沒有使用這種算法，因?yàn)檫@種算法很難解決對(duì)象之間相互引用的情況?？匆欢未a：
/**
* 虛擬機(jī)參數(shù)：-verbose:gc
*/
public class ReferenceCountingGC
{
private Object instance = null;
private static final int _1MB = 1024 * 1024;
/** 這個(gè)成員屬性唯一的作用就是占用一點(diǎn)內(nèi)存 */
private byte[] bigSize = new byte[2 * _1MB];
public static void main(String[] args)
{
ReferenceCountingGC objectA = new ReferenceCountingGC();
ReferenceCountingGC objectB = new ReferenceCountingGC();
objectA.instance = objectB;
objectB.instance = objectA;
objectA = null;
objectB = null;
System.gc();
}
}
看下運(yùn)行結(jié)果：
[GC 4417K->288K(61440K), 0.0013498 secs]
[Full GC 288K->194K(61440K), 0.0094790 secs]
看到，兩個(gè)對(duì)象相互引用著，但是虛擬機(jī)還是把這兩個(gè)對(duì)象回收掉了，這也說明虛擬機(jī)并不是通過引用計(jì)數(shù)法來判定對(duì)象是否存活的。
2、可達(dá)性分析法
這個(gè)算法的基本思想是通過一系列稱為“GC Roots”的對(duì)象作為起始點(diǎn)，從這些節(jié)點(diǎn)向下搜索，搜索所走過的路徑稱為引用鏈，當(dāng)一個(gè)對(duì)象到GC Roots沒有任何引用鏈（即GC Roots到對(duì)象不可達(dá)）時(shí)，則證明此對(duì)象是不可用的。在Java語言中可以作為GC Roots的對(duì)象包括：
· 虛擬機(jī)棧中引用的對(duì)象
· 方法區(qū)中靜態(tài)屬性引用的對(duì)象
· 方法區(qū)中常量引用的對(duì)象
· 本地方法棧中JNI（即Native方法）引用的對(duì)象
4種引用狀態(tài)
在JDK1.2之前，Java中引用的定義很傳統(tǒng)：如果引用類型的數(shù)據(jù)中存儲(chǔ)的數(shù)值代表的是另一塊內(nèi)存的起始地址，就稱這塊內(nèi)存代表著一個(gè)引用。這種定義很純粹，但是太過于狹隘，一個(gè)對(duì)象只有被引用或者沒被引用兩種狀態(tài)。我們希望描述這樣一類對(duì)象：當(dāng)內(nèi)存空間還足夠時(shí)，則能保留在內(nèi)存中；如果內(nèi)存空間在進(jìn)行垃圾收集后還是非常緊張，則可以拋棄這些對(duì)象。很多系統(tǒng)的緩存功能都符合這樣的應(yīng)用場(chǎng)景。在JDK1.2之后，Java對(duì)引用的概念進(jìn)行了擴(kuò)充，將引用分為強(qiáng)引用、軟引用、弱引用、虛引用4種，這4種引用強(qiáng)度依次減弱。
1、強(qiáng)引用
代碼中普遍存在的類似”O(jiān)bject obj = new Object()”這類的引用，只要強(qiáng)引用還存在，垃圾收集器永遠(yuǎn)不會(huì)回收掉被引用的對(duì)象
2、軟引用
描述有些還有用但并非必需的對(duì)象。在系統(tǒng)將要發(fā)生內(nèi)存溢出異常之前，將會(huì)把這些對(duì)象列進(jìn)回收范圍進(jìn)行二次回收。如果這次回收還沒有足夠的內(nèi)存，才會(huì)拋出內(nèi)存溢出異常。Java中的類SoftReference表示軟引用
3、弱引用
描述非必需對(duì)象。被弱引用關(guān)聯(lián)的對(duì)象只能生存到下一次垃圾回收之前，垃圾收集器工作之后，無論當(dāng)前內(nèi)存是否足夠，都會(huì)回收掉只被弱引用關(guān)聯(lián)的對(duì)象。Java中的類WeakReference表示弱引用
4、虛引用
這個(gè)引用存在的唯一目的就是在這個(gè)對(duì)象被收集器回收時(shí)收到一個(gè)系統(tǒng)通知，被虛引用關(guān)聯(lián)的對(duì)象，和其生存時(shí)間完全沒關(guān)系。Java中的類PhantomReference表示虛引用
方法區(qū)回收
虛擬機(jī)規(guī)范中不要求方法區(qū)一定要實(shí)現(xiàn)垃圾回收，而且方法區(qū)中進(jìn)行垃圾回收的效率也確實(shí)比較低，但是HotSpot對(duì)方法區(qū)也是進(jìn)行回收的，主要回收的是廢棄常量和無用的類兩部分。判斷一個(gè)常量是否“廢棄常量”比較簡(jiǎn)單，只要當(dāng)前系統(tǒng)中沒有任何一處引用該常量就好了，但是要判定一個(gè)類是否“無用的類”條件就要苛刻很多，類需要同時(shí)滿足以下三個(gè)條件：
1、該類所有實(shí)例都已經(jīng)被回收，也就是說Java堆中不存在該類的任何實(shí)例
2、加載該類的ClassLoader已經(jīng)被回收
3、該類對(duì)應(yīng)的java.lang.Class對(duì)象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法
在大量使用反射、動(dòng)態(tài)代理、CGLib等ByteCode框架、動(dòng)態(tài)生成JSP以及OSGi這類頻繁自定義ClassLoader的場(chǎng)景都需要虛擬機(jī)具備類卸載功能，以保證方法區(qū)不會(huì)溢出。
垃圾回收算法
第一步考量了哪些對(duì)象進(jìn)行回收后，第二步自然是如何對(duì)對(duì)象進(jìn)行回收了。這里主要寫幾種垃圾回收算法的思想。
1、標(biāo)記-清除（Mark-Sweep）算法
這是最基礎(chǔ)的算法，標(biāo)記-清除算法就如同它的名字樣，分為“標(biāo)記”和“清除”兩個(gè)階段：首先標(biāo)記出所有需要回收的對(duì)象，標(biāo)記完成后統(tǒng)一回收所有被標(biāo)記的對(duì)象。這種算法的不足主要體現(xiàn)在效率和空間，從效率的角度講，標(biāo)記和清除兩個(gè)過程的效率都不高；從空間的角度講，標(biāo)記清除后會(huì)產(chǎn)生大量不連續(xù)的內(nèi)存碎片， 內(nèi)存碎片太多可能會(huì)導(dǎo)致以后程序運(yùn)行過程中在需要分配較大對(duì)象時(shí)，無法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)一次垃圾收集動(dòng)作。標(biāo)記-清除算法執(zhí)行過程如圖：
2、復(fù)制（Copying）算法
復(fù)制算法是為了解決效率問題而出現(xiàn)的，它將可用的內(nèi)存分為兩塊，每次只用其中一塊，當(dāng)這一塊內(nèi)存用完了，就將還存活著的對(duì)象復(fù)制到另外一塊上面，然后再把已經(jīng)使用過的內(nèi)存空間一次性清理掉。這樣每次只需要對(duì)整個(gè)半?yún)^(qū)進(jìn)行內(nèi)存回收，內(nèi)存分配時(shí)也不需要考慮內(nèi)存碎片等復(fù)雜情況，只需要移動(dòng)指針，按照順序分配即可。復(fù)制算法的執(zhí)行過程如圖：
不過這種算法有個(gè)缺點(diǎn)，內(nèi)存縮小為了原來的一半，這樣代價(jià)太高了?，F(xiàn)在的商用虛擬機(jī)都采用這種算法來回收新生代，不過研究表明1:1的比例非常不科學(xué)，因此新生代的內(nèi)存被劃分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor。每次回收時(shí)，將Eden和Survivor中還存活著的對(duì)象一次性復(fù)制到另外一塊Survivor空間上，最后清理掉Eden和剛才用過的Survivor空間。HotSpot虛擬機(jī)默認(rèn)Eden區(qū)和Survivor區(qū)的比例為8:1，意思是每次新生代中可用內(nèi)存空間為整個(gè)新生代容量的90%。當(dāng)然，我們沒有辦法保證每次回收都只有不多于10%的對(duì)象存活，當(dāng)Survivor空間不夠用時(shí)，需要依賴?yán)夏甏M(jìn)行分配擔(dān)保（Handle Promotion）。
3、標(biāo)記-整理（Mark-Compact）算法
復(fù)制算法在對(duì)象存活率較高的場(chǎng)景下要進(jìn)行大量的復(fù)制操作，效率很低。萬一對(duì)象100%存活，那么需要有額外的空間進(jìn)行分配擔(dān)保。老年代都是不易被回收的對(duì)象，對(duì)象存活率高，因此一般不能直接選用復(fù)制算法。根據(jù)老年代的特點(diǎn)，有人提出了另外一種標(biāo)記-整理算法，過程與標(biāo)記-清除算法一樣，不過不是直接對(duì)可回收對(duì)象進(jìn)行清理，而是讓所有存活對(duì)象都向一端移動(dòng)，然后直接清理掉邊界以外的內(nèi)存。標(biāo)記-整理算法的工作過程如圖：
分代收集
根據(jù)上面的內(nèi)容，用一張圖概括一下堆內(nèi)存的布局
現(xiàn)代商用虛擬機(jī)基本都采用分代收集算法來進(jìn)行垃圾回收。這種算法沒什么特別的，無非是上面內(nèi)容的結(jié)合罷了，根據(jù)對(duì)象的生命周期的不同將內(nèi)存劃分為幾塊，然后根據(jù)各塊的特點(diǎn)采用最適當(dāng)?shù)氖占惴ā４笈鷮?duì)象死去、少量對(duì)象存活的，使用復(fù)制算法，復(fù)制成本低；對(duì)象存活率高、沒有額外空間進(jìn)行分配擔(dān)保的，采用標(biāo)記-清理算法或者標(biāo)記-整理算法。
垃圾收集器
垃圾收集器就是上面講的理論知識(shí)的具體實(shí)現(xiàn)了。不同虛擬機(jī)所提供的垃圾收集器可能會(huì)有很大差別，我們使用的是HotSpot，HotSpot這個(gè)虛擬機(jī)所包含的所有收集器如圖：
上圖展示了7種作用于不同分代的收集器，如果兩個(gè)收集器之間存在連線，那說明它們可以搭配使用。虛擬機(jī)所處的區(qū)域說明它是屬于新生代收集器還是老年代收集器。多說一句，我們必須要明白一個(gè)道理：沒有最好的垃圾收集器，更加沒有萬能的收集器，只能選擇對(duì)具體應(yīng)用最合適的收集器。這也是HotSpot為什么要實(shí)現(xiàn)這么多收集器的原因。OK，下面一個(gè)一個(gè)看一下收集器：
1、Serial收集器
最基本、發(fā)展歷史最久的收集器，這個(gè)收集器是一個(gè)采用復(fù)制算法的單線程的收集器，單線程一方面意味著它只會(huì)使用一個(gè)CPU或一條線程去完成垃圾收集工作，另一方面也意味著它進(jìn)行垃圾收集時(shí)必須暫停其他線程的所有工作，直到它收集結(jié)束為止。后者意味著，在用戶不可見的情況下要把用戶正常工作的線程全部停掉，這對(duì)很多應(yīng)用是難以接受的。不過實(shí)際上到目前為止，Serial收集器依然是虛擬機(jī)運(yùn)行在Client模式下的默認(rèn)新生代收集器，因?yàn)樗?jiǎn)單而高效。用戶桌面應(yīng)用場(chǎng)景中，分配給虛擬機(jī)管理的內(nèi)存一般來說不會(huì)很大，收集幾十兆甚至一兩百兆的新生代停頓時(shí)間在幾十毫秒最多一百毫秒，只要不是頻繁發(fā)生，這點(diǎn)停頓是完全可以接受的。
2、ParNew收集器
ParNew收集器其實(shí)就是Serial收集器的多線程版本，除了使用多條線程進(jìn)行垃圾收集外，其余行為和Serial收集器完全一樣，包括使用的也是復(fù)制算法。ParNew收集器除了多線程以外和Serial收集器并沒有太多創(chuàng)新的地方，但是它卻是Server模式下的虛擬機(jī)首選的新生代收集器，其中有一個(gè)很重要的和性能無關(guān)的原因是，除了Serial收集器外，目前只有它能與CMS收集器配合工作（看圖）。CMS收集器是一款幾乎可以認(rèn)為有劃時(shí)代意義的垃圾收集器，因?yàn)樗谝淮螌?shí)現(xiàn)了讓垃圾收集線程與用戶線程基本上同時(shí)工作。ParNew收集器在單CPU的環(huán)境中絕對(duì)不會(huì)有比Serial收集器更好的效果，甚至由于線程交互的開銷，該收集器在兩個(gè)CPU的環(huán)境中都不能百分之百保證可以超越Serial收集器。當(dāng)然，隨著可用CPU數(shù)量的增加，它對(duì)于GC時(shí)系統(tǒng)資源的有效利用還是很有好處的。它默認(rèn)開啟的收集線程數(shù)與CPU數(shù)量相同，在CPU數(shù)量非常多的情況下，可以使用-XX:ParallelGCThreads參數(shù)來限制垃圾收集的線程數(shù)。
3、Parallel收集器
Parallel收集器也是一個(gè)新生代收集器，也是用復(fù)制算法的收集器，也是并行的多線程收集器，但是它的特點(diǎn)是它的關(guān)注點(diǎn)和其他收集器不同。介紹這個(gè)收集器主要還是介紹吞吐量的概念。CMS等收集器的關(guān)注點(diǎn)是盡可能縮短垃圾收集時(shí)用戶線程的停頓時(shí)間，而Parallel收集器的目標(biāo)則是打到一個(gè)可控制的吞吐量。所謂吞吐量的意思就是CPU用于運(yùn)行用戶代碼時(shí)間與CPU總消耗時(shí)間的比值，即吞吐量=運(yùn)行用戶代碼時(shí)間/（運(yùn)行用戶代碼時(shí)間+垃圾收集時(shí)間），虛擬機(jī)總運(yùn)行100分鐘，垃圾收集1分鐘，那吞吐量就是99%。另外，Parallel收集器是虛擬機(jī)運(yùn)行在Server模式下的默認(rèn)垃圾收集器。
停頓時(shí)間短適合需要與用戶交互的程序，良好的響應(yīng)速度能提升用戶體驗(yàn)；高吞吐量則可以高效率利用CPU時(shí)間，盡快完成運(yùn)算任務(wù)，主要適合在后臺(tái)運(yùn)算而不需要太多交互的任務(wù)。
虛擬機(jī)提供了-XX:MaxGCPauseMillis和-XX:GCTimeRatio兩個(gè)參數(shù)來精確控制最大垃圾收集停頓時(shí)間和吞吐量大小。不過不要以為前者越小越好，GC停頓時(shí)間的縮短是以犧牲吞吐量和新生代空間換取的。由于與吞吐量關(guān)系密切，Parallel收集器也被稱為“吞吐量?jī)?yōu)先收集器”。Parallel收集器有一個(gè)-XX:+UseAdaptiveSizePolicy參數(shù)，這是一個(gè)開關(guān)參數(shù)，這個(gè)參數(shù)打開之后，就不需要手動(dòng)指定新生代大小、Eden區(qū)和Survivor參數(shù)等細(xì)節(jié)參數(shù)了，虛擬機(jī)會(huì)根據(jù)當(dāng)親系統(tǒng)的運(yùn)行情況手機(jī)性能監(jiān)控信息，動(dòng)態(tài)調(diào)整這些參數(shù)以提供最合適的停頓時(shí)間或者最大的吞吐量。如果對(duì)于垃圾收集器運(yùn)作原理不太了解，以至于在優(yōu)化比較困難的時(shí)候，使用Parallel收集器配合自適應(yīng)調(diào)節(jié)策略，把內(nèi)存管理的調(diào)優(yōu)任務(wù)交給虛擬機(jī)去完成將是一個(gè)不錯(cuò)的選擇。
4、Serial Old收集器
Serial收集器的老年代版本，同樣是一個(gè)單線程收集器，使用“標(biāo)記-整理算法”，這個(gè)收集器的主要意義也是在于給Client模式下的虛擬機(jī)使用。
5、Parallel Old收集器
Parallel收集器的老年代版本，使用多線程和“標(biāo)記-整理”算法。這個(gè)收集器在JDK 1.6之后的出現(xiàn)，“吞吐量?jī)?yōu)先收集器”終于有了比較名副其實(shí)的應(yīng)用組合，在注重吞吐量以及CPU資源敏感的場(chǎng)合，都可以優(yōu)先考慮Parallel收集器+Parallel Old收集器的組合。
6、CMS收集器
CMS收集器是一種以獲取最短回收停頓時(shí)間為目標(biāo)的老年代收集器。目前很大一部分Java應(yīng)用集中在互聯(lián)網(wǎng)站或者B/S系統(tǒng)的服務(wù)端上，這類應(yīng)用尤其注重服務(wù)的響應(yīng)速度，希望系統(tǒng)停頓時(shí)間最短，以給用戶帶來較好的體驗(yàn)，CMS收集器就非常符合這類應(yīng)用的需求。CMS收集器從名字就能看出是基于“標(biāo)記-清除”算法實(shí)現(xiàn)的。
7、G1收集器
G1（Garbage-First）收集器是當(dāng)今收集器技術(shù)發(fā)展的最前沿成果之一，JDK 7 Update 4后開始進(jìn)入商用。在G1收集器之前的其他收集器進(jìn)行收集的范圍都是整個(gè)新生代或者老年代，而G1收集器不再是這樣，使用G1收集器時(shí)，Java堆的內(nèi)存布局就與其他收集器有很大差別，它將整個(gè)Java堆分為多個(gè)大小相等的獨(dú)立區(qū)域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，它們都是一部分Region的集合。G1收集器跟蹤各個(gè)Region里面的垃圾堆積的價(jià)值大小，在后臺(tái)維護(hù)一個(gè)優(yōu)先列表，每次根據(jù)允許的收集時(shí)間，優(yōu)先回收價(jià)值最大的Region（這也是Garbage-First名稱的由來）。這種使用Region劃分內(nèi)存空間以及有優(yōu)先級(jí)的區(qū)域回收方式，保證了G1收集器在有限的時(shí)間內(nèi)可以獲取盡可能高的收集效率。
垃圾收集器總結(jié)
來看一下對(duì)垃圾收集器的總結(jié)，列了一張表
| GC組合 | Minor GC | Full GC | 描述 |
| -XX:+UseSerialGC | Serial收集器串行回收 | Serial Old收集器串行回收 | 該選項(xiàng)可以手動(dòng)指定Serial收集器+Serial Old收集器組合執(zhí)行內(nèi)存回收 |
| -XX:+UseParNewGC | ParNew收集器并行回收 | Serial Old收集器串行回收 | 該選項(xiàng)可以手動(dòng)指定ParNew收集器+Serilal Old組合執(zhí)行內(nèi)存回收 |
| -XX:+UseParallelGC | Parallel收集器并行回收 | Serial Old收集器串行回收 | 該選項(xiàng)可以手動(dòng)指定Parallel收集器+Serial Old收集器組合執(zhí)行內(nèi)存回收 |
| -XX:+UseParallelOldGC | Parallel收集器并行回收 | Parallel Old收集器并行回收 | 該選項(xiàng)可以手動(dòng)指定Parallel收集器+Parallel Old收集器組合執(zhí)行內(nèi)存回收 |
| -XX:+UseConcMarkSweepGC | ParNew收集器并行回收 | 缺省使用CMS收集器并發(fā)回收，備用采用Serial Old收集器串行回收 | 該選項(xiàng)可以手動(dòng)指定ParNew收集器+CMS收集器+Serial Old收集器組合執(zhí)行內(nèi)存回收。優(yōu)先使用ParNew收集器+CMS收集器的組合，當(dāng)出現(xiàn)ConcurrentMode Fail或者Promotion Failed時(shí)，則采用ParNew收集器+Serial Old收集器的組合 |
| -XX:+UseConcMarkSweepGC-XX:-UseParNewGC | Serial收集器串行回收 |
| -XX:+UseG1GC | G1收集器并發(fā)、并行執(zhí)行內(nèi)存回收 | 暫無 |
GC日志
每種收集器的日志形式都是由它們自身的實(shí)現(xiàn)所決定的，換言之，每種收集器的日志格式都可以不一樣。不過虛擬機(jī)為了方便用戶閱讀，將各個(gè)收集器的日志都維持了一定的共性，就以最前面的對(duì)象間相互引用的那個(gè)類ReferenceCountingGC的代碼為例：
虛擬機(jī)參數(shù)為“-XX:+PrintGCDetails -XX:+UseSerialGC”，使用Serial+Serial Old組合進(jìn)行垃圾回收的日志
[GC [DefNew: 310K->194K(2368K), 0.0269163 secs] 310K->194K(7680K), 0.0269513 secs] [Times: user=``0.00 sys=``0.00``, real=``0.03 secs]
[GC [DefNew: 2242K->0K(2368K), 0.0018814 secs] 2242K->2241K(7680K), 0.0019172 secs] [Times: user=``0.00 sys=``0.00``, real=``0.00 secs]
[Full GC (System) [Tenured: 2241K->193K(5312K), 0.0056517 secs] 4289K->193K(7680K), [Perm : 2950K->2950K(21248K)], 0.0057094 secs] [Times: user=``0.00 sys=``0.00``, real=``0.00 secs]
Heap
def new generation total 2432K, used 43K [``0x00000000052a0000``, 0x0000000005540000``, 0x0000000006ea0000``)
eden space 2176K, 2``% used [``0x00000000052a0000``, 0x00000000052aaeb8``, 0x00000000054c0000``)
from space 256K, 0``% used [``0x00000000054c0000``, 0x00000000054c0000``, 0x0000000005500000``)
to space 256K, 0``% used [``0x0000000005500000``, 0x0000000005500000``, 0x0000000005540000``)
tenured generation total 5312K, used 193K [``0x0000000006ea0000``, 0x00000000073d0000``, 0x000000000a6a0000``)
the space 5312K, 3``% used [``0x0000000006ea0000``, 0x0000000006ed0730``, 0x0000000006ed0800``, 0x00000000073d0000``)
compacting perm gen total 21248K, used 2982K [``0x000000000a6a0000``, 0x000000000bb60000``, 0x000000000faa0000``)
the space 21248K, 14``% used [``0x000000000a6a0000``, 0x000000000a989980``, 0x000000000a989a00``, 0x000000000bb60000``)
No shared spaces configured.
|
虛擬機(jī)參數(shù)為“-XX:+PrintGCDetails -XX:+UseParNewGC”，使用ParNew+Serial Old組合進(jìn)行垃圾回收的日志
[GC [ParNew: 310K->205K(2368K), 0.0006664 secs] 310K->205K(7680K), 0.0007043 secs] [Times: user=``0.00 sys=``0.00``, real=``0.00 secs]
[GC [ParNew: 2253K->31K(2368K), 0.0032525 secs] 2253K->2295K(7680K), 0.0032911 secs] [Times: user=``0.00 sys=``0.00``, real=``0.00 secs]
[Full GC (System) [Tenured: 2264K->194K(5312K), 0.0054415 secs] 4343K->194K(7680K), [Perm : 2950K->2950K(21248K)], 0.0055105 secs] [Times: user=``0.00 sys=``0.00``, real=``0.01 secs]
Heap
par new generation total 2432K, used 43K [``0x0000000005550000``, 0x00000000057f0000``, 0x0000000007150000``)
eden space 2176K, 2``% used [``0x0000000005550000``, 0x000000000555aeb8``, 0x0000000005770000``)
from space 256K, 0``% used [``0x0000000005770000``, 0x0000000005770000``, 0x00000000057b0000``)
to space 256K, 0``% used [``0x00000000057b0000``, 0x00000000057b0000``, 0x00000000057f0000``)
tenured generation total 5312K, used 194K [``0x0000000007150000``, 0x0000000007680000``, 0x000000000a950000``)
the space 5312K, 3``% used [``0x0000000007150000``, 0x0000000007180940``, 0x0000000007180a00``, 0x0000000007680000``)
compacting perm gen total 21248K, used 2982K [``0x000000000a950000``, 0x000000000be10000``, 0x000000000fd50000``)
the space 21248K, 14``% used [``0x000000000a950000``, 0x000000000ac39980``, 0x000000000ac39a00``, 0x000000000be10000``)
No shared spaces configured.
|
虛擬機(jī)參數(shù)為“-XX:+PrintGCDetails -XX:+UseParallelGC”，使用Parallel+Serial Old組合進(jìn)行垃圾回收的日志
[GC [PSYoungGen: 4417K->288K(18688K)] 4417K->288K(61440K), 0.0007910 secs] [Times: user=``0.00 sys=``0.00``, real=``0.00 secs]
[Full GC (System) [PSYoungGen: 288K->0K(18688K)] [PSOldGen: 0K->194K(42752K)] 288K->194K(61440K) [PSPermGen: 2941K->2941K(21248K)], 0.0032663 secs] [Times: user=``0.02 sys=``0.00``, real=``0.00 secs]
Heap
PSYoungGen total 18688K, used 321K [``0x0000000034190000``, 0x0000000035660000``, 0x0000000048f90000``)
eden space 16064K, 2``% used [``0x0000000034190000``,``0x00000000341e05c0``,``0x0000000035140000``)
from space 2624K, 0``% used [``0x0000000035140000``,``0x0000000035140000``,``0x00000000353d0000``)
to space 2624K, 0``% used [``0x00000000353d0000``,``0x00000000353d0000``,``0x0000000035660000``)
PSOldGen total 42752K, used 194K [``0x000000000a590000``, 0x000000000cf50000``, 0x0000000034190000``)
object space 42752K, 0``% used [``0x000000000a590000``,``0x000000000a5c0810``,``0x000000000cf50000``)
PSPermGen total 21248K, used 2982K [``0x0000000005190000``, 0x0000000006650000``, 0x000000000a590000``)
object space 21248K, 14``% used [``0x0000000005190000``,``0x0000000005479980``,``0x0000000006650000``)
|
虛擬機(jī)參數(shù)為“-XX:+PrintGCDetails -XX:+UseConcMarkSweepGC****”，使用ParNew+CMS+Serial Old組合進(jìn)行垃圾回收的日志
[Full GC (System) [CMS: 0K->194K(62656K), 0.0080796 secs] 4436K->194K(81792K), [CMS Perm : 2941K->2940K(21248K)], 0.0081589 secs] [Times: user=``0.01 sys=``0.00``, real=``0.01 secs]
Heap
par new generation total 19136K, used 340K [``0x0000000005540000``, 0x0000000006a00000``, 0x0000000006a00000``)
eden space 17024K, 2``% used [``0x0000000005540000``, 0x0000000005595290``, 0x00000000065e0000``)
from space 2112K, 0``% used [``0x00000000065e0000``, 0x00000000065e0000``, 0x00000000067f0000``)
to space 2112K, 0``% used [``0x00000000067f0000``, 0x00000000067f0000``, 0x0000000006a00000``)
concurrent mark-sweep generation total 62656K, used 194K [``0x0000000006a00000``, 0x000000000a730000``, 0x000000000a940000``)
concurrent-mark-sweep perm gen total 21248K, used 2981K [``0x000000000a940000``, 0x000000000be00000``, 0x000000000fd40000``)
|
這四段GC日志中提煉出一些共性：
1、日志的開頭“GC”、“Full GC”表示這次垃圾收集的停頓類型，而不是用來區(qū)分新生代GC還是老年代GC的。如果有Full，則說明本次GC停止了其他所有工作線程?？吹紽ull GC的寫法是“Full GC(System)”，這說明是調(diào)用System.gc()方法所觸發(fā)的GC。
2、“GC”中接下來的“DefNew”、“ParNew”、“PSYoungGen”、“CMS”表示的是老年代垃圾收集器的名稱，“PSYoungGen”中的“PS”指的是“Parallel Scavenge”，它是Parallel收集器的全稱。
3、以第一個(gè)為例，方括號(hào)內(nèi)部的“320K->194K(2368K)”、“2242K->0K(2368K)”，指的是該區(qū)域已使用的容量->GC后該內(nèi)存區(qū)域已使用的容量(該內(nèi)存區(qū)總?cè)萘?。方括號(hào)外面的“310K->194K(7680K)”、“2242K->2241K(7680K)”則指的是GC前Java堆已使用的容量->GC后Java堆已使用的容量(Java堆總?cè)萘?。
4、還以第一個(gè)為例，再往后“0.0269163 secs”表示該內(nèi)存區(qū)域GC所占用的時(shí)間，單位是秒。最后的“[Times: user=0.00 sys=0.00 real=0.03 secs]”則更具體了，user表示用戶態(tài)消耗的CPU時(shí)間、內(nèi)核態(tài)消耗的CPU時(shí)間、操作從開始到結(jié)束經(jīng)過的鐘墻時(shí)間。后面兩個(gè)的區(qū)別是，鐘墻時(shí)間包括各種非運(yùn)算的等待消耗，比如等待磁盤I/O、等待線程阻塞，而CPU時(shí)間不包括這些耗時(shí)，但當(dāng)系統(tǒng)有多CPU或者多核的話，多線程操作會(huì)疊加這些CPU時(shí)間所以如果user或sys超過real是完全正常的。
5、“Heap”后面就列舉出堆內(nèi)存目前各個(gè)年代的區(qū)域的內(nèi)存情況
觸發(fā)GC的時(shí)機(jī)
最后總結(jié)一下什么時(shí)候會(huì)觸發(fā)一次GC，個(gè)人經(jīng)驗(yàn)看，有三種場(chǎng)景會(huì)觸發(fā)GC：
1、第一種場(chǎng)景應(yīng)該很明顯，當(dāng)年輕代或者老年代滿了，Java虛擬機(jī)無法再為新的對(duì)象分配內(nèi)存空間了，那么Java虛擬機(jī)就會(huì)觸發(fā)一次GC去回收掉那些已經(jīng)不會(huì)再被使用到的對(duì)象
2、手動(dòng)調(diào)用System.gc()方法，通常這樣會(huì)觸發(fā)一次的Full GC以及至少一次的Minor GC
3、程序運(yùn)行的時(shí)候有一條低優(yōu)先級(jí)的GC線程，它是一條守護(hù)線程，當(dāng)這條線程處于運(yùn)行狀態(tài)的時(shí)候，自然就觸發(fā)了一次GC了。這點(diǎn)也很好證明，不過要用到WeakReference的知識(shí)，后面寫WeakReference的時(shí)候會(huì)專門講到這個(gè)。
