34.對象 GC，GC屬性，影響GC的因素，GC步驟，GC算法，安全區(qū)/安全區(qū)域，新生代，老年代等介紹
34.1.GC屬性
34.2.影響GC的因素
34.3.GC步驟
34.3.1.Mark
34.3.1.1.引用計(jì)數(shù)算法（Reference Counting）
34.3.1.2.可達(dá)性分析算法（Reachability Analysis）
34.3.2.Clean Up
34.3.2.1.清除（Sweep）
34.3.2.2.復(fù)制（Copying）
34.3.2.3.整理（Compacting）
34.4.分代回收（Generational）
34.4.1.1.YOUNG 新生代
34.4.1.2.OLD 老年代
34.4.1.3.PERM 永久代
34.5.安全點(diǎn)/安全區(qū)域
34.6.垃圾收集器
34.6.1.YOUNG 新生代
34.6.1.1.Serial（-XX:+UseSerialGC）
34.6.1.2.ParNew（-XX:+UseParNewGC）
34.6.1.3.Parallel Scavenge（-XX:+UseParallelGC）
34.6.2.OLD 老年代
34.6.2.1.Serial Old
34.6.2.2.Parallel Old（-XX:+UseParallelOldGC）
34.6.2.3.CMS（-XX:+UseConcMarkSweepGC）
34.6.2.4.G1（Garbage First，-XX:+UseG1GC）
34.7.GC監(jiān)控

34.對象 GC，GC屬性，影響GC的因素，GC步驟，GC算法，安全區(qū)/安全區(qū)域，新生代，老年代等介紹

Java的一大特性就是內(nèi)存的分配和回收都是自動進(jìn)行的。當(dāng)程序規(guī)模不大時(shí)，我們完全可以不考慮內(nèi)存的使用情況。但是一旦程序的規(guī)模足夠大，對性能的要求足夠高時(shí)，了解Java垃圾收集（GC）的內(nèi)部機(jī)制并根據(jù)具體的應(yīng)用特征來調(diào)整使用的垃圾收集算法就顯得十分重要了。

34.1.GC屬性

吞吐量（Throughput）：程序運(yùn)行時(shí)間 /（程序運(yùn)行時(shí)間 + 垃圾收集時(shí)間）
延遲（Latency）：使程序盡可能少的因?yàn)槔厥斩鴷和５哪芰?br /> 足跡（Footprint)：GC運(yùn)行時(shí)使用的內(nèi)存空間
敏捷度（Promptness）：對象被標(biāo)記為死亡到對象所占內(nèi)存被回收所經(jīng)歷的時(shí)間

34.2.影響GC的因素

堆大小
堆內(nèi)對象的存活率
內(nèi)存分配速率
引用更新速率
對象的壽命

34.3.GC步驟

34.3.1.Mark

標(biāo)記階段，目的是將不可用的對象標(biāo)記出來，以便進(jìn)行后階段的回收。那么，如何判斷一個(gè)對象是否可用呢？這跟指向該對象的引用有很大的關(guān)系。因此，在具體研究對象可用性判定算法之前，讓我們先看一看Java中不同的引用類型。

Java引用類型
Java中主要有以下四種引用類型：
?強(qiáng)引用（Strong Reference）：大多數(shù)情況下使用的引用類型。如Object obj = new Object();中的obj就屬于強(qiáng)引用。被強(qiáng)引用引用的對象在任何時(shí)候都不能被回收。
?軟引用（Soft Reference）：使用SoftReference類創(chuàng)建的引用，其所引用的對象將在內(nèi)存空間不足時(shí)被回收。
?弱引用（Weak Reference）：使用WeakRe引用，不管內(nèi)存空間是否足夠，其所引用的對象都將在下一次GC時(shí)被回收。ference類創(chuàng)建的
?虛引用（Phantom Reference）：使用PhantomReference類創(chuàng)建的引用，不影響其所引用的對象的壽命，僅在被回收時(shí)收到一個(gè)系統(tǒng)通知
上述四種引用的強(qiáng)度由上至下依次減弱。可以看出，除了強(qiáng)引用，其他引用對于GC的執(zhí)行并無太大的影響。因此，以下討論中談到的引用均指強(qiáng)引用。

34.3.1.1.引用計(jì)數(shù)算法（Reference Counting）

