一、并發標記與三色標記
問題：三色標記到底發生在什么階段，替代了什么。并發標記
1、并發標記( Concurrent Marking)
從 GC Root 開始對堆中對象進行可達性分析，遞歸掃描整個堆里的對象圖，找出要回收的對象，這階段耗時較長，但可與用戶程序并發執行。當對象圖掃描完成以后 ，并發標記時有引用變動的對象 ，這些對象會漏標。
CMS和G1的并發標記階段使用的標記清除掃秒算法占用了太長中斷時間，所以用三色標記替換。
2、三色標記的概念（多線程）
在三色標記之前有一個算法叫Mark-And-Sweep（標記清除）。這個算法會給每一個對象設置一個標志位來記錄對象是否被使用。最開始標識位都是0，如果發現對象可達就會設置為1，一步步下去就會呈現一個類似樹狀的結果。等標記的步驟完成后，會將被標記的對象統一清理，再次把所有的標記位置設置成0方便下次清理。
標記清除最大的問題是GC執行期間需要把整個程序完全暫停，不能異步進行GC操作。因為不同階段標記清除法的標志位0和1有不同的含義，那么新增的對象無論標記成什么都有可能意外刪除。對實時性要求高的系統來說，這種需要長時間掛起的標記清除算法是不可接受的。所以就需要一個算法來解決GC運行時程序長時間掛起的問題，那就是三色標記。
三色標記最大的好處就是異步，從而可以以中斷時間極少的代價或者完全沒有中斷來進行整個GC
三色標記把對象用三種顏色標記
- 黑色：根對象，或者這個對象及他的子對象都已經被掃描了
- 灰色：本身已經掃描了，子對象還沒掃描
- 白色：未被掃描的對象，如果掃描完所有的對象之后，最終白色的為不可達對象，既為垃圾
3、三色標記的問題
GC并發情況下會有漏標的問題
第一步：線程1完成所有的標記，線程2還處于半完成狀態
第二步：引用發成變化，B指向C變成A指向C
第三步：線程1、2都完成所有的標記，C對象是白色，被錯誤的回收
4、三色標記并發情況下漏標記解決方案（單線程，最終標記）
（1）cms的解決方案 incremental update 增量更新算法
CMS的三色標記發生并發標記和重新標記階段
當一個白色對象被一個黑色對象引用，將黑色對象重新標記為灰色，讓垃圾回收器重新掃描。增量更新，關注的是引用新增。
（2）G1中的解決方案 STAB (snapshot-at-the-beginning) 快照處理算法
剛開始做一個快照，當B指向C的引用消失的時候，就把這個引用推到GC的堆棧，保證C還能被GC掃描到，最重要的是要把這個引用推到GC的堆棧，是灰色對象B指向白色C的引用，如果一旦某一個引用消失掉了，會把它放到棧（GC方法運行時數據也是來自棧中），其實還是能找到它的，下回直接掃描他就行了，那樣白色就不會漏標。再次做一個快照，然后兩個快照進行對比，發現C不是垃圾，那就要對C單獨再做一次處理。
對應 G1 的垃圾回收過程中的：最終標記
對用戶線程做另外一個短暫的暫停，用于處理并發階段結束后仍遺留下來的最后那少量的SATB記錄（漏標對象）
（3）incremental update與STAB對比
為什么CMS不用快照，為什么G1不用增量
incremental Update算法關注引用的增加。（A-C的引用），如果增加了就變灰色，需要重新掃描
SATB算法是關注引用的刪除（B->C的引用）
G1 如果使用 Incremental Update 算法，因為變成灰色的成員還要重新掃，重新再來一遍，效率太低了。
所以 G1 在處理并發標記的過程比 CMS 效率要高，但是占內存高，這個主要是解決漏標的算法決定的。
三、安全點與安全區域
1、安全點（不會發生引用的變化的代碼）
用戶線程暫停，GC 線程要開始工作，但是要確保用戶線程暫停的這行字節碼指令是不會導致引用關系的變化。
所以 JVM 會在字節碼指令中，選一些指令，作為“安全點”，比如方法調用、循環跳轉、異常跳轉等，一般是這些指令才會產生安全點。
為什么它叫安全點，GC 時要暫停業務線程，并不是搶占式中斷（立馬把業務線程中斷）而是主動式中斷。主動式中斷是設置一個標志，這個標志是中斷標志，各業務線程在運行過程中會不停的主動去輪詢這個標志，一旦發現中斷標志為 True，就會在自己最近的“安全點”上主動中斷掛起。
業務線程停止---安全點--->垃圾回收線程開始
業務線程主動式中斷，GC開始，STW業務線程， 業務線程輪訓標志S（0 OR 1），即GC開始標志，主動去中斷線程，跑到最近的安全點掛起。
2、安全區域
為什么需要安全區域？
要是業務線程都不執行（業務線程處于 Sleep 或者是 Blocked 狀態），那么程序就沒辦法進入安全點，對于這種情況，就必須引入安全區域。
安全區域是指能夠確保在某一段代碼片段之中， 引用關系不會發生變化，因此，在這個區域中任意地方開始垃圾收集都是安全的。我們也可以把安全區城看作被擴展拉伸了的安全點。
當用戶線程執行到安全區域里面的代碼時，首先會標識自己已經進入了安全區域，這段時間里 JVM 要發起 GC 就不必去管這個線程了。
當線程要離開安全區域時，它要判斷 JVM 是否已經完成了GC階段（根節點枚舉，或者其他 GC 中需要暫停用戶線程的階段)
1、如果完成了，那線程就當作沒事發生過，繼續執行。
2、否則它就必須一直等待， 直到收到可以離開安全區域的信號為止。
四、低延遲的垃圾回收器
1、垃圾回收器的三項指標
傳統的垃圾回收器一般情況下內存占用、吞吐量、延遲只能同時滿足兩個。但是現在的發展，延遲這項的目標越來越重要。所以就有低延遲的垃圾回收器。
2、Eplison（了解即可）
這個垃圾回收器不能進行垃圾回收，是一個“不干活”的垃圾回收器，由 RedHat 推出，它還要負責堆的管理與布局、對象的分配、與解釋器的協作、與編譯器的協作、與監控子系統協作等職責，主要用于需要剝離垃圾收集器影響的性能測試和壓力測試。
3、ZGC（了解即可）
有類似于 G1 的 Region，但是沒有分代。
標志性的設計是染色指針 ColoredPointers（這個概念了解即可），染色指針有 4TB 的內存限制，但是效率極高，它是一種將少量額外的信息存儲在指針上的技術。
它可以做到幾乎整個收集過程全程可并發，短暫的 STW 也只與 GC Roots 大小相關而與堆空間內存大小無關，因此可以實現任何堆空間 STW 的時間小于十毫秒的目標。
JDK11 –ZGC（暫停時間不超過 10 毫秒，且不會隨著堆的增加而增加，TB 級別的堆回收））：
有色指針、加載屏障。JDK12 支持并發類卸載，進一步縮短暫停時間 JDK13(計劃于 2019 年 9 月)將最大堆大小從 4TB 增加到 16TB
4、Shenandoah（了解即可）
第一款非 Oracle 公司開發的垃圾回收器，有類似于 G1 的 Region，但是沒有分代。也用到了染色指針 ColoredPointers。效率沒有 ZGC 高，大概幾十毫秒的目標。
五、GC 參數和GC 日志詳解
1、GC 常用參數
-Xmn -Xms -Xmx –Xss 年輕代 最小堆 最大堆 棧空間
-XX:+UseTLAB 使用 TLAB，默認打開
-XX:+PrintTLAB 打印 TLAB 的使用情況
-XX:TLABSize 設置 TLAB 大小
-XX:+DisableExplicitGC 啟用用于禁用對的調用處理的選項 System.gc()
-XX:+PrintGC 查看 GC 基本信息
-XX:+PrintGCDetails 查看 GC 詳細信息
-XX:+PrintHeapAtGC 每次一次 GC 后，都打印堆信息
-XX:+PrintGCTimeStamps 啟用在每個 GC 上打印時間戳的功能
-XX:+PrintGCApplicationConcurrentTime 打印應用程序時間(低)
-XX:+PrintGCApplicationStoppedTime 打印暫停時長（低）
-XX:+PrintReferenceGC 記錄回收了多少種不同引用類型的引用（重要性低）
-verbose:class 類加載詳細過程
-XX:+PrintVMOptions 可在程序運行時，打印虛擬機接受到的命令行顯示參數
-XX:+PrintFlagsFinal -XX:+PrintFlagsInitial 打印所有的 JVM 參數、查看所有 JVM 參數啟動的初始值（必須會用）
-XX:MaxTenuringThreshold 升代年齡，最大值 15, 并行（吞吐量）收集器的默認值為 15，而 CMS 收集器的默認值為 6。
2、Parallel 常用參數
-XX:SurvivorRatio 設置伊甸園空間大小與幸存者空間大小之間的比率。默認情況下，此選項設置為 8
-XX:PreTenureSizeThreshold 大對象到底多大，大于這個值的參數直接在老年代分配
-XX:MaxTenuringThreshold 升代年齡，最大值 15, 并行（吞吐量）收集器的默認值為 15，而 CMS 收集器的默認值為 6。
-XX:+ParallelGCThreads 并行收集器的線程數，同樣適用于 CMS，一般設為和 CPU 核數相同
-XX:+UseAdaptiveSizePolicy 自動選擇各區大小比例
3、CMS 常用參數
-XX:+UseConcMarkSweepGC 啟用 CMS 垃圾回收器
-XX:+ParallelGCThreads 并行收集器的線程數，同樣適用于CMS，一般設為和 CPU 核數相同
-XX:CMSInitiatingOccupancyFraction 使用多少比例的老年代后開始 CMS 收集，默認是 68%(近似值)，如果頻繁發生 SerialOld 卡頓，應該調小，（頻繁 CMS 回收）
-XX:+UseCMSCompactAtFullCollection 在 FGC 時進行壓縮
-XX:CMSFullGCsBeforeCompaction 多少次 FGC 之后進行壓縮
-XX:+CMSClassUnloadingEnabled 使用并發標記掃描（CMS）垃圾收集器時，啟用類卸載。默認情況下啟用此選項。
-XX:CMSInitiatingPermOccupancyFraction 達到什么比例時進行 Perm 回收，JDK 8 中不推薦使用此選項，不能替代。
-XX:GCTimeRatio 設置 GC 時間占用程序運行時間的百分比（不推薦使用）
-XX:MaxGCPauseMillis 停頓時間，是一個建議時間，GC 會嘗試用各種手段達到這個時間，比如減小年輕代
4、G1 常用參數
-XX:+UseG1GC 啟用 CMS 垃圾收集器
-XX:MaxGCPauseMillis 設置最大 GC 暫停時間的目標（以毫秒為單位）。這是一個軟目標，并且 JVM 將盡最大的努力（G1 會嘗試調整 Young 區的塊數來）來實
現它。默認情況下，沒有最大暫停時間值。
-XX:GCPauseIntervalMillis GC 的間隔時間
-XX:+G1HeapRegionSize 分區大小，建議逐漸增大該值，1 2 4 8 16 32。隨著 size 增加，垃圾的存活時間更長，GC 間隔更長，但每次 GC 的時間也會更長
-XX:G1NewSizePercent 新生代最小比例，默認為 5%
-XX:G1MaxNewSizePercent 新生代最大比例，默認為 60%
-XX:GCTimeRatioGC 時間建議比例，G1 會根據這個值調整堆空間
-XX:ConcGCThreads 線程數量
-XX:InitiatingHeapOccupancyPercent 啟動 G1 的堆空間占用比例，根據整個堆的占用而觸發并發 GC 周期
