我所理解的Sync Pool

看gin源码时发现了sync.Pool的使用

// gin.go:L144
func New() *Engine {
    ...

    engine.pool.New = func() interface{} {
        return engine.allocateContext()
    }
    return engine
}

// gin.go: L346
func (engine *Engine) ServeHTTP(w http.ResponseWriter, req *http.Request) {
    c := engine.pool.Get().(*Context)
    c.writermem.reset(w)
    c.Request = req
    c.reset()

    engine.handleHTTPRequest(c)

    engine.pool.Put(c)
}

那个时候其实不太明白这个Pool是在干啥用, 大致觉得应该是内存池之类的. 后面想仔细看下sync.Pool具体怎么用, 我就去直接看了下Pool的源码, 然后直接懵逼了

因为基本看不懂其逻辑, 因为Pool的源码涉及到Golang的调度相关的知识. 要是不明白Golang是如何调度的, 基本是看不懂Pool的源码的(虽说它只有短短的259行代码, 文件路径: SDK/src/sync/pool.go). 这里推荐Go调度器系列系列文章

后面我就去看看别人是怎么理解和使用Pool的, 我就搜到了这么一篇文章 go语言的官方包sync.Pool的实现原理和适用场景里面有这么一个例子

package main

import(
    "fmt"
    "sync"
)

func main() {
    p := &sync.Pool{
        New: func() interface{} {
            return 0
        },
    }

    a := p.Get().(int)
    p.Put(1)
    b := p.Get().(int)
    fmt.Println(a, b)
}

以及Golang中国论坛上一个人的提问, 我不禁陷入了深深的疑问, 这个Golang的Pool到底是用来做什么的?

我疑问的地方:

sync.Pool的运用场景是什么, 哪些地方能用到Pool, 哪些地方不能用?
为啥CSDN上先Put后Get, 就能拿到1; 而Golang中国上那个提问, 为啥得到的顺序就不确定了?

我后面想了很久, 以及再回头去看gin, logrus的源码, 我才想明白: 这两个例子都是"坑货". 这两个例子都是sync.Pool使用的反面例子, 都是不正确的用法. 其实这些在源码的注释中, 都是由明确说明的, 只是当时没能理解. Callers should not assume any relation between values passed to Put and the values returned by Get. 简单来说: 就是Get和Put没有任何关系, 我们用Pool的时候, 要时刻记得这个.

因此, 我的疑问2就迎刃而解了, 其实就是这个一直困惑着我

关于疑问1就更简单了

// Pool's purpose is to cache allocated but unused items for later reuse,
// relieving pressure on the garbage collector. That is, it makes it easy to
// build efficient, thread-safe free lists. However, it is not suitable for all
// free lists.

简单来说, Pool就是为了减少GC压力的, 重复利用内存. 千万不能把他当成内存池使用

其实Pool的用法很简单, 就是先Get, 用完之后Put, 如gin的使用.

再比如logrus的用法

func (logger *Logger) Println(args ...interface{}) {
    entry := logger.newEntry()
    entry.Println(args...)
    logger.releaseEntry(entry)
}

func (logger *Logger) newEntry() *Entry {
    entry, ok := logger.entryPool.Get().(*Entry)
    if ok {
        return entry
    }
    return NewEntry(logger)
}

func (logger *Logger) releaseEntry(entry *Entry) {
    entry.Data = map[string]interface{}{}
    logger.entryPool.Put(entry)
}

所以别被别的池子带跑了, golang里的sync.Pool就是GC优化的, 用法很简单

在gocn有这么一个问题: 想在pool的基础上做一个限制池中对象数量的功能, 发现还是多次执行pool.New. 期望是只执行一次NewBuffer，也就是只打印一次alloc。实际上每次执行，会打印多次alloc

const MaxFrameSize = 5000

func main() {
    for i := 0; i < 10; i++ {
        // 多个协程想从pool中拿到对象
        go func() {
            c := getBuf()
            putBuf(c)
            log.Println("put done")
        }()
    }

    time.Sleep(3 * time.Second)
}

var bufPool = sync.Pool{
    New: func() interface{} {
        log.Println("alloc")
        return bytes.NewBuffer(make([]byte, 0, MaxFrameSize))
    },
}

var bufPoolChan = make(chan bool, 1)

func getBuf() *bytes.Buffer {
    bufPoolChan <- true
    b := bufPool.Get().(*bytes.Buffer)
    b.Reset()
    return b
}

func putBuf(b *bytes.Buffer) {
    bufPool.Put(b)
    <-bufPoolChan
}

大神解答:

sync.Pool的源代码里说了，pool里的对象随时都有可能被自动移除，并且没有任何通知。sync.Pool的数量是不可控制的。

Pool调用New与线程调度有关，Pool内部有一个localPool的数组，每个P对应其中一个localPool，在当前P执行goroutine的时候，优先从当前的localPool的private变量取，娶不到在从shared列表里面取，再取不到就尝试从别的P的localPool的shared里面偷一个。最后实在取不到就New一个。

由于你的bufPoolChan限制基本上10个goroutine就在两个P后面排队轮流执行，所以alloc就会出现两次，后面的基本就是从这两个localPool的private取出来的。

如果取消这个限制，10个goroutine很快就被分配到10个P上去了，对应就有10个localPool，10次每次取private都取不到，取shared列表也取不到，别的localPool也没得偷，就会New10次，alloc就会出现10次。

其他高级用法, 后面再补充

参考文章

[译] CockroachDB GC优化总结
Golang 优化之路——临时对象池
用Benchmark验证sync.Pool对GC latency的优化效果
Go语言实战笔记（十六）| Go 并发示例-Pool
Pool

我所理解的Sync Pool

你可能感兴趣的:(我所理解的Sync Pool)