該算法給每個(gè)對象添加一個(gè)引用計(jì)數(shù)器，當(dāng)有引用指向?qū)ο髸r(shí)，計(jì)數(shù)器加1，當(dāng)引用失效時(shí)，計(jì)數(shù)器減1。因此，當(dāng)一個(gè)對象的引用計(jì)數(shù)變?yōu)?時(shí)，就證明該對象不可用，其所占用的內(nèi)存也可以立即被釋放。

但是主流的Java虛擬機(jī)中并沒有使用這一簡單高效的算法來管理內(nèi)存，主要原因就是它無法解決循環(huán)引用（Circular）的問題。也即，當(dāng)對象A和對象B相互引用，而沒有任何其他對象指向A和B時(shí)，由于A和B的引用計(jì)數(shù)均為1（不等于0），引用計(jì)數(shù)算法將無法回收這兩個(gè)對象。

同時(shí)，該算法對引用計(jì)數(shù)的頻繁更新也會使得效率降低。

34.3.1.2.可達(dá)性分析算法（Reachability Analysis）

從一系列名為”GC Roots”的對象開始向下搜索，就可以形成若干條引用鏈。如果一個(gè)對象到”GC Roots”無任何引用鏈相連，該對象則被判定為可回收對象。

可以作為GC Roots的對象包括以下幾類：
?虛擬機(jī)棧中引用的對象
?方法區(qū)中類靜態(tài)屬性引用的對象
?方法區(qū)中常量引用的對象
?Native方法引用的對象

該算法可以很好的解決循環(huán)引用的問題。同時(shí)，對于高度變化的程序來說比引用計(jì)數(shù)法效率更高。但是，在迅速發(fā)現(xiàn)不可用的對象方面，則沒有引用計(jì)數(shù)法那么快。

34.3.2.Clean Up

清理階段。將Mark階段標(biāo)記出的不可用對象清除，釋放其所占用的內(nèi)存空間。主要有以下幾種實(shí)現(xiàn)方式。

34.3.2.1.清除（Sweep）

算法思想：遍歷堆空間，將Mark階段標(biāo)記不可用的對象清除。
不足： 效率不高；空間問題，多次清除之后會產(chǎn)生大量的內(nèi)存碎片。
適用場景：對象壽命長的內(nèi)存區(qū)域。
該算法過程如下圖所示：

34.3.2.2.復(fù)制（Copying）

算法思想：將內(nèi)存劃分為兩個(gè)區(qū)域（大小比例可調(diào)整），每次只用其中一塊，當(dāng)此塊內(nèi)存用完時(shí)，就將存活對象復(fù)制到另一塊內(nèi)存中，并對當(dāng)前塊進(jìn)行內(nèi)存回收。
優(yōu)點(diǎn)：解決了內(nèi)存碎片問題；內(nèi)存分配效率提高。每次復(fù)制后對象在堆中都是線性排列的，因此內(nèi)存分配時(shí)只需移動堆頂指針即可。
不足：如果對象的存活率較高，大量的復(fù)制操作會顯著的降低效率；內(nèi)存空間浪費(fèi)，每次都只能使用堆空間的一部分，代價(jià)高昂。
該算法過程如下圖所示：

34.3.2.3.整理（Compacting）

算法思想：將標(biāo)記的所有可用對象向內(nèi)存一端移動，然后直接清理邊界以外的內(nèi)存區(qū)域即可。
優(yōu)點(diǎn)：類似于復(fù)制算法，解決了內(nèi)存碎片問題，內(nèi)存分配效率提高；消除了復(fù)制算法對內(nèi)存空間的浪費(fèi)。
不足：難以做到并行。
該算法過程如下圖所示：

34.4.分代回收（Generational）

前面所述的Mark-Clean算法都是針對整個(gè)堆區(qū)域的，每一次GC運(yùn)行都需要對堆中所有的對象進(jìn)行遍歷。因此，隨著堆中對象數(shù)量的增多，GC的效率就會隨之下降。于是，GC對程序運(yùn)行做出如下假設(shè)：
?大多數(shù)對象都會在創(chuàng)建后不久死亡
?如果對象已存活一段時(shí)間，那它很可能會繼續(xù)存活一段時(shí)間
基于這兩個(gè)假設(shè)，GC將堆中的對象按照存活時(shí)間分為三代：Young（新生代）、Old（老年代）、Perm（永久代）。其內(nèi)存劃分示意圖如下：

34.4.1.1.YOUNG 新生代

