新生代一般采用復(fù)制算法(Copying)。

老生代一搬采用 標(biāo)記-清理(Mark-Sweep) 或者標(biāo)記-整理(Mark-Compact) 進(jìn)行回收。

可達(dá)性分析的缺點(diǎn)

從GC Roots節(jié)點(diǎn)找引用鏈這個(gè)操作為例，可作為GC Roots的節(jié)點(diǎn)主要在全局性的引用（例如常量或類靜態(tài)屬性）與執(zhí)行上下文（例如棧幀中的本地變量表）中，現(xiàn)在很多應(yīng)用僅僅方法區(qū)就有數(shù)百兆，如果要逐個(gè)檢查這里面的引用，那么必然會(huì)消耗很多時(shí)間。

由于要確保在一致性的快照中進(jìn)行可達(dá)性分析，從而導(dǎo)致GC進(jìn)行時(shí)必須要停頓所有Java執(zhí)行線程；

目前主流的Java虛擬機(jī)使用的都是準(zhǔn)確式GC，當(dāng)執(zhí)行系統(tǒng)停頓下來后并不需要一個(gè)不漏的檢查完所有執(zhí)行上下文和全局的引用變量，虛擬機(jī)應(yīng)當(dāng)有辦法直接得知哪些地方存著對(duì)象的引用

HotSpot使用一組稱為OopMap的數(shù)據(jù)結(jié)構(gòu)**來記錄哪些地方存著對(duì)象的引用

在類加載過程中，HotSpot就把對(duì)象內(nèi)什么偏移量上是什么類型的數(shù)據(jù)計(jì)算出來，在JIT編譯過程中會(huì)在特定的位置記錄下棧和寄存器中哪些位置是引用

判斷對(duì)象引用

類加載時(shí)，使用OopMap的數(shù)據(jù)結(jié)構(gòu)

JIT編譯時(shí)特定記錄

HotSpot沒有為每條指令都生成OopMap，只是在特定位置記錄了這些信息，這些位置稱為安全點(diǎn)。

即程序執(zhí)行時(shí)并非在所有地方都能停頓下來開始GC，只有到達(dá)安全點(diǎn)時(shí)才能暫停。

對(duì)于安全點(diǎn)基本上是以程序是否具有讓程序長時(shí)間執(zhí)行的特征（比如方法調(diào)用、循環(huán)跳轉(zhuǎn)、異常跳轉(zhuǎn)等）為標(biāo)準(zhǔn)進(jìn)行選定的。

另外還需要考慮如果在GC時(shí)讓所有線程都跑到最近的安全點(diǎn)上，有兩種方案：搶先式中斷和主動(dòng)式中斷；

搶先式中斷

不需要線程的執(zhí)行代碼主動(dòng)去配合，在GC發(fā)生時(shí)，首先把所有線程全部中斷，如果發(fā)現(xiàn)有線程中斷的地方不在安全點(diǎn)上，就恢復(fù)線程，讓它“跑”到安全點(diǎn)上。 現(xiàn)在幾乎沒有虛擬機(jī)實(shí)現(xiàn)采用搶先式中斷來暫停線程從而響應(yīng)GC事件。

主動(dòng)式中斷

當(dāng)GC需要中斷線程的時(shí)候，不直接對(duì)線程操作，僅僅簡(jiǎn)單地設(shè)置一個(gè)標(biāo)志，各個(gè)線程執(zhí)行時(shí)主動(dòng)去輪詢這個(gè)標(biāo)志，發(fā)現(xiàn)中斷標(biāo)志為真時(shí)就自己中斷掛起。輪詢標(biāo)志的地方和安全點(diǎn)是重合的，另外再加上創(chuàng)建對(duì)象需要分配內(nèi)存的地方。

兩者的區(qū)別在于，搶先式中斷是無論如何都進(jìn)行中斷，而主動(dòng)式中斷則是線程執(zhí)行輪詢標(biāo)志查看是否中斷。

為了處理不執(zhí)行的程序的安全點(diǎn)問題，提出了安全區(qū)域來解決問題。

安全區(qū)域是指在一段代碼片段之中，引用關(guān)系不會(huì)發(fā)生變化，在這個(gè)區(qū)域內(nèi)的任何地方進(jìn)行GC都是安全的。

虛擬機(jī)如個(gè)具體的進(jìn)行內(nèi)存回收是由虛擬機(jī)所采用的GC收集器決定的，而通常虛擬機(jī)中往往不止有一種GC收集器。

線程執(zhí)行到安全區(qū)域時(shí)，首先標(biāo)識(shí)自己已經(jīng)進(jìn)入了安全區(qū)域，這樣JVM在GC時(shí)就不管這些線程了。

