浅析GO并发处理选择sync还是channel
作者：阿兵云原生
如何选择 sync 和 channel
以前写 C 的时候，我们一般是都通过共享内存来通信，对于并发去操作某一块数据时，为了保证数据安全，控制线程间同步，我们们会去使用互斥锁，加锁解锁来进行处理
然而 GO 语言中建议的时候通过通信来共享内存，使用 channel 来完成临界区的同步机制
可是 GO 语言中的 channel 毕竟是属于比较高级的原语，自然在性能上就比不上 sync包里面的锁机制，感兴趣的同学可以自己写一个简单的基准测试来确认一下效果，评论去可以交流
另外，使用 sync 包来控制同步时，我们不会失去结构对象的所有权，还能让多个协程之间同步访问临界区的资源，那么如果我们的需求能够符合这种情况时，还是建议使用 sync 包来控制同步更加的合理和高效
为什么会选择使用 sync 包来控制同步结论：
- 不期望失去结构的控制权的同时，还期望多个协程能够安全的同步访问临界区资源
- 对性能要求会更高的情况
sync 的 Mutex 和 RWMutex
查看 sync 包的源码（xxx\Go\src\sync），我们可以看到 sync 包下面有如下几个结构：
- Mutex
- RWMutex
- Once
- Cond
- Pool
- atomic 包原子操作
上述经常使用的就是 Mutex 了，尤其是最开始不善于使用 channel 的时候，觉得使用 Mutex 非常的顺手，其次 RWMutex 相对来说就会用的少一些
不知大家有没有关注过，使用 Mutex 和 使用 RWMutex 的性能表现，获取大部分人都是默认使用互斥锁，一起写个 demo 来看看 他俩的性能对比
var (
mu sync.Mutex
murw sync.RWMutex
tt1 = 1
tt2 = 2
tt3 = 3
)
// 使用 Mutex 控制读取数据
func BenchmarkReadMutex(b *testing.B) {
b.RunParallel(func(pp *testing.PB) {
for pp.Next() {
mu.Lock()
_ = tt1
mu.Unlock()
}
})
}
// 使用 RWMutex 控制读取数据
func BenchmarkReadRWMutex(b *testing.B) {
b.RunParallel(func(pp *testing.PB) {
for pp.Next() {
murw.RLock()
_ = tt2
murw.RUnlock()
}
})
}
// 使用 RWMutex 控制读写入数据
func BenchmarkWriteRWMutex(b *testing.B) {
b.RunParallel(func(pp *testing.PB) {
for pp.Next() {
murw.Lock()
tt3++
murw.Unlock()
}
})
}写了三个简单的基准测试
- 使用互斥锁读取数据
- 使用读写锁的读锁读取数据
- 使用读写锁读取和写入数据
$ go test -bench . bbb_test.go --cpu 2 goos: windows goarch: amd64 cpu: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz BenchmarkReadMutex-2 39638757 30.45 ns/op BenchmarkReadRWMutex-2 43082371 26.97 ns/op BenchmarkWriteRWMutex-2 16383997 71.35 ns/op $ go test -bench . bbb_test.go --cpu 4 goos: windows goarch: amd64 cpu: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz BenchmarkReadMutex-4 17066666 73.47 ns/op BenchmarkReadRWMutex-4 43885633 30.33 ns/op BenchmarkWriteRWMutex-4 10593098 110.3 ns/op $ go test -bench . bbb_test.go --cpu 8 goos: windows goarch: amd64 cpu: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz BenchmarkReadMutex-8 8969340 129.0 ns/op BenchmarkReadRWMutex-8 36451077 33.46 ns/op BenchmarkWriteRWMutex-8 7728303 158.5 ns/op $ go test -bench . bbb_test.go --cpu 16 goos: windows goarch: amd64 cpu: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz BenchmarkReadMutex-16 8533333 132.6 ns/op BenchmarkReadRWMutex-16 39638757 29.98 ns/op BenchmarkWriteRWMutex-16 6751646 173.9 ns/op $ go test -bench . bbb_test.go --cpu 128 goos: windows goarch: amd64 cpu: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz BenchmarkReadMutex-128 10155368 116.0 ns/op BenchmarkReadRWMutex-128 35108558 33.27 ns/op BenchmarkWriteRWMutex-128 6334021 195.3 ns/op
可以看出来当并发较小的时候，使用互斥锁和使用读写锁的读锁性能类似，当并发逐渐变大时，读写锁的读锁性能并未发生较大变化，互斥锁和读写锁的性能都会随着并发的变大而下降
那么很明显，读写锁适用于读多写少的场景，在大并发读书数据的时候，多个协程可以同时拿到读锁，减少锁竞争和等待时间
而互斥锁并发的时候，多个协程中，只有一个协程能拿到锁，其他协程就会阻塞和等待，影响性能
举个例子，我们正常使用互斥锁，看看可能会出现什么样的问题
使用 sync 需要注意的地方
平时使用 sync 包中的锁的时候，需要注意的是不要去拷贝已经已经使用过的 Mutex 或者是 RWMutex
写一个简单的 demo：
var mu sync.Mutex
// sync 的互斥锁，读写锁，在被使用之后，就不要去复制这个对象，若要复制，需要在其未被使用的时候
func main() {
go func(mm sync.Mutex) {
for {
mm.Lock()
time.Sleep(time.Second * 1)
fmt.Println("g2")
mm.Unlock()
}
}(mu)
mu.Lock()
go func(mm sync.Mutex) {
for {
mm.Lock()
time.Sleep(time.Second * 1)
fmt.Println("g3")
mm.Unlock()
}
}(mu)
time.Sleep(time.Second * 1)
fmt.Println("g1")
mu.Unlock()
time.Sleep(time.Second * 20)
}感兴趣的朋友的，可以运行一下，可以看到打印的结果中时没有 g3 的，因此 g3 所在的协程已经发生了死锁，没有机会去调用 unlock
出现这种情况的原因是这样的，先来看看 Mutex 的内部结构：
//...
// A Mutex must not be copied after first use.
//...
type Mutex struct {
state int32
sema uint32
}因为例如 Mutex 中的内部结构是有一个 state （表示互斥锁的状态）和 sema（表示控制互斥锁的信号量），其中初始化 Mutex 的时候，他们都是 0，但是当我们用 Mutex 加锁时，Mutex 的状态就变成了 Locked 的状态，这个时候，其中一个协程去拷贝这个 Mutex，并在自己协程中加锁，就会出现死锁的情况，这一点是非常需要注意的
如果涉及到这种多个协程使用 Mutex 的情况， 可以使用闭包或者传入包裹锁的结构地址或者指针，这样就可以避免使用锁的时候导致不可预期的结果，避免一脸蒙圈
sync.Once
sync 包中的其他成员，不知 xdm 使用的多么，相对使用频率较高的应该就是 sync.Once 了，其他成员 xdm 可以自行看看源码，或者评论区留言哦，我们来看看 syn.Once 如何使用，都有哪些需要注意的？
还记得之前写 C 或者 C++ 的时候，对于程序生命周期只有一个实例的时候，我们会选择使用单例模式来进行处理，那么此处的 sync.Once 就是非常适合用在单例模式中
sync.Once 可以保证任意一个函数在程序运行期间只被执行一次，这一点相对来说就比每个包中的 init 函数灵活一些了
这里需要注意，sync.Once 中执行的函数，如果出现了 panic ，也是会被认为是执行完了了一次，之后如果再有逻辑需要进入 sync.Once 是无法进入并执行函数逻辑的
一般情况下， sync.Once 用于对象资源的初始化和清理动作，避免重复操作，可以来看一个 demo：
- 主函数开辟 3 个协程，且使用 sync.WaitGroup 来管控并等待子协程退出
- 主函数开辟所有协程之后等待 2 秒，开始创建并获取实例
- 协程中也在获取实例
- 只要有一个协程获取到进入 Once，执行逻辑之后，会出现 panic
- 出现 panic 的协程捕获了异常，此时全局的 instance 已经被初始化，其他协程仍然无法进入 Once 内的函数
type Instance struct {
Name string
}
var instance *Instance
var on sync.Once
func GetInstance(num int) *Instance {
defer func() {
if err := recover(); err != nil {
fmt.Println("num %d ,get instance and catch error ... \n", num)
}
}()
on.Do(func() {
instance = &Instance{Name: "阿兵云原生"}
fmt.Printf("%d enter once ... \n", num)
panic("panic....")
})
return instance
}
func main() {
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
wg.Add(1)
go func(i int) {
ins := GetInstance(i)
fmt.Printf("%d: ins:%+v , p=%p\n", i, ins, ins)
wg.Done()
}(i)
}
time.Sleep(time.Second * 2)
ins := GetInstance(9)
fmt.Printf("9: ins:%+v , p=%p\n", ins, ins)
wg.Wait()
}通过打印结果可以看出，0 对应的协程进入了 Once，且发生了 panic，因此当前协程获取到的 GetInstance 函数的结果是 nil
其他的协程包括主协程调用 GetInstance 函数都能正常拿到 instance 的地址，可以看出地址是同一个，全局就只初始化了一次
$ go run main.go
0 enter once ...
num %d ,get instance and catch error ...
0
0: ins:<nil> , p=0x0
1: ins:&{Name:阿兵云原生} , p=0xc000086000
2: ins:&{Name:阿兵云原生} , p=0xc000086000
9: ins:&{Name:阿兵云原生} , p=0xc000086000
到此这篇关于浅析GO并发处理选择sync还是channel的文章就介绍到这了,更多相关go并发处理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！