摘要：虛擬機(jī)所處的區(qū)域，則表示它是屬于新生代收集器還是老年代收集器。虛擬機(jī)總共運(yùn)行了分鐘，其中垃圾收集花掉分鐘，那么吞吐量就是。收集器線(xiàn)程所占用的數(shù)量為。

本文主要從GC（垃圾回收）的角度試著對(duì)jvm中的內(nèi)存分配策略與相應(yīng)的垃圾收集器做一個(gè)介紹。

注：還是老規(guī)矩，本著能畫(huà)圖就不BB原則，盡量將各知識(shí)點(diǎn)通過(guò)思維導(dǎo)圖或者其他模型圖的方式進(jìn)行說(shuō)明。文字僅記錄額外的思考與心得，以及其他特殊情況

本部分的回答主要圍繞 哪些內(nèi)存需要回收？什么時(shí)候回收？以及如何回收？這三個(gè)問(wèn)題來(lái)進(jìn)行介紹。

由上圖可知，只有堆區(qū)和靜態(tài)區(qū)，運(yùn)行時(shí)才能知道創(chuàng)建的對(duì)象信息，所以垃圾收集器所需要關(guān)注的內(nèi)存也就集中于這兩個(gè)部分了。

不可能再被任何途徑使用（對(duì)象已死）

主流對(duì)象存過(guò)判定算法分為如下兩種：

引用計(jì)數(shù)算法

可達(dá)性分析算法

在 java 中引用分為強(qiáng)軟弱虛四種形式，

最常見(jiàn)的就是強(qiáng)引用，比如類(lèi)似Object obj = new Object()這種。

軟引用通過(guò) “SoftReference” 來(lái)實(shí)現(xiàn)

弱引用通過(guò) “WeakReference” 來(lái)實(shí)現(xiàn)

弱引用通過(guò) “PhantomReference” 來(lái)實(shí)現(xiàn)

在方法區(qū)中，垃圾收集遠(yuǎn)不像堆區(qū)那么頻繁和高效。我們聚焦于兩部分內(nèi)容，廢棄常量和無(wú)用的類(lèi)。

針對(duì)是否對(duì)類(lèi)進(jìn)行回收，HotSpot 虛擬機(jī)提供了 -Xnoclassgc 參數(shù)進(jìn)行控制

針對(duì)類(lèi)加載和卸載信息，可以使用 -verbose:class 以及 -XX:+TraceClassLoading、-XX:TraceClassUnLoading

注：-verbose:class 以及 -XX:+TraceClassLoading 可以用在Product版的虛擬機(jī)中。-XX:+TraceClassUnLoading 參數(shù)需要 FastDebug 版的虛擬機(jī)支持。

其實(shí)如何回收也是具體的垃圾收集器該干的的事。但是各個(gè)平臺(tái)的虛擬機(jī)操作內(nèi)存的方法又各不相同。所以這部分先站在一個(gè)略宏觀的角度討論下關(guān)于垃圾回收的幾種常見(jiàn)算法。

傳統(tǒng)的復(fù)制算法由于將內(nèi)存劃分為了兩半，導(dǎo)致同一時(shí)間內(nèi)存的可用率只有50%，這顯然是難以接受的。
所以也早就有了機(jī)智的前輩對(duì)此方法進(jìn)行了改進(jìn)，接下來(lái)就來(lái)介紹下 HotSpot 虛擬機(jī)中是如何改進(jìn)的~

復(fù)制收集算法在對(duì)象存活率較高的時(shí)候，就要進(jìn)行較多的復(fù)制操作，效率將會(huì)變低。更關(guān)鍵的是，如果不想浪費(fèi)50%的控件，就需要有額外的空間進(jìn)行分配擔(dān)保，以應(yīng)對(duì)被使用的內(nèi)存中所有對(duì)象都100%存活的極端情況。