如果說收集算法是內(nèi)存回收的方法論，那么垃圾收集器就是內(nèi)存回收的具體實(shí)現(xiàn)。

不同的收集器應(yīng)用的區(qū)域不同，到現(xiàn)在為止沒有最好的收集器，也沒有萬能的收集器。

Serail 收集器是單線程的，他在進(jìn)行垃圾收集時(shí)必須暫停其他的所有線程，直到收集結(jié)束。

隨著收集器的發(fā)展，用戶線程的停頓時(shí)間越來越段，但任然無法消除。

Serial收集器是虛擬機(jī)運(yùn)行在Client模式下默認(rèn)的新生代收集器。

對(duì)于單個(gè)CPU壞境來說，Serial收集器**由于沒有線程交互的開銷，專心做垃圾收集，可以獲得很高的單線程收集效率。

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

ParNew收集器是Serial收集器的多線程版本

ParNew收集器是運(yùn)行在Server模式下虛擬機(jī)中首選的新生代收集器

在垃圾收集器中并發(fā)與并行的概念：

并行：多條垃圾收集線程并行工作，但此時(shí)用戶線程仍然處于等待狀態(tài)。

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

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

新生代收集器，使用復(fù)制算法，并行的多線程收集器；

與其他收集器關(guān)注于盡可能縮短垃圾收集時(shí)用戶線程停頓時(shí)間不同，它的目標(biāo)是達(dá)到一個(gè)可控制的吞吐量。

吞吐量就是CPU用于運(yùn)行用戶代碼的時(shí)間與CPU總消耗時(shí)間的比值，即吞吐量=運(yùn)行用戶代碼時(shí)間/（運(yùn)行用戶代碼時(shí)間+垃圾收集時(shí)間），虛擬機(jī)總共運(yùn)行了100分鐘，其中垃圾收集花掉1分鐘，那吞吐量就是99%。

高吞吐量可以高效的利用CPU時(shí)間，盡快得完成程序的運(yùn)算任務(wù)，主要適合在后臺(tái)運(yùn)算而不需要太多交互的任務(wù)。

GC停頓時(shí)間的縮短是以犧牲吞吐量和新生代空間來換取的。

Parallel Scavenge收集器也經(jīng)常被稱為吞吐量?jī)?yōu)先收集器。

Parallel Scavenge收集器提供了兩個(gè)參數(shù)用于精確控制吞吐量

控制最大垃圾收集停頓時(shí)間的-XX：MaxGCPauseMillis參數(shù)。

直接設(shè)置吞吐量大小的-XX：GCTimeRatio參數(shù)。

Serial Old是Serial收集器的老年代版本，它同樣是一個(gè)單線程收集器，使用“標(biāo)記-整理”算法。

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

Serial Old收集器是Serail收集器的老年代版本，是一個(gè)單線程收集器，使用標(biāo)記-整理算法。

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

Serail Old收集器主要用于Clinet模式下。

Serail Old收集器另一種用途是作為CMS收集器的后備預(yù)案。

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和“標(biāo)記-整理”算法。

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

CMS收集器是一種以獲取最短的回收停頓時(shí)間為目標(biāo)的收集器。

CMS收集器基于標(biāo)記-清楚算法實(shí)現(xiàn)，分為四個(gè)步驟：初始標(biāo)記、并發(fā)標(biāo)記、重新標(biāo)記、并發(fā)清除。

步驟詳解

初始標(biāo)記：標(biāo)記一下GC Roots能直接關(guān)聯(lián)到的對(duì)象，速度很快。

并發(fā)標(biāo)記：進(jìn)行GC Roots Tracing。

重新標(biāo)記：是為了修正那些在并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對(duì)象的標(biāo)記記錄，在這一階段的停頓時(shí)間會(huì)比初始標(biāo)記階段稍長一點(diǎn)。

并發(fā)清除：（CMS concurrent sweep）。

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

G1收集器是一款面向服務(wù)端應(yīng)用的垃圾收集器。
G1收集器具備以下特點(diǎn)：

并行與并發(fā)

G1能充分利用多CPU、 多核環(huán)境下的硬件優(yōu)勢(shì)，使用多個(gè)CPU（CPU或者CPU核心）來縮短Stop-The-World停頓的時(shí)間，部分其他收集器原本需要停頓Java線程執(zhí)行的GC動(dòng)作，G1收集器仍然可以通過并發(fā)的方式讓Java程序繼續(xù)執(zhí)行。

分代收集

