golang gc 問題(轉的)

 

在實際使用go語言的過程當中，碰到了一些看似奇怪的內存佔用現象，因而決定對go語言的垃圾回收模型進行一些研究。本文對研究的結果進行一下總結。

什麼是垃圾回收？

曾幾什麼時候，內存管理是程序員開發應用的一大難題。傳統的系統級編程語言（主要指C/C++）中，程序員必須對內存當心的進行管理操做，控制內存的申請及釋放。稍有不慎，就可能產生內存泄露問題，這種問題不易發現而且難以定位，一直成爲困擾開發者的噩夢。如何解決這個頭疼的問題呢？過去通常採用兩種辦法：

• 內存泄露檢測工具。這種工具的原理通常是靜態代碼掃描，經過掃描程序檢測可能出現內存泄露的代碼段。然而檢測工具不免有疏漏和不足，只能起到輔助做用。
• 智能指針。這是c++中引入的自動內存管理方法，經過擁有自動內存管理功能的指針對象來引用對象，是程序員不用太關注內存的釋放，而達到內存自動釋放的目的。這種方法是採用最普遍的作法，可是對程序員有必定的學習成本（並不是語言層面的原生支持），並且一旦有忘記使用的場景依然沒法避免內存泄露。

爲了解決這個問題，後來開發出來的幾乎全部新語言（java，python，php等等）都引入了語言層面的自動內存管理 – 也就是語言的使用者只用關注內存的申請而沒必要關心內存的釋放，內存釋放由虛擬機（virtual machine）或運行時（runtime）來自動進行管理。而這種對再也不使用的內存資源進行自動回收的行爲就被稱爲垃圾回收。

常見的垃圾回收方法

引用計數（reference counting）

這是最簡單的一種垃圾回收算法，和以前提到的智能指針殊途同歸。對每一個對象維護一個引用計數，當引用該對象的對象被銷燬或更新時被引用對象的引用計數自動減一，當被引用對象被建立或被賦值給其餘對象時引用計數自動加一。當引用計數爲0時則當即回收對象。

這種方法的優勢是實現簡單，而且內存的回收很及時。這種算法在內存比較緊張和實時性比較高的系統中使用的比較普遍，如ios cocoa框架，php，python等。簡單引用計數算法也有明顯的缺點：

• 頻繁更新引用計數下降了性能。一種簡單的解決方法就是編譯器將相鄰的引用計數更新操做合併到一次更新；還有一種方法是針對頻繁發生的臨時變量引用不進行計數，而是在引用達到0時經過掃描堆棧確認是否還有臨時對象引用而決定是否釋放。等等還有不少其餘方法，具體能夠參考這裏。
• 循環引用問題。當對象間發生循環引用時引用鏈中的對象都沒法獲得釋放。最明顯的解決辦法是避免產生循環引用，如cocoa引入了strong指針和weak指針兩種指針類型。或者系統檢測循環引用並主動打破循環鏈。固然這也增長了垃圾回收的複雜度。

標記-清除（mark and sweep）

該方法分爲兩步，標記從根變量開始迭代得遍歷全部被引用的對象，對可以經過應用遍歷訪問到的對象都進行標記爲「被引用」；標記完成後進行清除操做，對沒有標記過的內存進行回收（回收同時可能伴有碎片整理操做）。這種方法解決了引用計數的不足，可是也有比較明顯的問題：每次啓動垃圾回收都會暫停當前全部的正常代碼執行，回收是系統響應能力大大下降！固然後續也出現了不少mark&sweep算法的變種（如三色標記法）優化了這個問題。

分代收集（generation）

通過大量實際觀察得知，在面向對象編程語言中，絕大多數對象的生命週期都很是短。分代收集的基本思想是，將堆劃分爲兩個或多個稱爲 代（generation）的空間。新建立的對象存放在稱爲 新生代（young generation）中（通常來講，新生代的大小會比 老年代小不少），隨着垃圾回收的重複執行，生命週期較長的對象會被 提高（promotion）到老年代中。所以，新生代垃圾回收和老年代垃圾回收兩種不一樣的垃圾回收方式應運而生，分別用於對各自空間中的對象執行垃圾回收。新生代垃圾回收的速度很是快，比老年代快幾個數量級，即便新生代垃圾回收的頻率更高，執行效率也仍然比老年代垃圾回收強，這是由於大多數對象的生命週期都很短，根本無需提高到老年代。

GO的垃圾回收器

go語言垃圾回收整體採用的是經典的mark and sweep算法。

• 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須要優化的路徑還很長（可是相信將來必定是美好的~）。

實踐經驗

團隊在實踐go語言時一樣碰到最多和最棘手的問題也是內存問題（其中gc爲主），這裏把遇到的問題和經驗總結下，歡迎你們一塊兒交流探討。

go程序內存佔用大的問題

這個問題在咱們對後臺服務進行壓力測試時發現，咱們模擬大量的用戶請求訪問後臺服務，這時各服務模塊能觀察到明顯的內存佔用上升。可是當中止壓測時，內存佔用並未發生明顯的降低。花了很長時間定位問題，使用gprof等各類方法，依然沒有發現緣由。最後發現原來這時正常的…主要的緣由有兩個，

一是go的垃圾回收有個觸發閾值，這個閾值會隨着每次內存使用變大而逐漸增大（如初始閾值是10MB則下一次就是20MB，再下一次就成爲了40MB…），若是長時間沒有觸發gc go會主動觸發一次（2min）。高峯時內存使用量上去後，除非持續申請內存，靠閾值觸發gc已經基本不可能，而是要等最多2min主動gc開始才能觸發gc。

第二個緣由是go語言在向系統交還內存時只是告訴系統這些內存不須要使用了，能夠回收；同時操做系統會採起「拖延症」策略，並非當即回收，而是等到系統內存緊張時纔會開始回收這樣該程序又從新申請內存時就能夠得到極快的分配速度。

gc時間長的問題

對於對用戶響應事件有要求的後端程序，golang gc時的stop the world兼職是噩夢。根據上文的介紹，1.5版本的go再完成上述改進後應該gc性能會提高很多，可是全部的垃圾回收型語言都不免在gc時面臨性能降低，對此咱們對於應該儘可能避免頻繁建立臨時堆對象（如&abc{}, new, make等）以減小垃圾收集時的掃描時間，對於須要頻繁使用的臨時對象考慮直接經過數組緩存進行重用；不少人採用cgo的方法本身管理內存而繞開垃圾收集，這種方法除非無可奈何我的是不推薦的（容易形成不可預知的問題），固然無可奈何的狀況下仍是能夠考慮的，這招帶來的效果仍是很明顯的~

goroutine泄露的問題

咱們的一個服務須要處理不少長鏈接請求，實現時，對於每一個長鏈接請求各開了一個讀取和寫入協程，所有采用endless for loop不停地處理收發數據。當鏈接被遠端關閉後，若是不對這兩個協程作處理，他們依然會一直運行，而且佔用的channel也不會被釋放…這裏就必須十分注意，在不使用協程後必定要把他依賴的channel close並經過再協程中判斷channel是否關閉以保證其退出。