雖然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一旦開始,無論是建立物件還是物件的引用改變,都會先變為灰色。
參考文獻: