背景

Golang的垃圾回收器使用的是并行三色標(biāo)記回收算法。該算法對比分代算法的最大問題就是，無法區(qū)分年輕代和老年代對象，如果老年代對象非常多的話，新生代對象的回收效率就會下降。如果程序沒有減慢對象分配速度的話，golang為了避免出現(xiàn)內(nèi)存不足，會強制降低相關(guān)協(xié)程的執(zhí)行速度，擠出cpu幫助垃圾回收。結(jié)果就是程序出現(xiàn)延遲和卡頓，尤其業(yè)務(wù)頻繁的時候。這對游戲玩家來說是非常糟糕的體驗。

有沒有辦法解決這個問題呢？當(dāng)然有，思路很顯然，對象太多就減少對象分配，回收慢就提高回收效率。但是具體怎么操作，又要保證安全，又要保證有可操作性，就很難了。

---

分析

減少對象分配，一個是少創(chuàng)建對象，邏輯層面可以合并一些對象，用值代替指針，都是需要調(diào)整邏輯結(jié)構(gòu)的微觀層面的操作方法，有效但是杯水車薪。

重用對象也能減少分配，首當(dāng)其沖的辦法就是對象池。對象池簡單實用，但是缺點就是太簡陋了。分配的對象類型固定，還要使用者手動放回，而且保證不再操作已放回的對象。這對對象類型非常繁多，關(guān)系非常復(fù)雜的程序來說，可操作性不高。而且如果沒有g(shù)c兜底，對象泄露了也很難捕捉。對于某些大型對象，關(guān)系簡單的情況，效果很好。

提高回收效率的話，golang本身做了很多底層回收優(yōu)化，留給應(yīng)用層的空間不大。針對老生代對象問題，如果能夠讓GC跳過這些對象的掃描，必然節(jié)約很大的開銷。可惜golang沒有直接提供對應(yīng)的支持，唯一發(fā)現(xiàn)的就是go:notinheap標(biāo)記，可惜主要作用是優(yōu)化寫屏障，卡的很死。

還有一個大殺器CGO，CGO調(diào)用C運行庫跳過GC分配內(nèi)存，也跳過了GC掃描，非常好的思路。但是C內(nèi)存對象在go里面使用限制太多，像map這種常用數(shù)據(jù)接口根本沒有對應(yīng)辦法實現(xiàn)，因為不能操作符重載和泛型，結(jié)果就是使用起來太復(fù)雜了。所有的數(shù)據(jù)操作方式都要走C的風(fēng)格，像是回到了遠(yuǎn)古時代，簡直是對高級語言的侮辱。

因為實際情況是，對象數(shù)量確實是減少不了多少的，剩下唯一的辦法只有減少GC或者不GC。其實CGO如果可行的話，對象被搬運到C，既能減少go這邊的大量對象分配，也就減少了GC的壓力，非常完美。可惜差一點就達(dá)成。如果哪天CGO可以像微軟的C++/CLI一樣流暢的跨語言操作.NET，就牛逼了。這點還是不得不佩服微軟的技術(shù)實力。當(dāng)然.NET設(shè)計之初就是為了跨語言而生的，情況有點不一樣。扯遠(yuǎn)了。

回頭來說，有沒有辦法用go實現(xiàn)一個GC透明的分配器呢。

答案是肯定的。

但是，需要考慮幾個問題，是池子加強版嗎？那本質(zhì)還是池子啊！肯定不能是池子，我們要的是一個真正的分配器。他能自己管理內(nèi)存，繞過GC的掃描，能從內(nèi)存中任意分配對象，這才能滿足我們的需求。

---

思路

終于知道我們需要什么了！為了不重復(fù)造輪子，先看看有沒有現(xiàn)成的成熟方案吧。

• https://github.com/shoenig/offheap 太簡陋了，基本等于啥都沒有
• offheap package - github.com/glycerine/offheap - pkg.go.dev 這個好像功能很多，但是好像主要是優(yōu)化hash表，而且還是要手動釋放，接口使用起來有點繁瑣，對老代碼改動太大了。
• https://github.com/cachelot/cachelot好像主要是像cache一樣使用呢，也是要大改代碼

沒有一個符合我們需求的輪子呢，自己擼一個可行嗎？那就試試吧。

純CGO的實現(xiàn)還是算了，用起來麻煩，調(diào)試也麻煩，編譯還賊慢，直接pass。既然選擇golang就是為了方便啊。那就直接用golang實現(xiàn)吧，還能利用golang的高級功能呢！

內(nèi)存不就是byte數(shù)組嗎？這個簡單。怎么把一個地址轉(zhuǎn)成對象呢？unsafe指針強轉(zhuǎn)貌似可以，reflect.NewAt也可以，這個NewAt不就是簡化版C++的placement new嗎？愛了。

分配的對象怎么回收呢？一個個手動放回嗎？那還是洗洗睡吧。干嘛要放回呢？我們是老生代對象，可以永遠(yuǎn)不回收的。配置數(shù)據(jù)就是全局?jǐn)?shù)據(jù)，加載好了永遠(yuǎn)都不用釋放。那就好處理了。