所以針對(duì)老年代的特點(diǎn)，一般更傾向使用類(lèi)似“標(biāo)記-整理”而非“復(fù)制收集”這樣的算法。

前面從理論上介紹了對(duì)象存活的判定方法和垃圾收集算法的思想，但是具體實(shí)現(xiàn)的過(guò)程中，也才會(huì)發(fā)現(xiàn)一些在理論思考時(shí)不會(huì)注意的點(diǎn)。

通過(guò)一組稱(chēng)為 OopMap 的數(shù)據(jù)結(jié)構(gòu)來(lái)達(dá)到目的：

在類(lèi)加載完成的時(shí)候，HotSpot 將對(duì)象內(nèi)數(shù)據(jù)類(lèi)型及其偏移量記錄下來(lái)

JIT 編譯過(guò)程中也在特定的位置記錄下棧和寄存器中哪些位置使引用

通過(guò)這種事前約定記錄位置的方法，實(shí)現(xiàn)快速遍歷根節(jié)點(diǎn)引用

安全點(diǎn)的由來(lái)本身也是為了解決一個(gè)難題而產(chǎn)生的：

不同的廠(chǎng)商，不同版本的虛擬機(jī)所提供的垃圾收集器差別很大，為了方便討論，這里以 JDK 1.7 Update 14 為基礎(chǔ)進(jìn)行討論。

上圖展示了7種作用于不同分代的收集器，如果兩個(gè)收集器之間存在連線(xiàn)，就說(shuō)明它們可以搭配使用。虛擬機(jī)所處的區(qū)域，則表示它是屬于新生代收集器還是老年代收集器。

ParNew 默認(rèn)開(kāi)啟的垃圾收集器線(xiàn)程數(shù)就是CPU數(shù)量，可通過(guò)-XX：parallelGCThreads參數(shù)來(lái)限制收集器線(xiàn)程數(shù)

另：
從 ParNew 收集器開(kāi)始，后續(xù)還有幾款并發(fā)和并行收集器。這里解釋一下這兩個(gè)名詞：并發(fā)和并行。這兩個(gè)名詞都是并發(fā)編程中的概念，在談?wù)摾占鞯纳舷挛恼Z(yǔ)境中，它們可以解釋如下：

并行（Parallel）：指多條垃圾收集線(xiàn)程并行工作，但此時(shí)用戶(hù)線(xiàn)程仍處于等待狀態(tài)。

并發(fā)（Concurrent）：指用戶(hù)線(xiàn)程與垃圾收集線(xiàn)程同時(shí)執(zhí)行（但不一定是并行的，可能會(huì)交替執(zhí)行），用戶(hù)程序在繼續(xù)運(yùn)行，而垃圾收集程序運(yùn)行于另一個(gè)CPU上。

提供了兩個(gè)參數(shù)來(lái)精確控制吞吐量：

最大垃圾收集器停頓時(shí)間（-XX：MaxGCPauseMillis 大于0的毫秒數(shù)，停頓時(shí)間小了就要犧牲相應(yīng)的吞吐量和新生代空間），

設(shè)置吞吐量大?。?XX：GCTimeRatio 大于0小于100的整數(shù)，默認(rèn)99，也就是允許最大1%的垃圾回收時(shí)間）。
　　

還有一個(gè)參數(shù)表示自適應(yīng)調(diào)節(jié)策略（GC Ergonomics）（-XX：UseAdaptiveSizePolicy）。就不用手動(dòng)設(shè)置新生代大?。?Xmn）、Eden和Survivor區(qū)的比例（-XX：SurvivorRatio）晉升老年代對(duì)象大小（-XX：PretenureSizeThreshold），會(huì)根據(jù)當(dāng)前系統(tǒng)的運(yùn)行情況手機(jī)監(jiān)控信息，動(dòng)態(tài)調(diào)整停頓時(shí)間和吞吐量大小。也是其與PreNew收集器的一個(gè)重要區(qū)別，也是其無(wú)法與CMS收集器搭配使用的原因（CMS收集器盡可能地縮短垃圾收集時(shí)用戶(hù)線(xiàn)程的停頓時(shí)間，以提升交互體驗(yàn)）。

