一、并發(fā)標(biāo)記與三色標(biāo)記

問題：三色標(biāo)記到底發(fā)生在什么階段，替代了什么。并發(fā)標(biāo)記

1、并發(fā)標(biāo)記( Concurrent Marking)

從 GC Root 開始對(duì)堆中對(duì)象進(jìn)行可達(dá)性分析，遞歸掃描整個(gè)堆里的對(duì)象圖，找出要回收的對(duì)象，這階段耗時(shí)較長(zhǎng)，但可與用戶程序并發(fā)執(zhí)行。當(dāng)對(duì)象圖掃描完成以后 ，并發(fā)標(biāo)記時(shí)有引用變動(dòng)的對(duì)象 ，這些對(duì)象會(huì)漏標(biāo)。

CMS和G1的并發(fā)標(biāo)記階段使用的標(biāo)記清除掃秒算法占用了太長(zhǎng)中斷時(shí)間，所以用三色標(biāo)記替換。

2、三色標(biāo)記的概念（多線程）

在三色標(biāo)記之前有一個(gè)算法叫Mark-And-Sweep（標(biāo)記清除）。這個(gè)算法會(huì)給每一個(gè)對(duì)象設(shè)置一個(gè)標(biāo)志位來記錄對(duì)象是否被使用。最開始標(biāo)識(shí)位都是0，如果發(fā)現(xiàn)對(duì)象可達(dá)就會(huì)設(shè)置為1，一步步下去就會(huì)呈現(xiàn)一個(gè)類似樹狀的結(jié)果。等標(biāo)記的步驟完成后，會(huì)將被標(biāo)記的對(duì)象統(tǒng)一清理，再次把所有的標(biāo)記位置設(shè)置成0方便下次清理。

標(biāo)記清除最大的問題是GC執(zhí)行期間需要把整個(gè)程序完全暫停，不能異步進(jìn)行GC操作。因?yàn)椴煌A段標(biāo)記清除法的標(biāo)志位0和1有不同的含義，那么新增的對(duì)象無論標(biāo)記成什么都有可能意外刪除。對(duì)實(shí)時(shí)性要求高的系統(tǒng)來說，這種需要長(zhǎng)時(shí)間掛起的標(biāo)記清除算法是不可接受的。所以就需要一個(gè)算法來解決GC運(yùn)行時(shí)程序長(zhǎng)時(shí)間掛起的問題，那就是三色標(biāo)記。

三色標(biāo)記最大的好處就是異步，從而可以以中斷時(shí)間極少的代價(jià)或者完全沒有中斷來進(jìn)行整個(gè)GC

三色標(biāo)記把對(duì)象用三種顏色標(biāo)記

• 黑色：根對(duì)象，或者這個(gè)對(duì)象及他的子對(duì)象都已經(jīng)被掃描了
• 灰色：本身已經(jīng)掃描了，子對(duì)象還沒掃描
• 白色：未被掃描的對(duì)象，如果掃描完所有的對(duì)象之后，最終白色的為不可達(dá)對(duì)象，既為垃圾

3、三色標(biāo)記的問題

GC并發(fā)情況下會(huì)有漏標(biāo)的問題

第一步：線程1完成所有的標(biāo)記，線程2還處于半完成狀態(tài)

第二步：引用發(fā)成變化，B指向C變成A指向C

第三步：線程1、2都完成所有的標(biāo)記，C對(duì)象是白色，被錯(cuò)誤的回收

4、三色標(biāo)記并發(fā)情況下漏標(biāo)記解決方案（單線程，最終標(biāo)記）

（1）cms的解決方案 incremental update 增量更新算法

CMS的三色標(biāo)記發(fā)生并發(fā)標(biāo)記和重新標(biāo)記階段

當(dāng)一個(gè)白色對(duì)象被一個(gè)黑色對(duì)象引用，將黑色對(duì)象重新標(biāo)記為灰色，讓垃圾回收器重新掃描。增量更新，關(guān)注的是引用新增。

（2）G1中的解決方案 STAB (snapshot-at-the-beginning) 快照處理算法

