本章主要是對上一篇文章講的垃圾回收機制的擴展，垃圾回收其實本身是有很多可以優化的點的，本章就進行對這些優化點進行介紹。

1.GC Roots遍歷提升效率

以往做法

當垃圾回收器線程進行GC時， 第一步需要 「找到GC Roots」 ；第二步通過GC Roots進行 「遍歷堆中引用GC Roots的對象形成引用鏈」 ；第三步，將不在引用鏈中的對象標記進行 「標記」 （需要回收的對象），或者 「標記」 引用鏈中的對象（需要復制，整理的對象），具體標記哪種對象根據堆中的分代內存不同和采用的垃圾回收算法來確定。

可優化地方以及優化原理

上述過程第二步中遍歷堆中引用GC Roots的對象，這部分隨著堆內存的越來越大需要的時間也會逐步增長。如果能夠提前知道堆中哪部分內存是引用，來判斷是否引用GC Roots這樣效率是不是會更高一些。

沒錯，因為之前講過從Exact VM開始就已經采用了準確式內存管理即知道哪部分內存是引用；而且在即時編譯的過程中我也會知道棧中或者寄存器里哪部分內存是引用。這個時候我用一個數據結構來存儲這些信息，在第二步中就不需要遍歷整個堆了，只需要遍歷沒有標識引用內存的地方（也就是剛才數據結構中沒有存儲的信息）。

在HotSpot中使用OopMap這個數據結構來存儲這信息，也就是可以顯著提高GC Roots遍歷的效率，但是在什么位置放這些信息呢？

2.提升了GC Roots遍歷效率卻不知道怎么安插？

前面提到過通過一個OopMap數據結構能夠提升遍歷效率，但是OopMap中的數據在不同的地方內容是不一樣的（比如每個方法里面我的局部變量表里面的內容可能是不一樣的），所以 我為每個指令附近都放一個OopMap 。

?

等等，這樣未免也太浪費內存了吧~。

?

沒錯，所以我們得先辦法把它放到合適的地方！嗯沒錯，我想想： **「這個數據結構的出現是為了優化GC第二步的效率出現的，也就是說只有GC時在放這些數據就行了~。思路找到了，但是什么時候發生GC呢？

發生GC這個時間我不能確定，但是我可以確定的是它遍歷堆中內存的時候必須要進行STW【否則如果在標記的過程中堆中引用發生變化就會導致標記結果出錯】（2.1中講解），我指定只有代碼中執行執行到某個地方才可以進行STW這樣我就可以間接的實現我的目的」** 。

也就是說當GC發生時，只有執行到某個地方才會進行STW，然后我在這個地方附近放上這么一個OopMap的數據結構，然后加快第二步的效率。

「這個某個地方其實名字叫做“safePoint”」 ，顧名思義安全點，只有代碼執行到安全點附近才可以進行STW垃圾收集，而只要將OopMap安插到安全點附近就行。

2.1為什么需要STW？

上面提到過：

?

【否則如果在標記的過程中堆中引用發生變化就會導致標記結果出錯】

?

一，三色標記法

接下來用三色標記法進行解釋如果沒有STW會發生什么情況：一，先解釋三色標記法：

二，沒有STW出現的情況

在這里插入圖片描述

三，解決方案

上面那種異常情況必須同時滿足兩個條件：1.灰色對象不引用白色對象 2.黑色讀寫引用白色對象

因此，只要讓其中一個條件不滿足即可，因此出現了兩種解決方案：1.增量更新：這種方案是讓第二個條件不滿足，即當黑色對象引用白色對象時，將這個黑色對象保存下來，等掃描結束后，再次取出黑色對象進行掃描，可以簡單理解為如果黑色對象引用了百世對象就會被標記為灰色。

2.原始快照：當灰色對象刪除白色對象的引用時，將這個灰色對象記錄下來，等到掃描結束后，在對這些灰色對象為根進行掃描，簡單理解為：不管是否刪除與否都會按照第一次剛開始的引用關系圖進行掃描。

?

CMS垃圾回收器采用增量更新來進行并發標記，G1,Shenandoah采用原始快照

?

3.safePoint我又該放到哪里？

safePoint上面解釋過了，但是我該在哪里放置safePoint呢？放的多了會導致GC收集過于頻繁增加運行時內存壓力，放的少了又會因為堆中不斷增加使用的內存而沒有及時回收堆里面內存導致垃圾收集器等待時間過長。

這樣，我定義一個規則，只有這種**“會讓程序長時間運行的指令”**特征我才會進行安插safePoint，但是這個特征“長時間”并沒有具體的定義，但是卻有“指令序列復用”這樣的含義。比如方法調用，循環調整，異常跳轉這些，只有這些指令附近才會安插safePoint。

safePoint位置選好了，但是上個問題說過執行到safePoint中需要進行STW，發生GC時，我該如何快速跑到safePoint附近進行STW？還有我這個STW該怎么實現呢？

4.如何實現STW？

首先解釋為什么叫做STW，全稱“Stop the Word”，因為 「通過GC Roots遍歷堆中內存的過程其內存里面的引用關系不能發生變化」 ，所以需要暫停所有的用戶線程操作來保障Gc Roots形成的引用鏈是正確的即待會標記過程不會出錯。

讓所有線程都暫停，這個“看起來復雜其實并不簡單”的操作其實有兩種方式處理：一，搶先式中斷：

?

垃圾收集器收集時，系統將所有用戶線程都中斷。當發現不在safePoint附近的線程時先讓他恢復運行直至跑到safePoint附近。這種方式現在幾乎沒有虛擬機采用這種方式來響應GC。

?

二，主動式中斷：

?

我不直接對我的用戶線程操作，當發生GC時，我給用戶線程設立個標志位，用戶線程執行的時候不斷輪詢這個標志位，如果輪詢到了那么我將自己中斷我自己的運行，由于這種方式是輪詢到就立馬進行掛起所以將輪詢的地方和safePoint的地方重合。

?

優化

“不斷輪詢標志位”這句話聽起來就很耗時哈哈，那么再虛擬機中是怎么優化的呢?還有輪詢之后的操作我自己掛起我自己這個又是怎么實現的？

等等，我不放到下一個問題里面講了，直接一遍過：

輪詢標志位這個操作其實就是一條匯編指令，（對于匯編和JAVA是什么關系，之前也有講到過，辛苦翻閱前面文章~） 這條匯編指令的意思就是當我輪詢到需要中斷線程的標志位的時候：我會將其中一個內存頁設置為不可讀，這會導致產生一個自陷異常信號，異常處理器中接受到后進行主動中斷操作。