與其他收集器一樣，分代概念在G1中依然得以保留。 雖然G1可以不需要其他收集器配合就能獨(dú)立管理整個(gè)GC堆，但它能夠采用不同的方式去處理新創(chuàng)建的對(duì)象和已經(jīng)存活了一段時(shí)間、 熬過多次GC的舊對(duì)象以獲取更好的收集效果。

空間整合

從整體上來看是基于“標(biāo)記-整理”算法實(shí)現(xiàn)的，在局部上是基于復(fù)制算法實(shí)現(xiàn)的，但無論如何，這兩種算法都意味著G1運(yùn)作期間不會(huì)產(chǎn)生內(nèi)存空間碎片，收集后能提供規(guī)整的可用內(nèi)存。 這種特性有利于程序長時(shí)間運(yùn)行，分配大對(duì)象時(shí)不會(huì)因?yàn)闊o法找到連續(xù)內(nèi)存空間而提前觸發(fā)下一次GC。

可預(yù)測(cè)的停頓

這是G1相對(duì)于CMS的另一大優(yōu)勢(shì)，降低停頓時(shí)間是G1和CMS共同的關(guān)注點(diǎn)，但G1除了追求低停頓外，還能建立可預(yù)測(cè)的停頓時(shí)間模型，能讓使用者明確指定在一個(gè)長度為M毫秒的時(shí)間片段內(nèi)，消耗在垃圾收集上的時(shí)間不得超過N毫秒，這幾乎已經(jīng)是實(shí)時(shí)Java（RTSJ）的垃圾收集器的特征了。

G1收集器將整個(gè)Java堆劃分為多個(gè)大小相等的獨(dú)立區(qū)域，雖然還保留有新生代和老生代的概念，但新生代和老生代不再是物理隔的了，他們是一部分Region的集合。

G1收集器可以有計(jì)劃地避免在整個(gè)Java堆中進(jìn)行全區(qū)域的垃圾收集：跟蹤各個(gè)Region里面的垃圾堆積的價(jià)值大小，在后臺(tái)維護(hù)一個(gè)優(yōu)先列表，每次根據(jù)允許的收集時(shí)間，優(yōu)先回收價(jià)值最大的Region。

在G1收集器中，使用Remembered Set來避免全堆掃描

G1收集器的運(yùn)作大致可劃分為以下幾個(gè)步驟：

初始標(biāo)記（Initial Marking）

僅僅只是標(biāo)記一下GC Roots能直接關(guān)聯(lián)到的對(duì)象，并且修改TAMS（Next Top at Mark Start）的值，讓下一階段用戶程序并發(fā)運(yùn)行時(shí)，能在正確可用的Region中創(chuàng)建新對(duì)象，這階段需要停頓線程，但耗時(shí)很短。

并發(fā)標(biāo)記（Concurrent Marking）

從GC Root開始對(duì)堆中對(duì)象進(jìn)行可達(dá)性分析，找出存活的對(duì)象，這階段耗時(shí)較長，但可與用戶程序并發(fā)執(zhí)行。

最終標(biāo)記（Final Marking）

為了修正在并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分標(biāo)記記錄，虛擬機(jī)將這段時(shí)間對(duì)象變化記錄在線Remembered Set Logs里面，最終標(biāo)記階段需要把Remembered Set Logs的數(shù)據(jù)合并到Remembered Set中，這階段需要停頓線程，但是可并行執(zhí)行。

篩選回收（Live Data Counting and Evacuation）

首先對(duì)各個(gè)Region的回收價(jià)值和成本進(jìn)行排序，根據(jù)用戶所期望的GC停頓時(shí)間來制定回收計(jì)劃

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

最前面的數(shù)字代表GC發(fā)生的時(shí)間（虛擬機(jī)啟動(dòng)以后的秒殺）