剛開始做一個(gè)快照，當(dāng)B指向C的引用消失的時(shí)候，就把這個(gè)引用推到GC的堆棧，保證C還能被GC掃描到，最重要的是要把這個(gè)引用推到GC的堆棧，是灰色對(duì)象B指向白色C的引用，如果一旦某一個(gè)引用消失掉了，會(huì)把它放到棧（GC方法運(yùn)行時(shí)數(shù)據(jù)也是來自棧中），其實(shí)還是能找到它的，下回直接掃描他就行了，那樣白色就不會(huì)漏標(biāo)。再次做一個(gè)快照，然后兩個(gè)快照進(jìn)行對(duì)比，發(fā)現(xiàn)C不是垃圾，那就要對(duì)C單獨(dú)再做一次處理。

對(duì)應(yīng) G1 的垃圾回收過程中的：最終標(biāo)記

對(duì)用戶線程做另外一個(gè)短暫的暫停，用于處理并發(fā)階段結(jié)束后仍遺留下來的最后那少量的SATB記錄（漏標(biāo)對(duì)象）

（3）incremental update與STAB對(duì)比

為什么CMS不用快照，為什么G1不用增量

incremental Update算法關(guān)注引用的增加。（A-C的引用），如果增加了就變灰色，需要重新掃描

SATB算法是關(guān)注引用的刪除（B->C的引用）

G1 如果使用 Incremental Update 算法，因?yàn)樽兂苫疑某蓡T還要重新掃，重新再來一遍，效率太低了。

所以 G1 在處理并發(fā)標(biāo)記的過程比 CMS 效率要高，但是占內(nèi)存高，這個(gè)主要是解決漏標(biāo)的算法決定的。

三、安全點(diǎn)與安全區(qū)域

1、安全點(diǎn)（不會(huì)發(fā)生引用的變化的代碼）

用戶線程暫停，GC 線程要開始工作，但是要確保用戶線程暫停的這行字節(jié)碼指令是不會(huì)導(dǎo)致引用關(guān)系的變化。

所以 JVM 會(huì)在字節(jié)碼指令中，選一些指令，作為“安全點(diǎn)”，比如方法調(diào)用、循環(huán)跳轉(zhuǎn)、異常跳轉(zhuǎn)等，一般是這些指令才會(huì)產(chǎn)生安全點(diǎn)。

為什么它叫安全點(diǎn)，GC 時(shí)要暫停業(yè)務(wù)線程，并不是搶占式中斷（立馬把業(yè)務(wù)線程中斷）而是主動(dòng)式中斷。主動(dòng)式中斷是設(shè)置一個(gè)標(biāo)志，這個(gè)標(biāo)志是中斷標(biāo)志，各業(yè)務(wù)線程在運(yùn)行過程中會(huì)不停的主動(dòng)去輪詢這個(gè)標(biāo)志，一旦發(fā)現(xiàn)中斷標(biāo)志為 True，就會(huì)在自己最近的“安全點(diǎn)”上主動(dòng)中斷掛起。

業(yè)務(wù)線程停止---安全點(diǎn)--->垃圾回收線程開始

業(yè)務(wù)線程主動(dòng)式中斷，GC開始，STW業(yè)務(wù)線程， 業(yè)務(wù)線程輪訓(xùn)標(biāo)志S（0 OR 1），即GC開始標(biāo)志，主動(dòng)去中斷線程，跑到最近的安全點(diǎn)掛起。

2、安全區(qū)域

為什么需要安全區(qū)域？

要是業(yè)務(wù)線程都不執(zhí)行（業(yè)務(wù)線程處于 Sleep 或者是 Blocked 狀態(tài)），那么程序就沒辦法進(jìn)入安全點(diǎn)，對(duì)于這種情況，就必須引入安全區(qū)域。

安全區(qū)域是指能夠確保在某一段代碼片段之中， 引用關(guān)系不會(huì)發(fā)生變化，因此，在這個(gè)區(qū)域中任意地方開始垃圾收集都是安全的。我們也可以把安全區(qū)城看作被擴(kuò)展拉伸了的安全點(diǎn)。

當(dāng)用戶線程執(zhí)行到安全區(qū)域里面的代碼時(shí)，首先會(huì)標(biāo)識(shí)自己已經(jīng)進(jìn)入了安全區(qū)域，這段時(shí)間里 JVM 要發(fā)起 GC 就不必去管這個(gè)線程了。

