Go1-20 arena 能手動管理內存了,怎麼用?
大家好,我是煎魚。
最近 Go1.20 中的手動管理內存受到了很多人的關注。衆所周知,Go 是一門帶垃圾回收(GC)的編程語言,可以進行自動的內存申請、釋放等內存操作。
帶 GC 能簡化編程時的心智成本,也保證了內存的安全。我們說 “一般”,也就是有例外。人們說六個,一般都有七個。
Go 的例外就出現了。
Go1.20 arena
新版本 Go1.20,基於 Google 自身的需求,快速通過了實踐,正式支持了 arena,能夠實現手動的內存管理(當前是實驗性特性)。
現在可以通過 GOEXPERIMENT=arenas
環境變量啓用:
GOEXPERIMENT=arenas go run main.go
該特性可以讓程序員手動的從一個連續的內存區域申請、分配一組內存對象,也可以一次性的釋放。
重點是可以手動管理內存。
提供的 arena API
-
NewArena:創建一個新的 arena 內存空間。
-
Free:釋放 arena 及其關聯對象。
-
New:基於 arena,創建新對象。
-
MakeSlice:基於 arena,創建新切片。
-
Clone:克隆一個 arena 的對象,並移動到內存堆上。
一些 arena 例子
以下案例和性能測試是基於 uptrace 在 Golang memory arenas [101 guide][1] 中分享的 arena 例子,本處進行引用,我就不自創一份了。
很適合在初學時作爲 Demo 使用,打算也留着自己下次用時結合文檔翻一番。
arena.NewArena
一起來快速入門。代碼如下:
import "arena"
type T struct{
Foo string
Bar [16]byte
}
func processRequest(req *http.Request) {
// 在函數開頭創建一個 arena
mem := arena.NewArena()
// 在函數結束時釋放 arena
defer mem.Free()
// 從申請的 arena 中申請一些對象
for i := 0; i < 10; i++ {
obj := arena.New[T](mem "T")
}
// 從申請的 arena 中申請切片對象(指定長度和容量)
slice := arena.MakeSlice[T](mem, 100, 200 "T")
}
arena.Clone
如果要單獨使用某個申請出來的對象。可以藉助 Clone 方法進行單獨處理。
如下代碼:
// 創建一個 arena
mem := arena.NewArena()
obj1 := arena.New[T](mem "T") // 分配一個 arena 對象
obj2 := arena.Clone(obj1) // 拷貝一個 arena 上的對象,移動到內存堆上
fmt.Println(obj2 == obj1) // 即使是基於拷貝出來的,兩者並不完全等價
// 釋放 arena,obj1 不可使用,obj2 可正常使用
mem.Free()
釋放了最早申請的 arena,Clone 方法在這裏將會把 obj1 拷貝到新的內存堆上,再賦值給 obj2。後續要單獨用 obj2 就可以繼續使用。
reflect.ArenaNew
也可以結合 arena 和 reflect 兩個標準庫來進行使用。如下代碼:
var typ = reflect.TypeOf((*T)(nil)).Elem()
mem := arena.NewArena()
defer mem.Free()
value := reflect.ArenaNew(mem, typ)
fmt.Println(value.Interface().(*T))
arena.MakeSlice
該方法的常規用法:
arena.MakeSlice[string](mem, length, capacity "string")
如果需要申請一個新切片並追加元素:
slice := arena.MakeSlice[string](mem, 0, 0 "string")
slice = append(slice, "")
需要注意的是,arena 目前不支持 map。但你可以通過泛型來實現類似的效果。
arena.String
原則上 arena 不支持 string。但是我們依然可以通過 unsafe.String 方法的騷操作來變相實現。
如下代碼:
src := "腦子進煎魚了"
mem := arena.NewArena()
defer mem.Free()
bs := arena.MakeSlice[byte](mem, len(src "byte"), len(src))
copy(bs, src)
str := unsafe.String(&bs[0], len(bs))
在申請的 arena 釋放後,該對應的 string 就無法使用了,需要特別注意。
性能表現
這個允許手工管理內存的 arena 的特性是來源於內部,提案也是一路綠燈通過。(懂得懂)。
自述已經爲 Google 許多應用節省了高達 15% 的 CPU 和內存使用量,主要原因是減少了垃圾收集 CPU 時間和堆內存使用量。
經過在 vmihailenco/golang-memory-arenas[2] 項目中實際的性能對比。
沒有用 arena:
/usr/bin/time go run arena_off.go
77.27user 1.28system 0:07.84elapsed 1001%CPU (0avgtext+0avgdata 532156maxresident)k
30064inputs+2728outputs (551major+292838minor)pagefaults 0swaps
使用了 arena:
GOEXPERIMENT=arenas /usr/bin/time go run arena_on.go
35.25user 5.71system 0:05.09elapsed 803%CPU (0avgtext+0avgdata 385424maxresident)k
48inputs+3320outputs (417major+63931minor)pagefaults 0swaps
使用了 arena 的代碼運行速度更快,且使用的內存更少。
總結
Go 的各位大大們在性能優化中,不斷地試圖壓榨 Go 的潛力。現在已經到了手工管理內存的階段了。
實際的測試結果來看,是有作用的。
有興趣的小夥伴可以在 Go1.20 起就開始試用。不過需要注意,該特性由於發現了嚴重的 API 問題(想把 arena 應用到其他的標準庫中,但這是個大事件),社區還需要認真思考後續的發展,現階段處於處於停滯狀態。
從這次提案來看,真的是,內部需求一路猛如虎,直接衝上 master。外部需求就畏畏縮縮了。真雙標?
參考資料
[1]
Golang memory arenas [101 guide]: https://uptrace.dev/blog/golang-memory-arena.html
[2]
vmihailenco/golang-memory-arenas: https://github.com/vmihailenco/golang-memory-arenas/commit/3e88fc3cd3054e214fd401f8d434ee04fd476d2b
關注和加煎魚微信,
你好,我是煎魚,出版過 Go 暢銷書《Go 語言編程之旅》,再到獲得 GOP(Go 領域最有觀點專家)榮譽,點擊藍字查看我的出書之路。
日常分享高質量文章,輸出 Go 面試、工作經驗、架構設計,加微信拉讀者交流羣,和大家交流!
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/mwWMOwLsiY8EtODpyEoTIg