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还会执行吗?


发表评论

电子邮件地址不会被公开。 必填项已用*标注