由圖可見，新生代又可劃分為三個(gè)區(qū)域：Eden，Survivor0，Survivor1。其中，Eden區(qū)最大，新對象的內(nèi)存分配都在此區(qū)域進(jìn)行。兩個(gè)Survivor區(qū)域一個(gè)為From區(qū)，一個(gè)為To區(qū)，每次只使用其中的一個(gè)。
新生代的垃圾回收采用的是復(fù)制算法。第一次GC時(shí)，Eden區(qū)的存活對象會被復(fù)制到S0區(qū)。此后每次進(jìn)行GC時(shí)，Eden區(qū)和From區(qū)的存活對象都會被復(fù)制到To區(qū)。如果一個(gè)對象在經(jīng)歷了幾次垃圾回收后仍然存活，那么它就會被復(fù)制到Old Generation（老年代），此過程稱為Promotion。

34.4.1.2.OLD 老年代

老年代的對象是由新生代對象經(jīng)過Promotion而來，基于前面列出的假設(shè)：“如果對象已存活一段時(shí)間，那它很可能會繼續(xù)存活一段時(shí)間”，該區(qū)域的對象存活率普遍較高，因此一般采用Mark-Sweep或Mark-Compact算法。

34.4.1.3.PERM 永久代

永久代并不用來存儲從老年代經(jīng)過Promotion而來的對象，它存儲的是元數(shù)據(jù)，包括已被虛擬機(jī)加載的類信息、常量、靜態(tài)變量、方法等。該區(qū)域通常不會發(fā)生垃圾回收。

34.5.安全點(diǎn)/安全區(qū)域

在程序執(zhí)行時(shí)，并非任何時(shí)候都可以停下來進(jìn)行垃圾回收，只有到達(dá)某些特定的點(diǎn)時(shí)才能暫停，這些點(diǎn)稱為安全點(diǎn)（Safepoint）。安全點(diǎn)的設(shè)定既不能太少以致于讓GC等待時(shí)間過長，也不能太頻繁導(dǎo)致運(yùn)行時(shí)負(fù)荷增大。一般在方法調(diào)用、循環(huán)跳轉(zhuǎn)、異常跳轉(zhuǎn)處會產(chǎn)生安全點(diǎn)。
那么，如何在GC發(fā)生時(shí)讓所有的用戶線程都“跑”到最近的安全點(diǎn)上停下來呢，有以下兩種方案：
1、搶先式中斷：在GC發(fā)生時(shí)即中斷所有用戶線程，若有的線程中斷的地方不是安全點(diǎn)，則恢復(fù)該線程，讓它跑到安全點(diǎn)上再暫停。（幾乎不用）
2、主動式中斷：GC在其要開始運(yùn)行前設(shè)置一個(gè)標(biāo)志。而每個(gè)用戶線程在運(yùn)行過程中都會去主動的輪詢這個(gè)標(biāo)志，如果標(biāo)志為真則主動中斷掛起。由于輪詢標(biāo)志的地方和安全點(diǎn)重合，因此線程暫停的地方一定是安全的。
但是，以上實(shí)現(xiàn)方案有一種情況無法解決，那就是用戶線程不運(yùn)行的時(shí)候，也即處于sleep或blocked狀態(tài)的時(shí)候。由于此時(shí)線程無法輪詢中斷標(biāo)志，也就不能保證GC開始時(shí)它一定處于安全狀態(tài)。此時(shí)就需要引入安全區(qū)域（Safe Region）的概念了，它是指在一段代碼片段中，對象之間的引用關(guān)系不會發(fā)生變化。安全區(qū)域可以看做是擴(kuò)展了的安全點(diǎn)。
當(dāng)用戶線程執(zhí)行到Safe Region時(shí)，首先會標(biāo)志自己進(jìn)入了安全區(qū)域。那么，就算GC要開始時(shí)該線程處于blocked狀態(tài)，GC也可以放心的執(zhí)行垃圾回收動作了。而當(dāng)線程要離開Safe Region時(shí)，要先檢查GC是否已經(jīng)完成。如果完成了，線程就可以繼續(xù)執(zhí)行，否則需等待直到收到可以安全離開Safe Region的信號為止。

34.6.垃圾收集器

不同的虛擬機(jī)中通常有不止一種的垃圾收集器，它們實(shí)現(xiàn)了不同的垃圾收集算法。以下列舉在Sun HotSpot虛擬機(jī)中包含的垃圾收集器。

