Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > go并发处理

浅析GO并发处理选择sync还是channel

作者:阿兵云原生

这篇文章主要想来和大家讨论一下,GO 语言处理并发的时候我们是选择sync还是channel,文中的示例代码讲解详细,感兴趣的小伙伴可以了解下

如何选择 sync 和 channel

以前写 C 的时候,我们一般是都通过共享内存来通信,对于并发去操作某一块数据时,为了保证数据安全,控制线程间同步,我们们会去使用互斥锁,加锁解锁来进行处理

然而 GO 语言中建议的时候通过通信来共享内存,使用 channel 来完成临界区的同步机制

可是 GO 语言中的 channel 毕竟是属于比较高级的原语,自然在性能上就比不上 sync包里面的锁机制,感兴趣的同学可以自己写一个简单的基准测试来确认一下效果,评论去可以交流

另外,使用 sync 包来控制同步时,我们不会失去结构对象的所有权,还能让多个协程之间同步访问临界区的资源,那么如果我们的需求能够符合这种情况时,还是建议使用 sync 包来控制同步更加的合理和高效

为什么会选择使用 sync 包来控制同步结论:

sync 的 Mutex 和 RWMutex

查看 sync 包的源码(xxx\Go\src\sync),我们可以看到 sync 包下面有如下几个结构:

上述经常使用的就是 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:

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并发处理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
阅读全文