Pool：对象池源码解读

Pool

针对场景

如果你创建的对象过多，那么触发GC的频率会变高、GC的执行时间会变长，所以如果想开发一个高性能应用的话，就需要将经常使用的对象池化减少对象的创建

注意：

垃圾回收时会回收Pool里面的对象
syncPool本身就是线程安全的，多个goroutine可以并发存取对象
syncPool不可复制使用

源码解析

数据结构

Pool的数据结构如下：

Pool对象
local：[P]poolLocal，P大小的poolLocal数组
victim：上一个周期的local数组

poolLocalInternal对象
private interface{}：只能由相应的P使用
shared poolChain：本地P可以pushHead/popHead; 任意的P可以 popTail

poolChainElt对象
poolDequeue poolDequeue：poolDequeue is a lock-free fixed-size single-producer,
multi-consumer queue. The single producer can both push and pop from the head, and consumers can pop from the tail.单个生产者就是本地P，多个消费者就是其他的P

池对象回收(poolCleanup)

在垃圾回收开始时的STW期间执行，在 sync package init 的时候注册，由 runtime 后台执行，内容就是批量清理 allPools 里的元素。

func poolCleanup() {// 清理 oldPools 上的 victim 的元素for _, p := range oldPools {p.victim = nilp.victimSize = 0}// 把 local cache 迁移到 victim 上；// 这样就不致于让 GC 把所有的 Pool 都清空了，有 victim 再兜底以下，这样可以防止抖动；for _, p := range allPools {p.victim = p.localp.victimSize = p.localSizep.local = nilp.localSize = 0}// 清理一波所有的 allPoolsoldPools, allPools = allPools, nil
}

victim 把回收动作由一次变为了两次，这样更抗造一点。每次清理都是只有上次 local cache中留下来的对象才会被真正清理掉，当前的 cache 对象只是移到回收站（victim）。

知识小结：
每轮 GC 开始都会调用 poolCleanup 函数
使用两轮清理过程来抵抗波动，也就是 local cache 和 victim cache 配合

函数操作

Get

// the result of calling p.New.
func (p *Pool) Get() interface{} {//拿到当前P的poolLocal和pid，并且当前G固定在当前Ml, pid := p.pin()//从private拿x := l.privatel.private = nilif x == nil {//private没拿到//从链表头部拿x, _ = l.shared.popHead()if x == nil {//先尝试从其他P的localPool中偷一个Ele，如果没偷到再尝试从victim中获取Ele，之所以是这个获取顺序是为了对象在victim中呆的久一点这样垃圾回收时可以回收掉，避免浪费内存x = p.getSlow(pid)}}//M此时可抢占runtime_procUnpin()//还没拿到并且New不为nil，那么调用New函数创建对象if x == nil && p.New != nil {x = p.New()}return x
}func (p *Pool) pin() (*poolLocal, int) {//把G固定在当前P上pid := runtime_procPin()s := runtime_LoadAcquintptr(&p.localSize) // load-acquirel := p.local                              // load-consumeif uintptr(pid) < s {//获取P对应的localPoolreturn indexLocal(l, pid), pid}/*local还未初始化pinSlow 主要做以下几个事情：1. 首次 Pool 需要把自己注册进 allPools 数组；2. 按照P的个数创建poolLocal数组，赋值给local字段*/return p.pinSlow()
}

Put

func (p *Pool) Put(x interface{}) {if x == nil {return}l, _ := p.pin()//private没有放到privateif l.private == nil {l.private = xx = nil}if x != nil {//private有，就放到shared链表的头部l.shared.pushHead(x)}runtime_procUnpin()
}

常见踩坑

内存泄露

创建一个byte buffer的Pool，我们预估Pool中的byte Buffer大小在4K左右，但是拿出去的Byte Buffer在使用过程中底层的byte slice可能扩容，即使Reset了Byte Buffer中的内容大小仍然不变，这样放回Pool后，下次拿出来使用可能就不用了之前扩容的大小，造成部分内存用不到出现内存泄露

解决办法：在使用Put方法回收对象前检察一下对象的大小，如果太大就不要回收了

内存浪费

Pool中的对象可能偏大，使用的时候可能只需要一个小的buffer，那么就存在内存浪费

解决方法：将buffer池分成几层，比如小于512Byte的在一个池、小于1K的在一个池、小于4K的在一个池，按需从不同的池子拿，回收时按不同大小回收到不同的池

知名项目中实现的Pool

Pool分层
https://github.com/vitessio/vitess/tree/main/go/bucketpool

ByteBuffer Pool
https://github.com/valyala/bytebufferpool
https://github.com/oxtoacart/bpool

TCP连接池
https://github.com/fatih/pool

Worker Pool
https://github.com/gammazero/workerpool
https://github.com/ivpusic/grpool
https://github.com/dpaks/goworkers
https://github.com/alitto/pond

References

https://mp.weixin.qq.com/s/u0HZYgPVec9CET5d4wTPbA

总结

Pool是用来解决对象重用、对象预分配的一种手段

如果你发现GC频率高、GC耗时长，并且存在大量相同类型的临时对象不断被创建、销毁，那么可以使用Pool池化手段重用这些对象

如果发现Goroutine的数量特别多，内存资源占用非常大，那么可以使用Worker Pool限制Goroutine数量