Golang sync.Pool

1. Golang sync.Pool

1.1. 基础知识

在 golang 中有一个池, 它特别神奇, 你只要和它有个约定, 你要什么它就给什么, 你用完了还可以还回去, 但是下次拿的时候呢, 确不一定是你上次存的那个, 这个池就是 sync.Pool。sync.Pool 类型只有两个方法——Put 和 Get。Put 用于在当前的池中存放临时对象, 它接受一个 interface{}类型的参数; 而 Get 则被用于从当前的池中获取临时对象, 它会返回一个 interface{}类型的值。更具体地说, 这个类型的 Get 方法可能会从当前的池中删除掉任何一个值, 然后把这个值作为结果返回。如果此时当前的池中没有任何值, 那么这个方法就会使用当前池的 New 字段创建一个新值, 并直接将其返回, 先看个简单的示例:

var strPool = sync.Pool{    New: func() interface{} {        return "test str"    },}func main() {    str := strPool.Get()    fmt.Println(str)    strPool.Put(str)}

通过 New 去定义你这个池子里面放的究竟是什么东西, 在这个池子里面你只能放一种类型的东西, 比如在上面的例子中我就在池子里面放了字符串。我们随时可以通过 Get 方法从池子里面获取我们之前在 New 里面定义类型的数据, 当我们用完了之后可以通过 Put 方法放回去, 或者放别的同类型的数据进去。那么这个池子的目的是什么呢? 其实一句话就可以说明白, 就是为了复用已经使用过的对象, 来达到优化内存使用和回收的目的。说白了, 一开始这个池子会初始化一些对象供你使用, 如果不够了呢, 自己会通过 new 产生一些, 当你放回去了之后这些对象会被别人进行复用, 当对象特别大并且使用非常频繁的时候可以大大的减少对象的创建和回收的时间。

1.2. 源码解析

1.2.1. Pool

