golang sync.Pool 使用和源码分析

    golang 在写高频服务的时候，如何解决gc问题，对象池是一个颇有效果的方式，本文阐述下对象池的两种使用方式，和对对象池的源码分析，以及使用pool 的要点。golang 的对象池源码在避免锁竞争还利用了分段锁的思想减小锁的竞争，代码比较精彩。

该文章后续仍在不断的更新修改中， 请移步到原文地址http://www.dmwan.cc/?p=152

    首先sync.Pool 有两种使用方式，使用效果没有区别。

    第一种，实例化的时候，实现New 函数便可：

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)  
}

        第二种，get 取值的时候，判断是否为nil 便可。

package main  
 
import(  
    "fmt"  
    "sync"  
)  
 
func main() {  
    p := &sync.Pool{}  
    a := p.Get()
    if a == nil {
       a = func() interface{} {  
            return 0  
        }
    }
    p.Put(1)  
    b := p.Get().(int)  
    fmt.Println(a, b)  
}

    这两种实现方式，最后的效果是同样的，也反应了pool 的特性，get 返回值是new 的对象，或者nil。

    而后，pool 底层究竟是怎样的数据结构？就是一个metux 和 slice？其实也是相似，只是加了些其余特性而已，下面数据结构：

type Pool struct {  
    local     unsafe.Pointer // local fixed-size per-P pool, actual type is [P]poolLocal  
    localSize uintptr        // size of the local array  
  
    // 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{}  
}  
  
// Local per-P Pool appendix.  
type poolLocal struct {  
    private interface{}   // Can be used only by the respective P.  
    shared  []interface{} // Can be used by any P.  
    Mutex                 // Protects shared.  
    pad     [128]byte     // Prevents false sharing.  
}

    这里的local 是个poolLocal 的数组，localsize 是数组的大小。其中，从get 和put 方法看，为每一个thread 维护了一个poolLocal 数据结构。不一样线程取数据的时候，先判断下hash 到哪一个线程去了，分别去对应的poolLocal 中去取数据，这是利用了分段锁的思想。

    具体实现能够看get 方法：

func (p *Pool) Get() interface{} {  
    if raceenabled {  
        if p.New != nil {  
            return p.New()  
        }  
        return nil  
    }  
    l := p.pin()  // 获取当前线程的poolLocal，也就是p.local[pid]。  
    x := l.private  //判断临时变量是否有值，有值即返回
    l.private = nil  
    runtime_procUnpin()  
    if x != nil {  
        return x  
    }  
    l.Lock()  //临时对象没值到本地的缓存列表中去取
    last := len(l.shared) - 1  
    if last >= 0 {  
        x = l.shared[last]  
        l.shared = l.shared[:last]  
    }  
    l.Unlock()  
    if x != nil {  
        return x  
    }  
    return p.getSlow()  //当本线程的缓存对象已经没有，去其余线程缓存列表中取
}

    这里代码的注释比较详尽了，原本维护一个mutex ，如今变成竞争多个mutex ，下降了锁的竞争。性能天然很是好。

    最后是getSlow 方法，从其余线程的变量中去steal 偷。runtime 也喜欢搞这种事。。。

func (p *Pool) getSlow() (x interface{}) {  
    // See the comment in pin regarding ordering of the loads.  
    size := atomic.LoadUintptr(&p.localSize) // load-acquire  
    local := p.local                         // load-consume  
    // Try to steal one element from other procs.  
    pid := runtime_procPin()  
    runtime_procUnpin()  
    for i := 0; i < int(size); i++ {  //遍历其余线程的缓存队列
        l := indexLocal(local, (pid+i+1)%int(size))  
        l.Lock()  
        last := len(l.shared) - 1  
        if last >= 0 {  
            x = l.shared[last]  
            l.shared = l.shared[:last]  
            l.Unlock()  
            break  
        }  
        l.Unlock()  
    }  
  
    if x == nil && p.New != nil {  //其余线程没有，那么new 一个
        x = p.New()  
    }  
    return x  
}

    最后，pool 还有个特性是当gc 的时候全部的缓存对象都要被清理，调用的是PoolCleanUp,没什么特别之处。可是这个特性要求了pool 绝对不能作有状态的缓存，相似socket的缓存池。

    这里的分段锁，为每一个线程bind 一个队列，还考虑到了均衡的状况，是比较巧妙和值得学习的。以上。。。