圖解Golang的GC演算法
雖然Golang的GC自打一開始，就被人所詬病，但是經過這麼多年的發展，Golang的GC已經改善了非常多，變得非常優秀了。
以下是Golang GC演算法的里程碑：
- v1.1 STW
- v1.3 Mark STW, Sweep 並行
- v1.5 三色標記法
- v1.8 hybrid write barrier
經典的GC演算法有三種： 引用計數(reference counting) 、 標記-清掃(mark & sweep) 、 複製收集(Copy and Collection) 。
Golang的GC演算法主要是基於 標記-清掃(mark and sweep) 演算法，並在此基礎上做了改進。因此，在此主要介紹一下 標記-清掃(mark and sweep)演算法 ，關於 引用計數(reference counting) 和 複製收集(copy and collection) 可自行百度。
標記-清掃(Mark And Sweep)演算法
此演算法主要有兩個主要的步驟：
- 標記(Mark phase)
- 清除(Sweep phase)
第一步，找出不可達的物件，然後做上標記。
第二步，回收標記好的物件。
操作非常簡單，但是有一點需要額外注意： mark and sweep 演算法在執行的時候，需要程式暫停！即 stop the world 。
也就是說，這段時間程式會卡在哪兒。故中文翻譯成 卡頓 。
我們來看一下圖解：
開始標記，程式暫停。程式和物件的此時關係是這樣的：
然後開始標記，process找出它所有可達的物件，並做上標記。如下圖所示：
標記完了之後，然後開始清除未標記的物件：
然後 垃圾 清除了，變成了下圖這樣。
最後，停止暫停，讓程式繼續跑。然後迴圈重複這個過程，直到 process 生命週期結束。
標記-清掃(Mark And Sweep)演算法存在什麼問題？
標記-清掃(Mark And Sweep)演算法 這種演算法雖然非常的簡單，但是還存在一些問題：
- STW，stop the world；讓程式暫停，程式出現卡頓。
- 標記需要掃描整個heap
- 清除資料會產生heap碎片
這裡面最重要的問題就是：mark-and-sweep 演算法會暫停整個整個程式。
Go是如何面對並這個問題的呢？
三色併發標記法
我們先來看看Golang的三色標記法的大體流程。
首先：程式建立的物件都標記為白色。
gc開始：掃描所有可到達的物件，標記為灰色
從灰色物件中找到其引用物件標記為灰色，把灰色物件本身標記為黑色
監視物件中的記憶體修改，並持續上一步的操作，直到灰色標記的物件不存在
此時，gc回收白色物件。
最後，將所有黑色物件變為白色，並重復以上所有過程。
好了，大體的流程就是這樣的，讓我們回到剛才的問題：Go是如何解決 標記-清除(mark and sweep) 演算法中的卡頓(stw，stop the world)問題的呢？
gc和使用者邏輯如何並行操作？
標記-清除(mark and sweep)演算法的STW(stop the world)操作，就是runtime把所有的執行緒全部凍結掉，所有的執行緒全部凍結意味著使用者邏輯是暫停的。這樣所有的物件都不會被修改了，這時候去掃描是絕對安全的。
Go如何減短這個過程呢？標記-清除(mark and sweep)演算法包含兩部分邏輯：標記和清除。
我們知道Golang三色標記法中最後只剩下的黑白兩種物件，黑色物件是程式恢復後接著使用的物件，如果不碰觸黑色物件，只清除白色的物件，肯定不會影響程式邏輯。所以： 清除操作和使用者邏輯可以併發。
標記操作和使用者邏輯也是併發的，使用者邏輯會時常生成物件或者改變物件的引用，那麼標記和使用者邏輯如何併發呢？
process新生成物件的時候，GC該如何操作呢？不會亂嗎？
我們看如下圖，在此狀態下：process程式又新生成了一個物件，我們設想會變成這樣：
但是這樣顯然是不對的，因為按照三色標記法的步驟，這樣新生成的物件A最後會被清除掉，這樣會影響程式邏輯。
Golang為了解決這個問題，引入了 寫屏障 這個機制。
寫屏障：該屏障之前的寫操作和之後的寫操作相比，先被系統其它元件感知。
通俗的講：就是在gc跑的過程中，可以監控物件的記憶體修改，並對物件進行重新標記。(實際上也是超短暫的stw，然後對物件進行標記)
在上述情況中， 新生成的物件，一律都標位灰色！
即下圖：
那麼，灰色或者黑色物件的引用改為白色物件的時候，Golang是該如何操作的？
看如下圖，一個黑色物件引用了曾經標記的白色物件。
這時候，寫屏障機制被觸發，向GC傳送訊號，GC重新掃描物件並標位灰色。
因此，gc一旦開始，無論是建立物件還是物件的引用改變，都會先變為灰色。