点击上方蓝色“Go语言中文网”关注我们,领全套Go资料,每天学习 Go 语言
本文作者:曹春晖 Xargin
原文链接:https://xargin.com/logic-of-slice-memory-leak/
Go 101 总结了几个可能导致内存泄露的场景:
https://gfw.go101.org/article/memory-leaking.html
goroutine 阻塞在 channel,time.Ticker 不使用但未 stop,以及 for 循环里用 defer 导致泄露,这三个场景其实已经比较常见了,这里就不说了。
我们来看看子切片截取为什么会导致内存泄露。
因为 Go 是一门带 GC 的语言,虽然官方宣传 GC stw 在 1ms 以内,但服务的延迟并不仅仅取决于 stw,用户的 goroutine 如果触发了堆上分配内存的操作,也很有可能进入到协助标记流程(newobject->mallocgc->gcAssist),这个“协助标记”也会导致相应的用户 goroutine 延迟大幅度上升。我们总会听到有人吹 stw 1ms 以内没有影响,这其实是一个相当不负责的结论。目前 Go 的实现只是把 GC 的成本进行了均摊,例如标记成本有一部分被均摊给了用户的 goroutine。
GC 优化在高并发的场景下是一定有必要的。通过减少堆上创建的对象来降低标记的压力,一方面可以节省 GC 整体使用的 CPU,最终也就大幅缩减了用户服务的延迟,那些说不用优化的笑笑就好。
在优化 GC 时,最直接的思路就是对创建对象进行复用,官方提供了 sync.Pool 来帮助用户对他们的应用对象进行复用。这里看 Go 的基本类型:map 和 slice。
sync.Pool 在复用对象时,需要我们在 Get 或 Put 时对对象进行清空操作,这个清空是由用户完成的,对于一个 slice 来说,清空操作很简单:sl := sl[:0]
。但对于一个 map 来说,就没这么简单了。虽然官方对清空 map 也进行了一些优化:这里[1] 和 这里[2]。不过显然 map 依然不是一个适合复用的结构。
因为 slice 相比 map 要容易复用,在性能敏感的场景,只要能用 slice 来代替 map 就都换成了 slice + sync.Pool 来进行复用,fasthttp 里有很多这方面的实践,之前也有人做了比较好的总结,参考 这里[3] 和 这里[4]。
嗯,既然知道了 slice 很方便复用,大家都喜欢它,来看看为什么 slice 的复用可能会造成内存泄露。
下面这段程序是这位[5] 朋友提供的 demo 的改版:
package main
import (
"fmt"
"runtime"
"time"
)
type P struct {
Age int
}
func getPartOfSlice() []*P {
var s = make([]*P, 0, 10000)
for i := 0; i < 10000; i++ {
var p = &P{i}
runtime.SetFinalizer(p, func(x *P) { println("gc happen on p", x) })
s = append(s, p)
}
return s[100:101]
}
func main() {
var k = getPartOfSlice()
// type 1
// print then gc
//fmt.Println(k[0])
//runtime.GC()
// type 2
// gc then print
runtime.GC()
fmt.Println(k[0])
time.Sleep(time.Hour)
}
type 1 表示在 runtime.GC 的时候,已经没有代码持有 k 的引用了,而 type 2 则表示在发生 GC 时,k 依然被持有。
显而易见,只要你持有子切片的某个对象,大切片被截掉的那些元素就是没有办法进行回收的。大概是下面这样:
在引用 slice 时要特别小心,因为有些 slice 的大小是动态生成的(比如可能依赖外部参数),所以也可能 99.99% 的 slice 大小在 <10,但只要有几个大 slice 就导致你的应用程序占用内存大幅增加,如果 slice 的大小依赖于用户输入,甚至会导致发生偶发的 OOM。
这个坑踩的人很多,比如:
writev 的 leak[6]
获得了“官方自己都会踩的 Go 语言”坑认证。
如果你的 slice 大小是用户输入决定的,在往 pool 里放的时候,应该提前判断一下 slice 的容量,否则即使能够复用,也始终有一部分内存空间是浪费掉的。
参考资料
[1]:0]`。但对于一个 map 来说,就没这么简单了。虽然官方对清空 map 也进行了一些优化:[这里: https://github.com/golang/go/issues/20138
[2]这里: https://go-review.googlesource.com/c/go/+/110055/
[3]这里: https://cbsheng.github.io/posts/fasthttp源码最佳实践分析/
[4]这里: https://www.zhihu.com/question/327580797
[5]这位: https://www.zhihu.com/people/xtlisk
[6]writev 的 leak: https://github.com/golang/go/pull/32138
推荐阅读
线上真实场景:实战 Goroutine 泄露排查
喜欢本文的朋友,欢迎关注“Go语言中文网”:
Go语言中文网启用微信学习交流群,欢迎加微信:274768166,投稿亦欢迎