還有一堆新生代對象呢？好多臨時對象，比如發(fā)到網(wǎng)絡(luò)上的包，發(fā)完了就廢棄了。簡單，我直接把整個分配器一起扔了不就可以了，nice。

所以大概的思路就出來了，我就一直分配對象不回收，最后整個分配器一起丟掉。中間只有分配器占用了一個byte數(shù)組對象需要GC掃描，但是因為Go認(rèn)為數(shù)組里面沒有指針，所以就只標(biāo)記數(shù)組頭為可達(dá)，掃描就完成了。目標(biāo)達(dá)成！

注：為什么byte數(shù)組化分出來的對象也是被指針引用，GC就不掃描呢，因為GO的GC是根據(jù)GO分配對象當(dāng)時的對象信息來確定要不要掃描的，細(xì)節(jié)請看go的垃圾回收文檔。雖然有指針引用我們分配的對象，但是從這個指針指向的地址去找heap中對應(yīng)的內(nèi)存塊的時候，找到的是byte數(shù)組，他的對象信息里面是沒有子對象的，因此此處的掃描結(jié)束。

---

實現(xiàn)

這一直分配的方式，熟悉的人一下就發(fā)現(xiàn)是線性分配器。搞C++的游戲開發(fā)不會不知道這些。在C++里面定制分配器簡直就是家常便飯。終于發(fā)現(xiàn)C++搞多了還是有很多好處的。

文章有點長了，長話短說不賣關(guān)子了。要注意的幾點：

• 線性分配器分配的對象對GC是透明的，那就不能把原生分配器分配的對象掛到上面，會被GC認(rèn)為是無人引用的對象回收掉，所以需要能自動識別這種情況。方法就是分配器分配的對象保存下來，通過反射挨個遞歸地從每個對象遍歷子對象，檢查是否有不是分配器分配的內(nèi)存。（用golang來實現(xiàn)的一個好處就是能用golang的反射，COG的方案就沒有這個好處）
• 不能在分配器銷毀后，繼續(xù)使用分配器分配的對象。C++的內(nèi)存診斷工具的做法是把對應(yīng)的內(nèi)存頁設(shè)為不可讀，讀和寫會觸發(fā)硬件中斷。不過這個實現(xiàn)起來有點復(fù)雜，而且內(nèi)存開銷非常大。簡單點的方法，分配器返回id，使用的時候再去取對象，這個需要改變對象的使用方式，對老代碼很不友好。其他簡單實用的方法目前沒有找到，如果在宏觀層面能保證的話，問題也不大。
• 分配器不能分配失敗。簡單，buffer不夠了再加就行了，然后用新buffer繼續(xù)分配。絕對不能使用原生的分配器分配對象再掛到分配器上，因為掛載的過程不一定是gc原子性的(我發(fā)明的詞匯，參考GC safe-point)，坑跟data race一樣隱蔽（不過data race有detector而已）。
• 分配器也可以重用，用完reset丟到池子里面，取出來又是一條好漢。免得頻繁創(chuàng)建分配器，雖然大部分時候go的原生分配器很快，但是高峰的時候就不一定了。（而且有g(shù)olang的gc兜底，忘了放回去也不會有大問題。COG的方案就沒有這個好處）

大的問題都解決了，其他就是小細(xì)節(jié)了，可以參看具體實現(xiàn)：

GitHub - crazybie/linear_ac: Speed up the memory allocation and improve the garbage collection performance.

倉庫還在測試階段不一定穩(wěn)定。等上線了再反饋優(yōu)化一波。但是請放心，上線的項目完全夠壓力。

好了，該睡覺了。仿佛夢見CPU再也不飚了，游戲再也不延遲了，完美。

參考：

• Go內(nèi)存分配
• CGO優(yōu)化內(nèi)存分配
• notinheap介紹

go:notinheapapplies to type declarations. It indicates that a type must never be allocated from the GC'd heap or on the stack. Specifically, pointers to this type must always fail theruntime.inheapcheck. The type may be used for global variables, or for objects in unmanaged memory (e.g., allocated withsysAlloc,persistentalloc,fixalloc, or from a manually-managed span).

• The GC Pacer

If need be, the Pacer slows down allocation while speeding up marking. At a high level the Pacer stops the Goroutine, which is doing a lot of the allocation, and puts it to work doing marking. The amount of work is proportional to the Goroutine’s allocation. This speeds up the garbage collector while slowing down the mutator.

• GitHub - crazybie/linear_ac: Speed up the memory allocation and improve the garbage collection performance.

Go has all goroutines reach a garbage collection safe point with a process calledstop the world. This temporarily stops the program from running and turns awrite barrieron to maintain data integrity on the heap. This allows for concurrency by allowing goroutines and the collector to run simultaneously.

總結(jié)

以上是生活随笔為你收集整理的如何缓解Golang大型游戏服务器的GC压力的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。