另：所謂吞吐量就是CPU用于運(yùn)行用戶(hù)代碼的時(shí)間與CPU總消耗時(shí)間的比值，即吞吐量 = 運(yùn)行用戶(hù)代碼時(shí)間 / （運(yùn)行用戶(hù)代碼時(shí)間 + 垃圾收集時(shí)間）。

虛擬機(jī)總共運(yùn)行了100分鐘，其中垃圾收集花掉1分鐘，那么吞吐量就是99%。

（圖畫(huà)錯(cuò)了，老年代應(yīng)該是并行收集才對(duì)）

CMS收集器是基于“標(biāo)記-清除”算法實(shí)現(xiàn)的，整個(gè)收集過(guò)程大致分為4個(gè)步驟：
①.初始標(biāo)記(CMS initial mark)
②.并發(fā)標(biāo)記(CMS concurrenr mark)
③.重新標(biāo)記(CMS remark)
④.并發(fā)清除(CMS concurrent sweep)

其中初始標(biāo)記、重新標(biāo)記這兩個(gè)步驟任然需要停頓其他用戶(hù)線(xiàn)程（Stop The World）。
初始標(biāo)記僅僅只是標(biāo)記出 GC ROOTS 能直接關(guān)聯(lián)到的對(duì)象，速度很快，并發(fā)標(biāo)記階段是進(jìn)行 GC ROOTS 根搜索算法階段，會(huì)判定對(duì)象是否存活。而重新標(biāo)記階段則是為了修正并發(fā)標(biāo)記期間，因用戶(hù)程序繼續(xù)運(yùn)行而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對(duì)象的標(biāo)記記錄，這個(gè)階段的停頓時(shí)間會(huì)被初始標(biāo)記階段稍長(zhǎng)，但比并發(fā)標(biāo)記階段要短。

由于整個(gè)過(guò)程中耗時(shí)最長(zhǎng)的并發(fā)標(biāo)記和并發(fā)清除過(guò)程中，收集器線(xiàn)程都可以與用戶(hù)線(xiàn)程一起工作，所以整體來(lái)說(shuō)，CMS收集器的內(nèi)存回收過(guò)程是與用戶(hù)線(xiàn)程一起并發(fā)執(zhí)行的。

關(guān)于CMS的三個(gè)缺點(diǎn)，這里有更詳細(xì)的解釋說(shuō)明：

CMS收集器對(duì)CPU資源非常敏感。在并發(fā)（并發(fā)標(biāo)記、并發(fā)清除）階段，雖然不會(huì)導(dǎo)致用戶(hù)線(xiàn)程停頓，但是會(huì)占用CPU資源而導(dǎo)致應(yīng)用程序變慢，總吞吐量下降。CMS默認(rèn)啟動(dòng)的回收線(xiàn)程數(shù)是：(CPU數(shù)量+3) / 4。收集器線(xiàn)程所占用的CPU數(shù)量為：（CPU+3）/4=0.25+3/（4*CPU）。因此這時(shí)垃圾收集器始終不會(huì)占用少于25%的CPU，因此當(dāng)進(jìn)行并發(fā)階段時(shí)，雖然用戶(hù)線(xiàn)程可以跑，但是很緩慢，特別是雙核CPU的時(shí)候，已經(jīng)占用了5/8的CPU，吞吐量會(huì)很低。為了解決這種情況，產(chǎn)生了“增量式并發(fā)收集器”（Incremental Concurrent Mark Sweep/i-CMS）。就是采用搶占方式來(lái)模擬多任務(wù)機(jī)制，就是在并發(fā)（并發(fā)標(biāo)記、并發(fā)清除）階段，讓GC線(xiàn)程、用戶(hù)線(xiàn)程交替執(zhí)行，盡量減少GC線(xiàn)程獨(dú)占CPU，這樣垃圾收集過(guò)程更長(zhǎng)，但是對(duì)用戶(hù)程序影響小一些。實(shí)際上i-CMS效果很一般，目前已經(jīng)被聲明為“deprecated”。

