Skip to Content

Discover-sync.Pool

Posted on

其实很久之前就用到了这个东西,起因是collecter程序占用太多内存了,然后就用sync.Pool复用额外消耗的一次性内存,避免GC周期太长使内存来不及释放而导致的OOM。

https://golang.org/pkg/sync/#Pool

简单的说,就是在一个池子里放了一些“东西”,这些东西是某种特殊的类型,用的时候需要指定。

池子会随着你的取用而扩张,比如说,池子里面放了扳手(扳手池),现在有10个工人依次取用,当第一个人取的时候,“扳手池”发现没有扳手,ok,new一个出来; 当第一个工人用完了的时候,把扳手放回扳手池,然后第二个人取的时候,扳手池就直接返回那个扳手就可以了。嗯……如果第一个工人没有归还呢,那么扳手池就要重新new一个扳手了,也就是这种情况:10个工人同时取用扳手,那么扳手池就得new10个新的出来了。

一个测试:

https://gist.github.com/wrfly/7de7f1e0c87860aa2f92dc6ed64cb75b

Makefile:

.PHONY: build run test
NAME := $(shell basename `pwd`)

build:
	go build

run:
	./$(NAME)

test: build run
	go tool pprof -lines $(NAME) mem.porf

上面那个gist中,有几个测试,在这种情况下:

	wg.Add(alloc)
	for i := 0; i < alloc; i++ {
		go func(num int) {
			// justMake()
			// bufPoolGet()
			bufPoolGetAndPut(num)
			// bufPoolSleepAndGetAndPut(num)
			wg.Done()
		}(i)
	}

也就是拿了接着放回去的时候,结果如下:

➜  syncPool_mem_usage_test make run
go build
./syncPool_mem_usage_test
newmake: 4
reused: 9996
reused slice(maybe equal to newmake) len: 0
➜  syncPool_mem_usage_test 

也就是说,新分配了4个1e6长度的[]byte,其余的都是复用的。

但是这里有要注意的是,如果将 buf 中的内容打印出来(上面的num),reuse的效率就会下降几个数量级了,我还试过用append的方式将复用的内容追加到某个地方,复用的buf也会减少很多很多,分析原因,认为不论是print还是append都会占用时间,影响了Put的效率,从而Get的时候就Get慢了,就new了新的出来。

嗯,其实上面是为了测试Pool里面到底存了多少东西,是把所有put进去的都存了,还是只存了最后put进去的。

该程序最后加了这么一段:

	for i := 0; i < alloc; i++ {
		b := bufPool.Get()
		buf := b.([]byte)
		if buf[0] != 0 {
			fmt.Printf("reuse %s", buf)
		}
	}

发现结果跟理论有很大出入,按理说应该打印make的那几个,但有时候回打印,有时候就没有。

➜  syncPool_mem_usage_test make run
go build
./syncPool_mem_usage_test
reuse [2]
reuse [175]
reuse [174]
reuse [210]
newmake: 13
reused: 9987
reused slice(maybe equal to newmake) len: 4
➜  syncPool_mem_usage_test 

应该是被整没了:

// Any item stored in the Pool may be removed automatically at any time without
// notification. If the Pool holds the only reference when this happens, the
// item might be deallocated.
//

所以放里面的东西并不保险,内存是会省的,但东西会丢。

所以说,池子里面的东西,会丢,比如new了10个扳手,再用的时候里面也许就只有8个了,有两个被销毁了(be removed automatically at any time without notification)(也是够狠的),然后就找不到他们了,想再用的话,就只能new新的。

gist中还有不同的测试,最主要的是对内存消耗的测试。其实不用测也知道,GetAndPut是最省内存的,上面只是验证理论,毕竟不能别人说啥就是啥,是吧。

感兴趣的同学可以把代码和Makefile都跑一跑,在我这里:

  • justMake用了148.59MB
  • bufPoolGet用了27.02MB
  • bufPoolGetAndPut用了1.13MB
  • bufPoolSleepAndGetAndPut用了332.07MB|282.54MB|16137.43kB|56.28MB 总之结果差异很大…… 可能是时间的原因,没验证(但这个结果的确很蹊跷,值得深究)

消耗不了多少内存。

结论

在高并发的情况下,使用sync.Pool能够节省内存.

comments powered by Disqus