當(dāng)線程要離開安全區(qū)域時(shí)，它要判斷 JVM 是否已經(jīng)完成了GC階段（根節(jié)點(diǎn)枚舉，或者其他 GC 中需要暫停用戶線程的階段)

1、如果完成了，那線程就當(dāng)作沒事發(fā)生過，繼續(xù)執(zhí)行。

2、否則它就必須一直等待， 直到收到可以離開安全區(qū)域的信號(hào)為止。

四、低延遲的垃圾回收器

1、垃圾回收器的三項(xiàng)指標(biāo)

傳統(tǒng)的垃圾回收器一般情況下內(nèi)存占用、吞吐量、延遲只能同時(shí)滿足兩個(gè)。但是現(xiàn)在的發(fā)展，延遲這項(xiàng)的目標(biāo)越來越重要。所以就有低延遲的垃圾回收器。

2、Eplison（了解即可）

這個(gè)垃圾回收器不能進(jìn)行垃圾回收，是一個(gè)“不干活”的垃圾回收器，由 RedHat 推出，它還要負(fù)責(zé)堆的管理與布局、對(duì)象的分配、與解釋器的協(xié)作、與編譯器的協(xié)作、與監(jiān)控子系統(tǒng)協(xié)作等職責(zé)，主要用于需要?jiǎng)冸x垃圾收集器影響的性能測(cè)試和壓力測(cè)試。

3、ZGC（了解即可）

有類似于 G1 的 Region，但是沒有分代。

標(biāo)志性的設(shè)計(jì)是染色指針 ColoredPointers（這個(gè)概念了解即可），染色指針有 4TB 的內(nèi)存限制，但是效率極高，它是一種將少量額外的信息存儲(chǔ)在指針上的技術(shù)。

它可以做到幾乎整個(gè)收集過程全程可并發(fā)，短暫的 STW 也只與 GC Roots 大小相關(guān)而與堆空間內(nèi)存大小無關(guān)，因此可以實(shí)現(xiàn)任何堆空間 STW 的時(shí)間小于十毫秒的目標(biāo)。

JDK11 –ZGC（暫停時(shí)間不超過 10 毫秒，且不會(huì)隨著堆的增加而增加，TB 級(jí)別的堆回收））：

有色指針、加載屏障。JDK12 支持并發(fā)類卸載，進(jìn)一步縮短暫停時(shí)間 JDK13(計(jì)劃于 2019 年 9 月)將最大堆大小從 4TB 增加到 16TB

4、Shenandoah（了解即可）

第一款非 Oracle 公司開發(fā)的垃圾回收器，有類似于 G1 的 Region，但是沒有分代。也用到了染色指針 ColoredPointers。效率沒有 ZGC 高，大概幾十毫秒的目標(biāo)。

五、GC 參數(shù)和GC 日志詳解

1、GC 常用參數(shù)

-Xmn -Xms -Xmx –Xss 年輕代 最小堆 最大堆 ?？臻g

-XX:+UseTLAB 使用 TLAB，默認(rèn)打開

-XX:+PrintTLAB 打印 TLAB 的使用情況

-XX:TLABSize 設(shè)置 TLAB 大小

-XX:+DisableExplicitGC 啟用用于禁用對(duì)的調(diào)用處理的選項(xiàng) System.gc()

-XX:+PrintGC 查看 GC 基本信息

-XX:+PrintGCDetails 查看 GC 詳細(xì)信息

-XX:+PrintHeapAtGC 每次一次 GC 后，都打印堆信息

-XX:+PrintGCTimeStamps 啟用在每個(gè) GC 上打印時(shí)間戳的功能

-XX:+PrintGCApplicationConcurrentTime 打印應(yīng)用程序時(shí)間(低)

-XX:+PrintGCApplicationStoppedTime 打印暫停時(shí)長(zhǎng)（低）

-XX:+PrintReferenceGC 記錄回收了多少種不同引用類型的引用（重要性低）

-verbose:class 類加載詳細(xì)過程

-XX:+PrintVMOptions 可在程序運(yùn)行時(shí)，打印虛擬機(jī)接受到的命令行顯示參數(shù)

