sync pool中的几个问题解答

之前在分享中，发现了自己在看sync.pool的源码中忽略了两个个重要的问题。这两个问题，确实是在看源码的过程中自己没思考的。确实，这也是分享的好处，分享让自己能从不同角度重新看待原来的问题。废话不过说，下面上课。

nocopy的作用，没有nocopy又会出现什么问题

首先介绍下golang的nocopy

这个nocopy只是在结构体里面声明的一个变量，声明这个变量并不是不能拷贝，只是在兽医go vet的检查下会报错。

noCopy 是 go1.7 开始引入的一个静态检查机制。它不仅仅工作在运行时或标准库，同时也对用户代码有效。
用户只需实现这样的不消耗内存、仅用于静态分析的结构，来保证一个对象在第一次使用后不会发生复制

然后说下介绍下waitgroup 使用拷贝会出现什么问题：

我们拿其中sync包下的waitgroup作为例子，看看waitgroup的拷贝会发生什么问题，首先我们看看waitgroup的结构体：

type WaitGroup struct {
    noCopy noCopy

    // 64-bit value: high 32 bits are counter, low 32 bits are waiter count.
    // 64-bit atomic operations require 64-bit alignment, but 32-bit
    // compilers do not ensure it. So we allocate 12 bytes and then use
    // the aligned 8 bytes in them as state, and the other 4 as storage
    // for the sema.
    state1 [3]uint32
}

这里声明了两个变量，其中一个就是nocopy，里一个是数组state1。好的，拷贝waitgroup意味着对数组拷贝，golang的拷贝的都是值拷贝，数组的拷贝就是深拷贝了，并不是重新拷贝指针。理解了这点之后，我们就能发现，在拷贝之后，对waitgroup的操作完全是在两个waitgroup上了，是不是有点恐怖，下面用一段代码来验证：

func main()  {
    var t sync.WaitGroup
    t.Add(1)
    go func(wait sync.WaitGroup) {
        fmt.Println(1)
        wait.Done()
    }(t)
    t.Wait()
    fmt.Println("done!")
}

这段代码中，新的groutine中使用了参数值传递的方式，来拷贝了waitgroup，原以为程序能够顺利的执行，没想到缺产生了

fatal error: all goroutines are asleep – deadlock!

同时，我们用vet检查下也能发现：

./main.go:96:4: call of func(wait sync.WaitGroup) {
        fmt.Println(1)
        wait.Done()
} copies lock value: sync.WaitGroup contains sync.noCopy
./main.go:93:15: func passes lock by value: sync.WaitGroup contains sync.noCopy

上面阐述了，通过值传递也拷贝了nocopy。

最后看看sync.pool的拷贝：

我们先看看sync.pool的结构体，这里使用的是golang1.14的版本，1.13之前的版本因为还有锁，所以拷贝就更加不被允许了。1.13之后因为使用了CAS进行操作，优化了锁的操作，这里就只讲了1.13之后的无锁版本，对于拷贝可能会出现的问题：

type Pool struct {
    noCopy noCopy

    local     unsafe.Pointer // local fixed-size per-P pool, actual type is [P]poolLocal
    localSize uintptr        // size of the local array

    victim     unsafe.Pointer // local from previous cycle
    victimSize uintptr        // size of victims 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变量指向的是一个切片，索引的是每个pid的值。指向切片又有什么问题，当切片进行扩容操作的时候，地址是会被修改。基于这点，我们能看出，扩容后的pool和拷贝后pool是会出现不一致的情况的。那数据不一致又会对pool产生什么样的问题呢？数据不一致意味着对于有的pool来说，有的能拿出对象，有的不能，不能就得重新创建，重新创建就意味着内存重复利用的功能降低了，重复利用内存的概率降低了，就和pool的目的重复内存使用的目的产生了偏差。

pin是怎么保证GC不在绑定和解绑之间发生GC的

pool函数里面有个pin方法，目的是绑定G和M，并且获取M上的当前P的pid；同时，另一个功能是 保证GC不在绑定和解绑之间发生。

那么问题来了：他是怎么保证GC不触发的呢，这里翻了下GC的源码，看下下main这个：

func gcStart(trigger gcTrigger) {
    // Since this is called from malloc and malloc is called in
    // the guts of a number of libraries that might be holding
    // locks, don't attempt to start GC in non-preemptible or
    // potentially unstable situations.
    mp := acquirem()
    if gp := getg(); gp == mp.g0 || mp.locks > 1 || mp.preemptoff != "" {
        releasem(mp)
        return
    }
    releasem(mp)
    mp = nil
        ......
}

这里gc在开始之前，会获取当期那M，然后判断当前M上的几个参数，其中的一个参数是locks，这个只要大于0，便不会发生GC。这个locks会在调用pin的使用进行自增，以此来保证GC的不触发。同时，有产生了一个问题，pin的调用能保证GC的不触发，那么在大量pin的调用下，极端情况下，GC是不是不会执行了呢？这个还要学习！

好的，今天介绍了两个sync.pool中出现的问题，分别是nocopy，和pin。对于nocopy，首先介绍了nocopy，然后使用了waitgroup作为例子，最后介绍了pool的拷贝可能会产生的问题。在pin中，我们介绍了pin的保证GC不触发的原因，同时抛出了另一个问题：频繁pin下，GC还会执行吗？