Go并发编程 — sync.Once 单实例模式的思考
共 6606字,需浏览 14分钟
·
2021-03-18 22:17
大纲
并发经典场景
怎么解决?
单例模式
Once 的实现
思考:为什么没有用 cas 原子判断?
思考:为什么 `doSlow` 用 `defer` 来加计数,而不是 `f()` 之后直接操作?
Once 的语义
总结
并发经典场景
Go 并发编程的场景中,有一个特别经典的场景,就是并发创建对象的时候。一般伪代码如下:
if ( /* 如果对象不存在 */) {
// 那么就创建对象
}
因为是并发的环境,所以多个 goroutine 短时间内得出的判断都是一样的:都判断得到对象是不存在的,这时候大家的的行为也特别一致,每个 goroutine 磨刀霍霍就是创建。这时候如果不加以控制,那么会导致程序逻辑出问题。
会导致对象重复创建多次,并且可能不断的被替换和丢弃。
怎么解决?
加锁互斥
最简单的方法:加锁互斥。保证判断和创建这两个动作是原子操作,这样就不存在并发误判的时间窗,那么就不会存在以上问题了。
lock ...
{
if ( /* 如果对象不存在 */) {
// 那么就创建对象
}
}
unlock ...
加锁不可怕,锁冲突才可怕,如果每次都要抢一把锁,那性能就划不来了。
Once
在 Go 的并发库对此有另外一个实现:sync.Once
对象。这是一个非常小巧的实现,对象实现代码极其精简。这个库非常方便的实现 Go 的单实例设计模式。
我们换一个思路,我们不做判断,需要一个库能够提供只执行一次的语义,那么也能实现我们的目的。
没错,就是直接调用 Once.Do
执行创建对象,业务方甚至都不需要再做多余的判断的动作,如下:
once.Do(/* 创建对象 */)
对,就是这么简单,上面的调用就能保证在并发的上下文中,保持正确性。那么 sync.Once
对外保证了什么语义呢?
划重点:确保传入函数只被执行一次。
这里注意思考一个点:只执行一次是针对库的还是针对实例的?
划重点:只执行一次的语义是和具体的 once 变量绑定的。
怎么理解?举个例子:
var once1 sync.Once
var once2 sync.Once
once1.Do( f1 )
once2.Do( f2 )
f1
和 f2
各保证执行一次。
单例模式
单例模式模式可以说是设计模式里最简单的了。Go 怎么实现只创建一个对象呢?
非常简单,就是借助 sync.Once
结构。举个完整的例子:
// 全局变量(我们只希望创建一个)
var s *SomeObject
// 定义一个 once 变量
var once sync.Once
// 只希望创建一个,单例模式
func GetInstance() *SomeObject {
once.Do(func(){
// 创建一个对象,赋值指针给全局变量
s = &SomeObject{}
})
return s
}
这样,我们就实现了单例模式,每次调用 GetInstance
函数返回的对象都只有一个。那么 sync.Once
是怎么做到的呢?
Once 的实现
以下就是 Once
实例的全部源码实现,非常的简短,也非常的有趣。
package sync
import (
"sync/atomic"
)
type Once struct {
done uint32
m Mutex
}
func (o *Once) Do(f func()) {
// 思考题:为什么这里不用 cas 来判断?
if atomic.LoadUint32(&o.done) == 0 {
o.doSlow(f)
}
}
func (o *Once) doSlow(f func()) {
o.m.Lock()
defer o.m.Unlock()
if o.done == 0 {
// 思考题:为什么这里用 defer 来加计数?
defer atomic.StoreUint32(&o.done, 1)
f()
}
}
以上的 sync.Once
实现非常简短,但是也有两个值得思考的地方。
为什么 Once.Do
里面没有用cas
判断?原子操作岂不是更快?为什么 Once.doSlow
里面用defer
来加计数,而不是直接操作?
思考:为什么没有用 cas 原子判断?
什么是 cas
?
Go 里面有是 atomic.CompareAndSwapUint32
实现这 cas
的功能。cas
就是 Compare And Swap 的缩写,把判断和赋值包装成一个原子操作。我们看一下 cas 的伪代码实现:
func cas(p : pointer to int, old : int, new : int) bool {
// *p 不等于 old 的时候,返回 false
if *p != old {
return false
}
// *p 等于 old 的时候,赋值新值,并返回 true
*p = new
return true
}
上面的就是 cas
的伪代码实现,cas
保证上面的逻辑是原子操作。思考下,为什么 Once
不能用如下的实现:
if atomic.CompareAndSwapUint32(&o.done, 0, 1) {
f()
}
第一眼看过去,好像也能实现 Once
只执行一次语义?
这个代码看起来 o.done == 0
的时候,会赋值 o.done==1
,然后执行 f()
。其他并发请求的时候, o.done == 1
,就不会再进到这个分支里,貌似也可以?
那为什么没用原子操作呢?cas
原子操作不是性能最好的吗?
细品下,虽然能保证只执行一次,却有个致命的缺陷:无法在 o.done==1
的时候保证 f()
函数有执行完成。Golang 的标准库也针对这些提到了这点。
// Do guarantees that when it returns, f has finished. // This implementation would not implement that guarantee: // given two simultaneous calls, the winner of the cas would // call f, and the second would return immediately, without // waiting for the first's call to f to complete.
当 o.done
判断为 0 的时候,立即就设置成了 1 ,这个时候才走到 f()
函数里执行,这里的语义不再正确。
Once
不仅要保证只执行一次,还要保证当其他用户看到 o.done==1
导致 Once.Do
返回的时候,确保执行完成。
这个语义很重要吗?
非常重要,这里涉及到逻辑的正确性。举个栗子,我们用 Once.Do
来创建一个唯一的全局变量对象,如果是你回复了用户已经 Once.Do
成功,但是却 f()
还在执行过程,那么就会出现中间态,全局变量还没有创建出来,行为是无法定义的。
那么怎么解决?解决非常简单,两个思路:
热路径:用原子读 o.done
的值,保证竞态条件正确;既然不能用 cas
原子操作,那就用锁机制来保证原子性。如果o.done == 0
,那么就走慢路径,注意:以下所有逻辑在一把大锁内先执行 f()
函数;然后才去设置 o.done
为 1;
第一次可能在锁互斥的时候,可能会比较慢。因为要抢锁,但是只要执行过一次,就不会在走到锁内的逻辑了。都是走原子读的路径,也是非常快的。
既然提到锁,我们再来看一个死锁的例子。Once
内部用锁来保证代码的临界区,那么就千万不要嵌套使用,不然会死锁。如下:
once1.Do( func(){
once1.Do( func(){
/* something */
} )
} )
上面的代码会死锁在 once1.m.Lock()
的调用上。
划重点:千万不要把 sync.Once
用的复杂,要保持简洁,嵌套很容易死锁。
思考:为什么 doSlow 用 defer 来加计数,而不是 f() 之后直接操作?
Once.doSlow
整个是在锁内操作的,所以这段代码的操作是串行化的。如果 o.done
为 0,标识没有执行过 f,整个时候注册一个 defer
函数 defer atomic.StoreUint32(&o.done, 1)
,然后运行 f() 。
func (o *Once) doSlow(f func()) {
o.m.Lock()
defer o.m.Unlock()
if o.done == 0 {
// 思考题:为什么这里用 defer 来加计数?
defer atomic.StoreUint32(&o.done, 1)
f()
}
}
这里为什么要用 defer
来确保执行 o.done
赋值为 1 的操作呢?踏实把 atomic.StoreUint32(&o.done, 1)
放到 f()
之后不好吗?
不好!因为处理不了 panic 的异常。举个例子:
如果不用 defer
,当 f()
执行的时候出现 panic
的时候(被外层 recover,进程没挂),会导致没有 o.done
加计数,但其实 f()
已经执行过了,这就违反语义了。
之前我们说过,defer
注册的函数,就算 f()
内部执行出现 panic
,也会被执行,所以这里就保证了 Once 对外的语义:执行过一次,o.done
一定是非 0。
不过,我们继续思考 panic
场景,如果说 f()
因为某些原因,导致了 panic
,可能并没有执行完,这种时候,也再不会执行 Once.Do
了,因为已经执行过一次了。业务自己承担这个责任,框架已经尽力了。
Once 的语义
这里归纳出 Once 提供的语义:
Once.Do
保证只调用一次的语义,无论f()
内部有没有执行完( panic );只有 f()
执行完成,Once.Do
才会返回,否则阻塞等待f()
的第一次执行完成;
抢锁简要演示:
最开始一轮并发的时候,需要抢锁,但是只有这一会儿,不会太久。
之后的常规操作,全都走原子读即可,非常快速:
总结
Once
对外提供f()
只调用一次的语义;Once.Do
返回之后,按照约定,f()
一定被执行过一次,并且只执行过一次。如果没有执行完,会阻塞等待f()
的第一次执行完成;Once
只执行一次的语义是跟实例绑定的关系,多个Once
实例的话,每个实例都有一次的机会;内部用锁机制来保证逻辑的原子性,先执行 f()
,然后设置o.done
标识位;Once
用defer
机制保证panic
的场景,也能够保证o.done
标识位被设置;Once
实例千万注意,不要嵌套,内部有锁,乱用的话容易死锁;
~完~
推荐阅读