“[GC”和“[Full GC”說明停頓類型，有Full代表的是Stop-The-World的；

“[DefNew”、“[Tenured”和“[Perm”表示GC發(fā)生的區(qū)域；

方括號(hào)內(nèi)部的“3324K -> 152K(3712K)” 含義是 “GC前該內(nèi)存已使用容量 -> GC后該內(nèi)存區(qū)域已使用容量(該區(qū)域總?cè)萘?”;

方括號(hào)之外的“3324K -> 152K(11904)” 含義是 “GC前Java堆已使用容量 -> GC后Java堆已使用容量(Java堆總?cè)萘?”;

再往后“0.0025925 secs”表示該內(nèi)存區(qū)域GC所占用的時(shí)間；

垃圾收集器參數(shù)總結(jié)

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

對(duì)象優(yōu)先在新生代分配
大對(duì)象直接進(jìn)入老年代
長期存活的對(duì)象將進(jìn)入老年代

動(dòng)態(tài)對(duì)象年齡判斷：如果在Survivor空間中相同年齡所有對(duì)象大小總和大于Survivor空間的一半，大于或等于該年齡的對(duì)象直接進(jìn)入老年代。

空間分配擔(dān)保：發(fā)生Minor GC前，虛擬機(jī)會(huì)先檢查老年代最大可用連續(xù)空間是否大于新生代所有對(duì)象總空間，如果不成立，虛擬機(jī)會(huì)查看HandlePromotionFailure設(shè)置值是否允許擔(dān)保失敗，如果允許繼續(xù)檢查老年代最大可用的連續(xù)空間是否大于歷次晉升到老年代的平均大小，如果大于會(huì)嘗試進(jìn)行一次Minor GC；如果小于或者不允許冒險(xiǎn)，會(huì)進(jìn)行一次Full GC。

大多數(shù)情況下，對(duì)象優(yōu)先在新生代的Eden區(qū)分配。
當(dāng)Eden區(qū)沒有足夠的空間時(shí)，虛擬機(jī)將發(fā)起一次Minor GC。
Minor GC與Full GC。

Minor GC：新生代GC，非常頻繁，回收速度快。

Fulll GC：老年代GC，又稱為Major GC，經(jīng)常會(huì)伴隨一次Minor GC，速度比較慢。

大對(duì)象是指需要大量連續(xù)的內(nèi)存空間的Java對(duì)象,最典型的大對(duì)象就是那種很長的字符串以及數(shù)組。

虛擬機(jī)提供了一個(gè)參數(shù)：PretenureSizeThreshold，大于這個(gè)參數(shù)的對(duì)象將直接在老年代分配。

虛擬機(jī)給每個(gè)對(duì)象定義了一個(gè)對(duì)象年齡計(jì)數(shù)器（Age），對(duì)象每經(jīng)過一次Minor GC后仍然存活，且能被Survivor容納的話，年齡就 +1 ，當(dāng)年齡增加到一定程度（默認(rèn)為15），就會(huì)被晉升到老年代中，這個(gè)閾值可以通過參數(shù) MaxTenuringThreshold 來設(shè)置。

4.動(dòng)態(tài)對(duì)象年齡的判定

如果在Survivor空間中相同年齡所有對(duì)象大小的總和大于Survivor空間的一半，年齡大于或等于該年齡的對(duì)象就可以直接進(jìn)入老年代。

為了更好的適應(yīng)不同程序的內(nèi)存狀況，對(duì)象年齡不是必須到達(dá)閾值才會(huì)進(jìn)入老年代。

只要老年代的連續(xù)空間大于新生代對(duì)象總大小或者歷次晉升的平均大小就會(huì)進(jìn)行Minor GC，否則將進(jìn)行Full GC。

為什么程序要跑到安全點(diǎn)時(shí)停下來？

不設(shè)置安全點(diǎn)，而讓每一條指令都產(chǎn)生Oop(Ordinary Object Pointer)會(huì)需要大量的額外空間，增大GC的空間成本。設(shè)置了合適的安全點(diǎn)，有助于虛擬機(jī)得知對(duì)象引用所在的地方，因此有利于GC對(duì)“即將回收”的對(duì)象進(jìn)行掃描。

最后上一張本章結(jié)構(gòu)圖

圖片來源于網(wǎng)絡(luò)如有侵權(quán)請(qǐng)私信刪除

《深入理解Java虛擬機(jī)：JVM高級(jí)特性與最佳實(shí)踐_周志明.高清掃描版.pdf》

下載地址：鏈接：http://pan.baidu.com/s/1miBQCBY 密碼：9kbn

《深入理解Java虛擬機(jī)》（一）Java虛擬機(jī)發(fā)展史

《深入理解Java虛擬機(jī)》（二）Java虛擬機(jī)運(yùn)行時(shí)數(shù)據(jù)區(qū)

《深入理解Java虛擬機(jī)》（三）垃圾收集器與內(nèi)存分配策略

《深入理解Java虛擬機(jī)》（四）虛擬機(jī)性能監(jiān)控與故障處理工具

《深入理解Java虛擬機(jī)》（五）JVM調(diào)優(yōu) - 工具

《深入理解Java虛擬機(jī)》（六）堆內(nèi)存使用分析，GC 日志解讀

作者：鵬磊

出處：http://www.ymq.io

Email：[email protected]

版權(quán)歸作者所有，轉(zhuǎn)載請(qǐng)注明出處

Wechat：關(guān)注公眾號(hào)，搜云庫，專注于開發(fā)技術(shù)的研究與知識(shí)分享