Go 1.4+垃圾收集器計劃與路線圖

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

自從Go語言於2009年11月對外宣布以來，短短几年時間，這門語言發展迅猛，效能也在不斷提升，而垃圾收集器的改進正是其中的重要一環。

在Go 1.1中，Go語言引入了並行垃圾收集器，可以減少程式在多CPU上運行時的延遲；同時垃圾收集也更為精確了，以犧牲較少的CPU時間為代價，換來了堆記憶體的顯著減少。到了今年6月份發布的Go 1.3中，精確性有所改進，又實現了檢查棧上的值時的精確性。

那後續版本中，垃圾收集器會有怎樣的變化呢？Richard L. Hudson近日撰文介紹了Go 1.4+垃圾收集器的計劃和路線圖。

文中指出，計劃於2015年6月發布的Go 1.5的GC的目標是減少延遲，從而使Go語言能夠滿足對回應時間要求比較高的系統。該版本希望將GC延遲限制在10ms以內，而且每50ms保證Go應用代碼有40ms以上的執行時間。實現上將考慮一種混合式的Stop-the-World（STW）/並發垃圾收集器（CGC）。CGC的主要工作將在一個或多個專用的CPU上完成，而應用代碼則在其他CPU上執行。

文中提到，用繁複的垃圾收集術語來講，現在為Go 1.5提議的垃圾收集器是一種“非分代的、非移動的、並發的、三色的標記清除垃圾收集器”。像分代，JVM的Hotspot實現、Google的v8 JavaScript引擎等採用的就是分代垃圾收集技術。Hotspot中的堆區分為年輕代和老年代，不同的代會針對性地選擇不同的收集演算法。移動對象是複製類垃圾收集演算法常用的一種操作，不過移動有一個缺點，需要修改指向被複製對象的所有指標。三色是GC跟蹤過程中的一種標記策略，認定為活對象的標記為黑色，可能是死對象的標記為白色；可以參考這個文章。正在處理或者需要重新處理的標記為灰色。標記完成之後，仍為白色的則是垃圾。具體演算法，感興趣的讀者可以參考《The Garbage Collection Handbook: The Art of Automatic MemoryManagement》一書。低延遲意味著會影響輸送量，但是影響程度如何，還有待觀察。文中指出，隨著CPU核心數的增加，拿出一個或多個核來執行GC，應該不是很大的問題。

至於Go 1.6這個將於2015年12月發布的版本，其GC將根據1.5版本的經驗、使用者反饋和使用案例來改進。1.6版本很可能會加入指標碰撞分配（bump pointer allocation）和分代複製收集技術。

為配合垃圾收集器的改造，1.4版本中將去掉使用了Go指標及各種與並發或複製收集器不相容的不安全指標結構的C運行時代碼，使用者也需要去掉其代碼中的不相容結構。

相關討論可以參閱golang-dev郵件清單。HackerNews上的討論也很熱烈。有些網友介紹了實際使用體驗。感興趣的讀者可以參考。