-XX:+PrintFlagsFinal -XX:+PrintFlagsInitial 打印所有的 JVM 參數(shù)、查看所有 JVM 參數(shù)啟動(dòng)的初始值（必須會(huì)用）

-XX:MaxTenuringThreshold 升代年齡，最大值 15, 并行（吞吐量）收集器的默認(rèn)值為 15，而 CMS 收集器的默認(rèn)值為 6。

2、Parallel 常用參數(shù)

-XX:SurvivorRatio 設(shè)置伊甸園空間大小與幸存者空間大小之間的比率。默認(rèn)情況下，此選項(xiàng)設(shè)置為 8

-XX:PreTenureSizeThreshold 大對(duì)象到底多大，大于這個(gè)值的參數(shù)直接在老年代分配

-XX:MaxTenuringThreshold 升代年齡，最大值 15, 并行（吞吐量）收集器的默認(rèn)值為 15，而 CMS 收集器的默認(rèn)值為 6。

-XX:+ParallelGCThreads 并行收集器的線程數(shù)，同樣適用于 CMS，一般設(shè)為和 CPU 核數(shù)相同

-XX:+UseAdaptiveSizePolicy 自動(dòng)選擇各區(qū)大小比例

3、CMS 常用參數(shù)

-XX:+UseConcMarkSweepGC 啟用 CMS 垃圾回收器

-XX:+ParallelGCThreads 并行收集器的線程數(shù)，同樣適用于CMS，一般設(shè)為和 CPU 核數(shù)相同

-XX:CMSInitiatingOccupancyFraction 使用多少比例的老年代后開始 CMS 收集，默認(rèn)是 68%(近似值)，如果頻繁發(fā)生 SerialOld 卡頓，應(yīng)該調(diào)小，（頻繁 CMS 回收）

-XX:+UseCMSCompactAtFullCollection 在 FGC 時(shí)進(jìn)行壓縮

-XX:CMSFullGCsBeforeCompaction 多少次 FGC 之后進(jìn)行壓縮

-XX:+CMSClassUnloadingEnabled 使用并發(fā)標(biāo)記掃描（CMS）垃圾收集器時(shí)，啟用類卸載。默認(rèn)情況下啟用此選項(xiàng)。

-XX:CMSInitiatingPermOccupancyFraction 達(dá)到什么比例時(shí)進(jìn)行 Perm 回收，JDK 8 中不推薦使用此選項(xiàng)，不能替代。

-XX:GCTimeRatio 設(shè)置 GC 時(shí)間占用程序運(yùn)行時(shí)間的百分比（不推薦使用）

-XX:MaxGCPauseMillis 停頓時(shí)間，是一個(gè)建議時(shí)間，GC 會(huì)嘗試用各種手段達(dá)到這個(gè)時(shí)間，比如減小年輕代

4、G1 常用參數(shù)

-XX:+UseG1GC 啟用 CMS 垃圾收集器

-XX:MaxGCPauseMillis 設(shè)置最大 GC 暫停時(shí)間的目標(biāo)（以毫秒為單位）。這是一個(gè)軟目標(biāo)，并且 JVM 將盡最大的努力（G1 會(huì)嘗試調(diào)整 Young 區(qū)的塊數(shù)來）來實(shí)

現(xiàn)它。默認(rèn)情況下，沒有最大暫停時(shí)間值。

-XX:GCPauseIntervalMillis GC 的間隔時(shí)間

-XX:+G1HeapRegionSize 分區(qū)大小，建議逐漸增大該值，1 2 4 8 16 32。隨著 size 增加，垃圾的存活時(shí)間更長(zhǎng)，GC 間隔更長(zhǎng)，但每次 GC 的時(shí)間也會(huì)更長(zhǎng)

-XX:G1NewSizePercent 新生代最小比例，默認(rèn)為 5%

-XX:G1MaxNewSizePercent 新生代最大比例，默認(rèn)為 60%

-XX:GCTimeRatioGC 時(shí)間建議比例，G1 會(huì)根據(jù)這個(gè)值調(diào)整堆空間

-XX:ConcGCThreads 線程數(shù)量

-XX:InitiatingHeapOccupancyPercent 啟動(dòng) G1 的堆空間占用比例，根據(jù)整個(gè)堆的占用而觸發(fā)并發(fā) GC 周期