Go虽然是自动GC类型的语言,但在编码过程中如果不注意,很容易造成内存泄漏的问题。比较常见的是发生在 slice、time.Ticker、goroutine 等的使用过程中,这里结合我们日常中经常遇到的,以及网上搜集到一些Case进行系统性的总结一下,希望对你的日常工作有所帮助。
slice 类型引起内存泄漏
传入的参数被切片返回,导致局部变量不能被释放
Golang是自带GC的,如果资源一直被占用,是不会被自动释放的,比如下面的代码,如果传入的slice b是很大的,然后引用很小部分给全局量a,那么b未被引用的部分就不会被释放,造成了所谓的内存泄漏。
Go
var a []int
func test(b []int) {
a = b[:3]
return
}
想要理解这个内存泄漏,主要就是理解上面的a = b[:3]是一个引用,其实新、旧slice指向的都是同一片内存地址,那么只要全局量a在,b就不会被回收。
如果想避免这个问题,可以使用append方法的实现,如果append的目标slice空间不够,会重新申请一个array来放需要append的内容,所以&b[0]和&a[0]的值是不一样的,而&a[0]和&c[0]地址是一致的:
Bash
time.Sleep(time.Second * 5)
fmt.Println("main func")
var b []int
var c []int
// 现在,如果再没有其它值引用着承载着a元素的内存块,
// 则此内存块可以被回收了。
func test(a []int) {
c = a[:1]
b = append(a[:0:0], a[:1]...) // 秀操作而已,也可以使用nil
fmt.Println(&a[0], &c[0], &b[0]) //0xc0000aa030 0xc0000aa030 0xc0000b2038
}
也可以使用 copy()函数来实现引用类型的深拷贝。copy(dst[], src[])
切片容量导致内存泄漏
假如我们从网络中接受了很大的数据,该协议使用前5个字节标识消息类型。
Go
func consumeMessages() {
msg := receiveMessage() // a
storeMessageType(getMessageType(msg)) //b
// 其他的逻辑处理
}
// 然后msg作为一个参数
func getMessageType(msg []byte) []byte { //c
return msg[:5]
}
我们只想存储每个消息的前5字节代表的消息类型,但同时我们将每条消息的整个容量的数据也存储在了内存中。
解决方式可以使用copy方法,来替代对msg进行切分:
Go
func getMessageType(msg []byte) []byte {
msgType := make([]byte, 5)
copy(msgType, msg)
return msgType
}
数组值传递
由于数组是Golang的基本数据类型,每个数组占用不同的内存空间,生命周期互不干扰,很难出现内存泄漏的情况,但是数组作为形参传输时,遵循的是值拷贝,如果函数被多个goroutine调用且数组过大时,则会导致内存使用激增。
因此对于大数组放在形参场景下通常使用切片或者指针进行传递,避免短时间的内存使用激增。
goroutine导致内存泄漏
Go内存泄露,大部分都是goroutine泄露导致的。 虽然每个goroutine仅占用少量(栈)内存,但当大量goroutine被创建却不会释放时(即发生了goroutine泄露),也会消耗大量内存,造成内存泄露。
另外,如果goroutine里还有在堆上申请空间的操作,则这部分堆内存也不能被垃圾回收器回收。
Go 10次内存泄漏,8次goroutine泄漏,1次是真正内存泄漏,还有1次是cgo导致的内存泄漏 ("才高八斗"的既视感..)
在Go中大概单个goroutine占用2.6k左右的内存空间。
Goroutine 内存泄漏的原因
Go 语言的内存泄漏通常因为错误地使用 goroutine 和 channel。例如以下几种情况:
-
在 goroutine 里打开一个连接(如 gRPC)但是忘记 close。
-
在 goroutine 里的全局变量对象没有释放。
-
在 goroutine 里读 channel, 但是没有写入端,而被阻塞。
-
在 goroutine 里写入无缓冲的 channel,但是由于 channel 的读端被其他协程关闭而阻塞。
-
在 goroutine 里写入有缓冲的 channel,但是 channel 缓冲已满。
-
select操作在所有case上都阻塞,造成内存泄漏
其实本质上还是channel问题, 因为 select..case只能处理 channel类型, 即每个 case 必须是一个通信操作, 要么是发送要么是接收,select 将随机执行一个可运行 case, 如果没有 case 可运行,它将阻塞,直到有 case 可运行。 有个独立 goroutine去做某些操作的场景下,为了能在外部结束它,通常有两种方法:
-
同时传入一个用于控制goroutine退出的 quit channel,配合 select,当需要退出时close 这个 quit channel,该 goroutine 就可以退出
-
使用
context
包的WithCancel,可参考context.WithCancel()
的使用
-
I/O问题,I/O连接未设置超时时间,导致goroutine一直在等待,代码会一直阻塞。
-
互斥锁未释放,goroutine无法获取到锁资源,导致goroutine阻塞
Go
//协程拿到锁未释放,其他协程获取锁会阻塞
func mutexTest() {
mutex := sync.Mutex{}
for i := 0; i < 10; i++ {
go func() {
mutex.Lock()
fmt.Printf("%d goroutine get mutex", i)
//模拟实际开发中的操作耗时
time.Sleep(100 * time.Millisecond)
}()
}
time.Sleep(10 * time.Second)
}
- 死锁,当程序死锁时其他goroutine也会阻塞
Go
func mutexTest() {
m1, m2 := sync.Mutex{}, sync.RWMutex{}
//g1得到锁1去获取锁2
go func() {
m1.Lock()
fmt.Println("g1 get m1")
time.Sleep(1 * time.Second)
m2.Lock()
fmt.Println("g1 get m2")
}()
//g2得到锁2去获取锁1
go func() {
m2.Lock()
fmt.Println("g2 get m2")
time.Sleep(1 * time.Second)
m1.Lock()
fmt.Println("g2 get m1")
}()
//其余协程获取锁都会失败
go func() {
m1.Lock()
fmt.Println("g3 get m1")
}()
time.Sleep(10 * time.Second)
}
- waitgroup使用不当。
waitgroup的Add、Done和wait数量不匹配会导致wait一直在等待。
上面列的情况,在日常开发过程中不容易发现,因此会经常带来一些线上的问题。
select-case误用导致的内存泄露
Go
func TestLeakOfMemory(t *testing.T) {
fmt.Println("NumGoroutine:", runtime.NumGoroutine())
chanLeakOfMemory()
time.Sleep(time.Second * 3) // 等待 goroutine 执行,防止过早输出结果
fmt.Println("NumGoroutine:", runtime.NumGoroutine())
}
func chanLeakOfMemory() {
errCh := make(chan error) // 1
go func() { // (5)
time.Sleep(2 * time.Second)
errCh <- errors.New("chan error") // 2
fmt.Println("finish sending")
}()
var err error
select {
case <-time.After(time.Second): // 3 大家也经常在这里使用 <-ctx.Done()
fmt.Println("超时")
case err = <-errCh: // 4
if err != nil {
fmt.Println(err)
} else {
fmt.Println(nil)
}
}
}
输出结果如下:
Go
NumGoroutine: 2
超时
NumGoroutine: 3
这是 go channel 导致内存泄漏的经典场景。 根据输出结果(开始有两个 goroutine,结束时有三个 goroutine),我们可以知道,直到测试函数结束前,仍有一个 goroutine 没有退出。
原因是由于 1 处创建的 errCh 是不含缓存队列的 channel,如果 channel 只有发送方发送,那么发送方会阻塞;如果 channel 只有接收方,那么接收方会阻塞。
可以看到由于没有发送方往 errCh 发送数据,所以 4 处代码一直阻塞。
直到 3 处超时后,打印"超时",函数退出,4 处代码都未接收成功。
而 2 处的所在的 goroutine 在"超时"被打印后,才开始发送。
由于外部的 goroutine 已经退出了,errCh 没有接收者,导致 2 处一直阻塞。
因此 2 处代码所在的协程一直未退出,造成了内存泄漏。
如果代码中有许多类似的代码,或在 for 循环中使用了上述形式的代码,随着时间的增长会造成多个未退出的 gorouting,最终导致程序 OOM。
这种情况其实还比较简单。我们只需要为 channel 增加一个缓存队列。即把 (1) 处代码改为 errCh := make(chan error, 1) 即可。修改后输出如下所示,可知我们创建的 goroutine 已经退出了。
Go
NumGoroutine: 2
超时
NumGoroutine: 2
可能会有人想要使用 defer close(errCh) 关闭 channel。比如把 1 处代码改为如下形式(错误):
Go
errCh := make(chan error)
defer close(errCh)
由于 2 处代码没有接收者,所以一直阻塞。直到 close(errCh) 运行,2 处仍在阻塞。这导致关闭 channel 时,仍有 goroutine 在向 errCh 发送。然而在 golang 中,在向 channel 发送时不能关闭 channel,否则会 panic。因此这种方式是错误的。
又或在 5 处 goroutine 的第一句加上 defer close(errCh)。由于 2 处阻塞, defer close(errCh) 会一直得不到执行。因此也是错误的。 即便对调 2 处和 4 处的发送者和接收者,也会因为 channel 关闭,导致输出无意义的零值。
for range 导致的协程泄漏
Go
func leakOfMemory_1(nums ...int) {
out := make(chan int)
// sender
go func() {
defer close(out)
for _, n := range nums { // c.
out <- n
fmt.Printf("sender success: %v\n", n)
time.Sleep(time.Second)
}
}()
// receiver
go func() {
ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()
for n := range out { //b.
if ctx.Err() != nil { //a.
fmt.Println("ctx timeout ")
return
}
fmt.Println(n)
}
}()
}
// 单测文件中执行
func TestLeakOfMemory(t *testing.T) {
fmt.Println("NumGoroutine:", runtime.NumGoroutine())
leakOfMemory_1(1, 2, 3, 4, 5, 6, 7)
time.Sleep(3 * time.Second)
fmt.Println("main exit...")
fmt.Println("NumGoroutine:", runtime.NumGoroutine())
}
执行结果如下:
Go
=== RUN TestLeakOfMemory
NumGoroutine: 2
1
sender success: 1
sender success: 2
2
ctx timeout
sender success: 3
main exit...
NumGoroutine: 3
--- PASS: TestLeakOfMemory (3.00s)
PASS
理论上,是不是最开始只有2个goruntine ,实际上执行完出现了3个gorountine。
说明 leakOfMemory_1 里面起码有一个协程没有退出。 因为时间到了,在 a 处,程序就准备退出了,也就是说 b 这个就退出了,没有接收者继续接受 chan 中的数据了。c处往chan 写数据就阻塞了,因此协程一直没有退出,就造成了泄漏。
如何解决上面说的协程泄漏问题? 可以加个管道通知来防止内存泄漏。
goruntine 中 map 并发
map 是引用类型,函数值传值是调用,参数副本依然指向m,因为值传递的是引用,对于共享变量,资源并发读写会产生竞争。 下面的场景在工作中经常遇到(测的时候不容易发现)。
Go
func TestConcurrencyMap(t *testing.T) {
m := make(map[int]int)
go func() {
for {
m[3] = 3
}
}()
go func() {
for {
m[2] = 2
}
}()
//select {}
time.Sleep(10 * time.Second)
}
time.Ticker** 误用造成内存泄漏**
注意:Ticker 和 Timer 是不同的。Timer 只会定时一次,而 Ticker 如果不 Stop,就会一直发送定时。
Go
func TestTickerNormal(t *testing.T) {
ticker := time.NewTicker(time.Second)
defer ticker.Stop() // stop一定不能漏了
go func() {
for {
fmt.Println(<-ticker.C)
}
}()
time.Sleep(time.Second * 3)
fmt.Println("finish")
}
time.After()使用注意事项
看下面的例子:
Go
func TestTimeAfter(t *testing.T) {
defer func() {
fmt.Println(runtime.NumGoroutine())
}()
go func() {
ticker := time.NewTicker(time.Second * 1)
for {
select {
case <-ticker.C:
fmt.Println("hello world")
case <-time.After(time.Second * 3):
fmt.Println("exit")
return
}
}
}()
time.Sleep(time.Second * 5)
fmt.Println("main func")
}
// 输出结果如下
=== RUN TestTimeAfter
hello world
hello world
hello world
hello world
hello world
main func
3
--- PASS: TestTimeAfter (5.00s)
PASS
从输出结果看,程序根本没有打印exit, 也证明了goroutine不是由time.After() 退出,而是函数执行结果退出。
看下关于time.After() 实现原理:After底层是用NewTimer实现, NewTimer(d).C 每次都是 return 了一个新的对象。
Go
func After(d Duration) <-chan Time {
return NewTimer(d).C
}
func NewTimer(d Duration) *Timer {
c := make(chan Time, 1)
t := &Timer{
C: c,
r: runtimeTimer{
when: when(d),
f: sendTime,
arg: c,
},
}
startTimer(&t.r)
return t
}
可以进行如下的修改
Go
func TestTimeAfter(t *testing.T) {
defer func() {
fmt.Println(runtime.NumGoroutine())
}()
idleDuration := time.After(time.Second * 3)
ticker := time.NewTicker(time.Second * 1)
defer ticker.Stop()
for {
select {
case <-ticker.C:
fmt.Println("hello world")
case <-idleDuration:
fmt.Println("exit")
return
}
}
time.Sleep(time.Second * 5)
fmt.Println("main func")
}
下面的这个例子,是经常遇到的一定要注意: 定时器定义位置
Go
func main() {
chi := make(chan int)
go func() {
for {
// 定时器都是新创建的,那么就会造成永久性的泄露。
timer := time.After(10 * time.Second)
select {
case <-ch:
fmt.Println("get it")
case <-timer:
fmt.Println("end")
}
}
}()
for i:= 1; i< 1000000; i++ {
chi <- i
time.sleep(time.Millisecond)
}
}