首頁 >後端開發 >Golang >你或許聽過對Golang map做GC？

你或許聽過對Golang map做GC？

藏色散人轉載: 2021-08-13 14:26:462594瀏覽

在 Golang# 中的 map 結構，在刪除鍵值對的時候，並且不會真正的刪除，而是標記。那麼隨著鍵值對越來越多，會不會造成大量記憶體浪費呢？

首先答案是會的，很有可能導致 OOM，而且針對這個還有一個討論：github.com/golang/go/issues/20135。大致的意思就是在很大的 map 中，delete 操作沒有真正釋放記憶體而可能導致記憶體 OOM。

所以一般的做法：就是 重建map。而 go-zero 中內建了 safemap 的容器元件。 safemap 在一定程度上可以避免這種情況發生。

那首先我們來看看 go 原生提供的 map 是怎麼刪除的？

原生map刪除

1  package main
2
3  func main() {
4      m := make(map[int]string, 9)
5      m[1] = "hello"
6      m[2] = "world"
7      m[3] = "go"
8
9      v, ok := m[1]
10     _, _ = fn(v, ok)
11
12     delete(m, 1)
13  }
14
15 func fn(v string, ok bool) (string, bool) {
16     return v, ok
17 }

測試程式碼如上，我們可以透過go tool compile -S -N -l testmap.go | grep "CALL" ：

0x0071 00113 (test/testmap.go:4)        CALL    runtime.makemap(SB)
0x0099 00153 (test/testmap.go:5)        CALL    runtime.mapassign_fast64(SB)
0x00ea 00234 (test/testmap.go:6)        CALL    runtime.mapassign_fast64(SB)
0x013b 00315 (test/testmap.go:7)        CALL    runtime.mapassign_fast64(SB)
0x0194 00404 (test/testmap.go:9)        CALL    runtime.mapaccess2_fast64(SB)
0x01f1 00497 (test/testmap.go:10)       CALL    "".fn(SB)
0x0214 00532 (test/testmap.go:12)       CALL    runtime.mapdelete_fast64(SB)
0x0230 00560 (test/testmap.go:7)        CALL    runtime.gcWriteBarrier(SB)
0x0241 00577 (test/testmap.go:6)        CALL    runtime.gcWriteBarrier(SB)
0x0252 00594 (test/testmap.go:5)        CALL    runtime.gcWriteBarrier(SB)
0x025c 00604 (test/testmap.go:3)        CALL    runtime.morestack_noctxt(SB)

執行第12行的delete，實際執行的是runtime.mapdelete_fast64。

這些函數的參數型別是具體的int64，mapdelete_fast64 跟原始的delete 運算一樣的，所以我們來看看mapdelete。