之前在分享中，发现了自己在看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还会执行吗？
有疑问加站长微信联系（非本文作者）