type Pool struct {    noCopy noCopy    local     unsafe.Pointer  // 数组指针, 指向 [P]poolLocal    localSize uintptr         // 大小为 P    victim     unsafe.Pointer // 用于存放"幸存者"    victimSize uintptr        // "幸存者"size    // New optionally specifies a function to generate    // a value when Get would otherwise return nil.    // It may not be changed concurrently with calls to Get.    New func() interface{}}type poolLocalInternal struct {    private interface{} // Can be used only by the respective P.    shared  poolChain   // Local P can pushHead/popHead; any P can popTail.}type poolLocal struct {    poolLocalInternal    // Prevents false sharing on widespread platforms with    // 128 mod (cache line size) = 0 .    pad [128 - unsafe.Sizeof(poolLocalInternal{})%128]byte}

我们可以看到其实结构并不复杂, 但是如果自己看的话有点懵, 注意几个细节就可以:

• local 这里面真正的是 [P]poolLocal 其中 P 就是 GPM 模型中的 P, 有多少个 P 数组就有多大, 也就是每个 P 维护了一个本地的 poolLocal。
• poolLocal 里面维护了一个 private 一个 shared, 看名字其实就很明显了, private 是给自己用的, 而 shared 的是一个队列, 可以给别人用的。注释写的也很清楚, 自己可以从队列的头部存然后从头部取, 而别的 P 可以从尾部取。
• victim 这个从字面上面也可以知道, 幸存者嘛, 当进行 gc 的 stw 时候, 会将 local 中的对象移到 victim 中去, 也就是说幸存了一次 gc。

1.2.2. Get

func (p *Pool) Get() interface{} {    // ......    l, pid := p.pin()    // Step1: 先直接获取自己的 private, 如果有, 直接返回    x := l.private    l.private = nil    if x == nil {        // Step2: 如果 private 为空, 就从自己的 shared 随便取一个        x, _ = l.shared.popHead()        if x == nil {            x = p.getSlow(pid)        }    }    runtime_procUnpin()    // ......    if x == nil && p.New != nil {        // Step5: 找了一圈都没有, 自己 New 一个        x = p.New()    }    return x}
func (p *Pool) getSlow(pid int) interface{} {    size := atomic.LoadUintptr(&p.localSize)    locals := p.local    for i := 0; i < int(size); i++ {        l := indexLocal(locals, (pid+i+1)%int(size))        // Step3: 从其它的 P 中随便偷一个出来        if x, _ := l.shared.popTail(); x != nil {            return x        }    }    size = atomic.LoadUintptr(&p.victimSize)    if uintptr(pid) >= size {        return nil    }    // Step4: 从"幸存者"中找一个, 找的逻辑和前面的一样, 先 private, 再 shared    locals = p.victim    l := indexLocal(locals, pid)    if x := l.private; x != nil {        l.private = nil        return x    }    for i := 0; i < int(size); i++ {        l := indexLocal(locals, (pid+i)%int(size))        if x, _ := l.shared.popTail(); x != nil {            return x        }    }    atomic.StoreUintptr(&p.victimSize, 0)    return nil}

我去掉了其中一些竞态分析的代码, 代码里面我也标明了每个 step, Get 的逻辑其实非常清晰:

• 如果 private 不是空的, 那就直接拿来用;
• 如果 private 是空的, 那就先去本地的 shared 队列里面从头 pop 一个;
• 如果本地的 shared 也没有了, 那 getSlow 去拿, 其实就是去别的 P 的 shared 里面偷, 偷不到回去 victim 幸存者里面找;
• 如果最后都没有, 那就只能调用 New 方法创建一个了。
  再用一幅图描述一下:

1.2.3. Put

func (p *Pool) Put(x interface{}) {    if x == nil {        return    }    // ......    l, _ := p.pin()    if l.private == nil {        l.private = x        x = nil    }    if x != nil {        l.shared.pushHead(x)    }    runtime_procUnpin()    // ......}

Put 主要做 2 件事情:

• 如果 private 没有, 就放在 private;
• 如果 private 有了, 那么就放到 shared 队列的头部。

1.3. GMP 调度

我们先回顾一下 GMP 的知识:

• G 表示 Goroutine 协程, M 表示 thread 线程, P 表示 processor 处理器;
• M 是 G 运行的实体, P 的作用就是将 G 分配到 M 上;
• 一个 P 有个本地队列, 专门用于存放 G。
  再回顾一下 GMP 核心的调度流程:
• 当程序运行时, P 会从本地队列中随机取一个 G, 然后给到 M 运行;
• 当 P 的本地队列没有 G 时, 会从全局对列中找一批 G, 然后放到自己的本地队列, 然后再取出 G;
• 当本地队列为空时, P 会从其它的 P 的本地队列中抢一批 G, 然后放到自己的本地队列, 然后再取出 G;
• 当没有抢到时, M 就自动挂起来, 不运行了。
  一句话总结一下, G 和 P 都属于 Goroutine 调度器, 就是通过 G 和 P 的各种协作, 找一个 P 给到 M, 然后 OS 调度器就会去运行这个 M, 详细的知识可以阅读"GMP 原理"章节。我们再回到 sync.Pool, 它的 Get 代码是不是和 GMP 中 P 去抢 G 中很像呢? 我们再深度解读一下: 在程序调用临时对象池的 Put 方法或 Get 方法的时候, 总会先试图从该临时对象池的本地池列表中, 获取与之对应的本地池, 依据的就是与当前的 goroutine 关联的那个 P 的 ID。换句话说, 一个临时对象池的 Put 方法或 Get 方法会获取到哪一个本地池, 完全取决于调用它的代码所在的 goroutine 关联的那个 P, 我们可以通过下面这幅图来描述:
  pool 结构体中的 unsafe.Pointer, 就是图中的本地池列表, 一共有 P 个本地池, 每个池子包含 1 个 private 和 1 个 shared, 其中 shared 是一个队列, 里面装的就是对应的 pool 元素(注意图中的 G 不是 pool 元素, 只是表示一个协程), 然后对于 13.2.2 中的 Get 调度图, 也可以通过下面这一幅图表述:
  里面抢占 pool 数据的逻辑, 和 GMP 中抢占 G 资源的逻辑, 是不是很像呢?

1.4. 总结

pool 在掌握基础用法的同时, 需要知道 Get 和 Push 方法的实现逻辑, 其中最重要的一点, 是需要将 pool 和 GMP 的调度原理结合起来, 其中两者的 P 的原理其实是一样的, 只是对于资源抢占这一块, GMP 抢占的是 G, pool 抢占的是 pool 数据, 对于这块, 其实是自己个人的理解, 如果理解的不对, 还请大家帮忙指出。