CMS收集器無(wú)法處理浮動(dòng)垃圾，可能出現(xiàn)“Concurrent Mode Failure“，失敗后而導(dǎo)致另一次Full  GC的產(chǎn)生。由于CMS并發(fā)清理階段用戶(hù)線(xiàn)程還在運(yùn)行，伴隨程序的運(yùn)行自熱會(huì)有新的垃圾不斷產(chǎn)生，這一部分垃圾出現(xiàn)在標(biāo)記過(guò)程之后，CMS無(wú)法在本次收集中處理它們，只好留待下一次GC時(shí)將其清理掉。這一部分垃圾稱(chēng)為“浮動(dòng)垃圾”。也是由于在垃圾收集階段用戶(hù)線(xiàn)程還需要運(yùn)行，即需要預(yù)留足夠的內(nèi)存空間給用戶(hù)線(xiàn)程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿(mǎn)了再進(jìn)行收集，需要預(yù)留一部分內(nèi)存空間提供并發(fā)收集時(shí)的程序運(yùn)作使用。在默認(rèn)設(shè)置下，CMS收集器在老年代使用了68%的空間時(shí)就會(huì)被激活，也可以通過(guò)參數(shù)-XX:CMSInitiatingOccupancyFraction的值來(lái)提高觸發(fā)百分比，以降低內(nèi)存回收次數(shù)提高性能。JDK1.6中，CMS收集器的啟動(dòng)閾值已經(jīng)提升到92%。要是CMS運(yùn)行期間預(yù)留的內(nèi)存無(wú)法滿(mǎn)足程序其他線(xiàn)程需要，就會(huì)出現(xiàn)“Concurrent Mode Failure”失敗，這時(shí)候虛擬機(jī)將啟動(dòng)后備預(yù)案：臨時(shí)啟用Serial Old收集器來(lái)重新進(jìn)行老年代的垃圾收集，這樣停頓時(shí)間就很長(zhǎng)了。所以說(shuō)參數(shù)-XX:CMSInitiatingOccupancyFraction設(shè)置的過(guò)高將會(huì)很容易導(dǎo)致“Concurrent Mode Failure”失敗，性能反而降低。

最后一個(gè)缺點(diǎn)，CMS是基于“標(biāo)記-清除”算法實(shí)現(xiàn)的收集器，使用“標(biāo)記-清除”算法收集后，會(huì)產(chǎn)生大量碎片?？臻g碎片太多時(shí)，將會(huì)給對(duì)象分配帶來(lái)很多麻煩。比如說(shuō)大對(duì)象，內(nèi)存空間找不到連續(xù)的空間來(lái)分配不得不提前觸發(fā)一次Full  GC。為了解決這個(gè)問(wèn)題，CMS收集器提供了一個(gè)-XX:UseCMSCompactAtFullCollection開(kāi)關(guān)參數(shù)，用于在Full  GC之后增加一個(gè)內(nèi)存碎片的合并整理過(guò)程，但是內(nèi)存整理過(guò)程是無(wú)法并發(fā)的，因此解決了空間碎片問(wèn)題，卻使停頓時(shí)間變長(zhǎng)。還可通過(guò)-XX:CMSFullGCBeforeCompaction參數(shù)設(shè)置執(zhí)行多少次不壓縮的Full  GC之后，跟著來(lái)一次碎片整理過(guò)程（默認(rèn)值是0，表示每次進(jìn)入Full GC時(shí)都進(jìn)行碎片整理）。

