GO的垃圾回收器

go語言垃圾回收總體采用的是經典的mark and sweep算法。 （推薦學習：go）

1.3版本以前，golang的垃圾回收算法都非常簡陋，然后其性能也廣被詬病：go runtime在一定條件下（內存超過閾值或定期如2min），暫停所有任務的執行，進行mark&sweep操作，操作完成后啟動所有任務的執行。

在內存使用較多的場景下，go程序在進行垃圾回收時會發生非常明顯的卡頓現象（Stop The World）。在對響應速度要求較高的后臺服務進程中，這種延遲簡直是不能忍受的！這個時期國內外很多在生產環境實踐go語言的團隊都或多或少踩過gc的坑。

當時解決這個問題比較常用的方法是盡快控制自動分配內存的內存數量以減少gc負荷，同時采用手動管理內存的方法處理需要大量及高頻分配內存的場景。

1.3版本開始go team開始對gc性能進行持續的改進和優化，每個新版本的go發布時gc改進都成為大家備受關注的要點。

1.3版本中，go runtime分離了mark和sweep操作，和以前一樣，也是先暫停所有任務執行并啟動mark，mark完成后馬上就重新啟動被暫停的任務了，而是讓sweep任務和普通協程任務一樣并行的和其他任務一起執行。

如果運行在多核處理器上，go會試圖將gc任務放到單獨的核心上運行而盡量不影響業務代碼的執行。go team自己的說法是減少了50%-70%的暫停時間。

1.4版本（當前最新穩定版本）對gc的性能改動并不多。1.4版本中runtime很多代碼取代了原生c語言實現而采用了go語言實現，對gc帶來的一大改變是可以是實現精確的gc。

c語言實現在gc時無法獲取到內存的對象信息，因此無法準確區分普通變量和指針，只能將普通變量當做指針，如果碰巧這個普通變量指向的空間有其他對象，那這個對象就不會被回收。

而go語言實現是完全知道對象的類型信息，在標記時只會遍歷指針指向的對象，這樣就避免了C實現時的堆內存浪費（解決約10-30%）。

1.5版本go team對gc又進行了比較大的改進（1.4中已經埋下伏筆如write barrier的引入）,官方的主要目標是減少延遲。go 1.5正在實現的垃圾回收器是“非分代的、非移動的、并發的、三色的標記清除垃圾收集器”。

分代算法上文已經提及，是一種比較好的垃圾回收管理策略，然1.5版本中并未考慮實現；我猜測的原因是步子不能邁太大，得逐步改進，go官方也表示會在1.6版本的gc優化中考慮。

同時引入了上文介紹的三色標記法，這種方法的mark操作是可以漸進執行的而不需每次都掃描整個內存空間，可以減少stop the world的時間。

由此可以看到，一路走來直到1.5版本，go的垃圾回收性能也是一直在提升，但是相對成熟的垃圾回收系統（如java jvm和javascript v8），go需要優化的路徑還很長（但是相信未來一定是美好的~）。