34.6.1.YOUNG 新生代

34.6.1.1.Serial（-XX:+UseSerialGC）

單線程收集器，采用復(fù)制算法。GC運(yùn)行時(shí)會暫停所有的用戶線程（STW，Stop The World）。是虛擬機(jī)運(yùn)行在Client模式下的默認(rèn)新生代收集器。

34.6.1.2.ParNew（-XX:+UseParNewGC）

Serial收集器的多線程版本，除此之外與Serial收集器幾乎完全相同。是許多運(yùn)行在Server模式下的虛擬機(jī)中首選的新生代收集器。原因之一是它是唯一能與CMS配合使用的新生代收集器。
可使用-XX:ParallelGCThreads參數(shù)指定垃圾收集的線程數(shù)。

34.6.1.3.Parallel Scavenge（-XX:+UseParallelGC）

與ParNew一樣，是使用復(fù)制算法的多線程收集器。但是不同于ParNew對縮短垃圾收集時(shí)用戶線程停頓時(shí)間的關(guān)注，Parallel Scavenge更多的是關(guān)注提高程序的吞吐量，因此常被稱為“吞吐量優(yōu)先”收集器。適用于在后臺運(yùn)算而沒有太多交互的任務(wù)。

34.6.2.OLD 老年代

34.6.2.1.Serial Old

Serial收集器的老年代版本，單線程收集器，使用Mark-Compact算法。
主要用于Client模式下的虛擬機(jī)。但在Server模式下也有兩大用途。
?在JDK1.5及之前版本中與Parallel Scavenge搭配使用
?作為CMS收集器的后備預(yù)案，在發(fā)生Concurrent Mode Failure時(shí)使用Parallel Old（-XX:+UseParallelOldGC）

34.6.2.2.Parallel Old（-XX:+UseParallelOldGC）

Parallel Scavenge的老年代版本，使用多線程和Mark-Compact算法，JDK1.6開始提供。
下圖展示了Serial和Parallel收集器的工作模式。

34.6.2.3.CMS（-XX:+UseConcMarkSweepGC）

Concurrent Mark Sweep，其工作過程可分為以下四個(gè)步驟：
?初始標(biāo)記（Initial Mark）：STW方式。標(biāo)記GC Roots直接引用的對象，時(shí)間很短。
?并發(fā)標(biāo)記（Concurrent Mark）：進(jìn)行GC Roots Tracing，標(biāo)記出所有可用對象。
?重新標(biāo)記（Remark）：對并發(fā)標(biāo)記期間因程序繼續(xù)運(yùn)行而變化的引用進(jìn)行修正，停頓時(shí)間比初始標(biāo)記長，但遠(yuǎn)比并發(fā)標(biāo)記短。
?并發(fā)清除（Concurrent Sweep）：清除不可用對象，釋放內(nèi)存。
該過程示意圖如下所示：

由圖可見，CMS執(zhí)行過程中大部分階段都是與用戶線程并行進(jìn)行的，因此用戶線程暫停時(shí)間會大大減少。但是由于CMS在進(jìn)行清理時(shí)，用戶線程也在運(yùn)行，也即此時(shí)仍然會有新的垃圾產(chǎn)生。這些垃圾稱為“浮動垃圾”（Floating Garbage）。由于“浮動垃圾”產(chǎn)生于CMS標(biāo)記階段之后，它們只能等到下一次GC時(shí)才可被回收。所以，CMS并不能等到老年代幾乎要滿了才開始垃圾收集動作，它必須預(yù)留足夠的空間給用戶線程在垃圾收集過程中使用。如果預(yù)留的空間預(yù)估不準(zhǔn)的話，就有可能出現(xiàn)以下兩種情況：
?Concurrent Mode Failure：在CMS運(yùn)行期間預(yù)留的內(nèi)存空間不夠用戶線程使用，這將觸發(fā)一次Full GC，即啟動后備預(yù)案（Serial Old收集器）來重新進(jìn)行老年代的垃圾收集。這可能會導(dǎo)致數(shù)分鐘的用戶線程停頓。
?Promotion Failure：由于CMS采用的是Mark-Sweep算法，因此在執(zhí)行了幾次GC之后老年代會存在大量的內(nèi)存碎片。如果從新生代經(jīng)過Promotion而來的對象過大，就很有可能找不到足夠的空間來分配。這也會提前觸發(fā)一次Full GC。
可使用-XX:+CMSInitiatingOccupancyFraction參數(shù)來指定在老年代空間被使用多少后觸發(fā)垃圾收集，默認(rèn)為68%。