G1收集器之所以能建立可預(yù)測(cè)的停頓時(shí)間模型，是因?yàn)樗梢杂杏?jì)劃地避免在整個(gè)Java堆中進(jìn)行全區(qū)域的垃圾收集。

在G1之前的其他收集器進(jìn)行收集的范圍都是整個(gè)新生代或者老年代，而G1不再是這樣。使用G1收集器時(shí)，Java堆的內(nèi)存布局與就與其他收集器有很大差別，它將整個(gè)Java堆劃分為多個(gè)大小相等的獨(dú)立區(qū)域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，它們都是一部分Region（不需要連續(xù)）的集合。G1跟蹤各個(gè)Region里面的垃圾堆積的價(jià)值大?。ɑ厥账@得的空間大小以及回收所需時(shí)間的經(jīng)驗(yàn)值），在后臺(tái)維護(hù)一個(gè)優(yōu)先列表，每次根據(jù)允許的收集時(shí)間，優(yōu)先回價(jià)值最大的Region（這也就是Garbage-First名稱(chēng)的來(lái)由）。這種使用Region劃分內(nèi)存空間以及有優(yōu)先級(jí)的區(qū)域回收方式，保證了G1收集器在有限的時(shí)間內(nèi)獲可以獲取盡可能高的收集效率。
但是，G1把內(nèi)存“化整為零”的思路，理解起來(lái)似乎很容易理解，其中的實(shí)現(xiàn)細(xì)節(jié)卻遠(yuǎn)遠(yuǎn)沒(méi)有現(xiàn)象中簡(jiǎn)單，否則也不會(huì)從04年Sun實(shí)驗(yàn)室發(fā)表第一篇G1的論文拖至今將近8年時(shí)間都還沒(méi)有開(kāi)發(fā)出G1的商用版。筆者舉個(gè)一個(gè)細(xì)節(jié)為例：把Java堆分為多個(gè)Region后，垃圾收集是否就真的能以Region為單位進(jìn)行了？聽(tīng)起來(lái)順理成章，再仔細(xì)想想就很容易發(fā)現(xiàn)問(wèn)題所在：Region不可能是孤立的。一個(gè)對(duì)象分配在某個(gè)Region中，它并非只能被本Region中的其他對(duì)象引用，而是可以與整個(gè)Java堆任意的對(duì)象發(fā)生引用關(guān)系。那在做可達(dá)性判定確定對(duì)象是否存活的時(shí)候，豈不是還得掃描整個(gè)Java堆才能保障準(zhǔn)確性？這個(gè)問(wèn)題其實(shí)并非在G1中才有，只是在G1中更加突出了而已。在以前的分代收集中，新生代的規(guī)模一般都比老年代要小許多，新生代的收集也比老年代要頻繁許多，那回收新生代中的對(duì)象也面臨過(guò)相同的問(wèn)題，如果回收新生代時(shí)也不得不同時(shí)掃描老年代的話(huà)，Minor GC的效率可能下降不少。。
在G1收集器中Region之間的對(duì)象引用以及其他收集器中的新生代與老年代之間的對(duì)象引用，虛擬機(jī)都是使用Remembered Set來(lái)避免全堆掃描的。G1中每個(gè)Region都有一個(gè)與之對(duì)應(yīng)的Remembered Set，虛擬機(jī)發(fā)現(xiàn)程序在對(duì)Reference類(lèi)型的數(shù)據(jù)進(jìn)行寫(xiě)操作時(shí)，會(huì)產(chǎn)生一個(gè)Write Barrier暫時(shí)中斷寫(xiě)操作，檢查Reference引用的對(duì)象是否處于不同的Region之中（在分代的例子中就是檢查引是否老年代中的對(duì)象引用了新生代中的對(duì)象），如果是，便通過(guò)CardTable把相關(guān)引用信息記錄到被引用對(duì)象所屬的Region的Remembered Set之中。當(dāng)進(jìn)行內(nèi)存回收時(shí)，GC根節(jié)點(diǎn)的枚舉范圍中加入Remembered Set即可保證不對(duì)全堆掃描也不會(huì)有遺漏。