34.6.2.4.G1（Garbage First，-XX:+UseG1GC）

之所以把G1單獨(dú)列出來，是因?yàn)樗趦?nèi)存年代劃分上不同于上面介紹的所有收集器。G1把內(nèi)存分為很多個(gè)大小相等的獨(dú)立區(qū)域（Region），新生代和老年代不再是相互隔離的，而是都由若干個(gè)非連續(xù)的Region組成。除此之外，G1收集器還有以下幾個(gè)特點(diǎn)：
?并行與并發(fā)：可大大縮短STW的時(shí)間
?分代收集：G1可以不需要其他收集器的配合而獨(dú)立管理整個(gè)GC堆，而且它能夠使用不同的方式去處理不同年代的對象
?空間整合：G1整體上采用Mark-Compact算法，消除了內(nèi)存碎片
?可預(yù)測的停頓：通過跟蹤各個(gè)Region中垃圾堆積的價(jià)值大小（可回收的空間大小以及回收所需時(shí)間的經(jīng)驗(yàn)值），G1維護(hù)了一個(gè)優(yōu)先列表，每次根據(jù)允許的收集時(shí)間，優(yōu)先對價(jià)值最大的Region進(jìn)行回收。

當(dāng)然，由于跨Region引用的存在，垃圾收集并不能真的以Region為單位進(jìn)行。對于這種情況，G1通過為每一個(gè)Region維護(hù)一個(gè)Remember Set（RSet）來避免進(jìn)行全堆掃描。RSet中記錄了其他Region中的對象指向本Region對象的引用信息。
忽略RSet的維護(hù)操作，G1的執(zhí)行過程主要分為以下四步，其與CMS的執(zhí)行過程很相似：
1、初始標(biāo)記（Initial Mark）：STW方式。標(biāo)記GC Roots直接引用的對象，并修改TAMS的值，使下一階段用戶線程并發(fā)運(yùn)行時(shí)能夠在正確可用的Region中創(chuàng)建新對象。時(shí)間很短。
2、并發(fā)標(biāo)記（Concurrent Mark）：進(jìn)行GC Roots Tracing，標(biāo)記出所有可用對象。
3、最終標(biāo)記（Final Mark）：將并發(fā)標(biāo)記期間因程序繼續(xù)運(yùn)行而變化的引用合并到RSet中。
4、篩選回收（Live Data Counting and Evacuation）：對各個(gè)Region按照回收價(jià)值和成本進(jìn)行排序，然后根據(jù)用戶所期望的GC停頓時(shí)間來制定回收計(jì)劃。
其執(zhí)行過程如下圖所示：

34.7.GC監(jiān)控

在實(shí)際應(yīng)用中，常常需要根據(jù)不同的應(yīng)用特征調(diào)整垃圾收集器的配置方案。在調(diào)整過程中，不免需要監(jiān)控各種收集器的運(yùn)行過程來進(jìn)行性能的比較。JDK自帶了一個(gè)Visual VM工具來可視化GC的執(zhí)行過程。筆者最近為了跟蹤服務(wù)器上不同垃圾收集器實(shí)現(xiàn)的性能，分析了較多的GC日志。不同收集器生成的日志格式可能不盡相同，但都有一定的共性。下面列出的是在實(shí)際應(yīng)用中使用ParNew+CMS和使用G1時(shí)產(chǎn)生的日志，從中可以很清楚的看到CMS和G1的執(zhí)行階段以及GC運(yùn)行時(shí)用戶線程暫停的時(shí)間，有興趣的朋友可以研究一下
ParNew+CMS日志

G1日志

使用的日志相關(guān)參數(shù)如下:

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC

34.8.其他注意點(diǎn)

避免顯式調(diào)用System.gc()或Runtime.getRuntime().gc()。這兩個(gè)方法只是給虛擬機(jī)一個(gè)建議，是否執(zhí)行垃圾回收還是由虛擬機(jī)來決定。
不要在finalize()方法中釋放資源。
不要嘗試在finalize()方法中逃脫垃圾回收。

總結(jié)

以上是生活随笔為你收集整理的34.对象 GC，GC属性，影响GC的因素，GC步骤，GC算法，安全区/安全区域，新生代，老年代等介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。