忽略Remembered Set的維護(hù)，G1的運(yùn)行步驟可簡(jiǎn)單描述為：

①.初始標(biāo)記(Initial Marking)
②.并發(fā)標(biāo)記(Concurrenr Marking)
③.最終標(biāo)記(Final Marking)
④.篩選回收(Live Data Counting And Evacution)

1.初始標(biāo)記：初始標(biāo)記僅僅標(biāo)記GC Roots能直接關(guān)聯(lián)到的對(duì)象，并且修改TAMS（Next Top at Mark Start）的值，讓下一階段用戶(hù)程序并發(fā)運(yùn)行時(shí)，能在正確可用的Region中創(chuàng)建新的對(duì)象。這階段需要停頓線(xiàn)程，不可并行執(zhí)行，但是時(shí)間很短。
2.并發(fā)標(biāo)記：此階段是從GC Roots開(kāi)始對(duì)堆中對(duì)象進(jìn)行可達(dá)性分析，找出存活對(duì)象，此階段時(shí)間較長(zhǎng)可與用戶(hù)程序并發(fā)執(zhí)行。
3.最終標(biāo)記：此階段是為了修正在并發(fā)標(biāo)記期間因?yàn)橛脩?hù)線(xiàn)程繼續(xù)運(yùn)行而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一份標(biāo)記記錄，虛擬機(jī)將這段時(shí)間對(duì)象變化記錄在線(xiàn)程Remembered Set Logs里面，最終標(biāo)記階段需要把Remembered Set Logs的數(shù)據(jù)合并到Remembered Set中，這段時(shí)間需要停頓線(xiàn)程，但是可并行執(zhí)行。
4.篩選回收：對(duì)各個(gè)Region的回收價(jià)值和成本進(jìn)行排序，根據(jù)用戶(hù)期望的GC停頓時(shí)間來(lái)制定回收計(jì)劃。

-XX:+ 啟用選項(xiàng)
-XX:- 不啟用選項(xiàng)
-XX:=
-XX:=

表面上看，Java 和 C 比起來(lái)，由于內(nèi)存的動(dòng)態(tài)分配與內(nèi)存回收技術(shù)已經(jīng)相對(duì)成熟，日常的代碼中也不怎么需要關(guān)注內(nèi)存的申請(qǐng)與釋放。為什么我們還要關(guān)注這些問(wèn)題呢？

筆者認(rèn)為，一方面越是平常不會(huì)關(guān)注的東西，在關(guān)鍵的時(shí)候越珍貴，因?yàn)榇嬖谂挪楦鞣N內(nèi)存溢出、內(nèi)存泄漏問(wèn)題、又或者當(dāng)垃圾收集稱(chēng)為系統(tǒng)達(dá)到更高并發(fā)量瓶頸時(shí)，對(duì)這些“自動(dòng)化”功能細(xì)節(jié)的了解，為我們提供了更廣闊的思路。另一方面，不同業(yè)務(wù)場(chǎng)景總有相似的一面，今天借鑒到的實(shí)現(xiàn)思想的細(xì)節(jié)，一直積累下去，或許未來(lái)的某天突然就豁然開(kāi)朗了。

《HotSpot垃圾收集器》——stack_over_flow@博客園

《解析JDK 7的Garbage-First收集器》——周志明@InfoQ

《深入理解Java虛擬機(jī)：JVM高級(jí)特效與最佳實(shí)現(xiàn)》，第2-3章——周志明著

Java系列筆記 - Java 內(nèi)存區(qū)域和GC機(jī)制——明舞

深入理解JVM結(jié)構(gòu)——java團(tuán)長(zhǎng)

zhihu.com
segmentfault.com
oschina.net