服务器之家

服务器之家 > 正文

浅谈golang并发操作变量安全的问题

时间:2021-03-17 00:56     来源/作者:思维的深度

我就废话不多说了,大家还是直接看代码吧~

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
package main
import (
    "fmt"
    "time"
    "sync"
    "sync/atomic"
)
 
func main() {
    test1()
    test2()
}
 
func test1() {
    var wg sync.WaitGroup
    count := 0
    t := time.Now()
    for i := 0 ; i < 50000 ; i++ {
        wg.Add(1)
        go func(wg *sync.WaitGroup,i int) {
            count++ //count不是并发安全的
            wg.Done()
        }(&wg,i)
    }
 
    wg.Wait()
    fmt.Println(time.Now().Sub(t))
    fmt.Println("count====>",count) //count的值<50000
    fmt.Println("exit")
}
 
func test2() {
    var wg sync.WaitGroup
    count := int64(0)
    t := time.Now()
    for i := 0 ; i < 50000 ; i++ {
        wg.Add(1)
        go func(wg *sync.WaitGroup,i int) {
            atomic.AddInt64(&count,1) //原子操作
            wg.Done()
        }(&wg,i)
    }
 
    wg.Wait()
    fmt.Println(time.Now().Sub(t))
    fmt.Println("count====>",count) //count的值为50000
    fmt.Println("exit")
}

执行结果:

?
1
2
3
4
5
6
18.0485ms
count====> 46621
exit
16.0418ms
count====> 50000
exit

补充:golang 基于共享变量的并发

并发定义:当我们没有办法自信地确认一个事件是在另一个事件的前面或者后面发生的话,就说明x和y这两个事件是并发的。

并发安全:如果其所有可访问的方法和操作都是并发安全的话,那么类型便是并发安全的。

竞争条件:程序在多个goroutine交叉执行操作时,没有给出正确的结果。

只要有

两个goroutine并发访问

同一变量,且至

少其中的一个是写操作的时候就会发生数据竞争。

数据竞争会在两个以上的goroutine并发访问相同的变量且至少其中一个为写操作时发生。

第一种:不要去写变量,变量直接提前初始化。

第二种:多个只允许一个goroutine访问变量,用select来监听操作(go的金句:不要通过共享变量来通信,通过通信(channel)来共享变量)。

第三种:允许过个goroutine访问变量,但是同一时间只允许一个goroutine访问。

现在我们来讲第三种情况具体操作

 

golang 我们可以通过channel作为计量器,可以保证可以有多少个goroutine可以同时访问。make(chan struct{},1),通过写入读取用阻塞的方式锁定住指定的代码块的访问。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var (
sema = make(chan struct{}, 1) // a binary semaphore guarding balance
balance int
)
func Deposit(amount int) {
sema <- struct{}{} // acquire token
balance = balance + amount
<-sema // release token
}
func Balance() int {
sema <- struct{}{} // acquire token
b := balance
<-sema // release token
return b
}

可以保证同一时刻只有一个goroutine来访问。

然而我们可以用sync包中的Mutex来实现上面的功能,那就是:

互斥锁 sync.Mutex

互斥锁:保证共享变量不会被并发访问。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
import "sync"
var (
mu sync.Mutex // guards balance
balance int
)
func Deposit(amount int) {
mu.Lock()
balance = balance + amount
mu.Unlock()
}
func Balance() int {
mu.Lock()
b := balance
mu.Unlock()
return b
}

在Lock和Unlock之间的代码段中的内容goroutine可以随便读取或者修改,这个代码段叫做临界区。

注意:一定要释放锁(Unlock),不管任何情况,可以利用defer Mutex.Unlock(),一定要注意go里没有重入锁,如果遇到更小原子的操作,考虑分解成不带锁功能的小块函数

接下来我们将另一种锁:读写锁sync.RWMutex

很多情况我们需要保证读的性能,而互斥锁会短暂的阻止其他的goroutine的运行,没法达到很好的多并发效果(多读单写),这时读写锁就可以很好的解决这个问题。

RLock()和RUnlock()获取和释放一个读取或者共享锁。RLock只能在临界区共享变量没有任何写入操作时可用。一般来说,我们不应该假设逻辑上的只读函数/方法也不会去更新某一些变量。如果没法确定,那么久使用互斥锁(Mutex)

最后我们来讲下内存同步的问题

?
1
2
3
4
5
6
7
8
9
var x, y int
go func() {
x = 1 // A1
fmt.Print("y:", y, " ") // A2
}()
go func() {
y = 1 // B1
fmt.Print("x:", x, " ") // B2
}()

上面的例子:A1、A2、B1、B2 执行循序却是毫无规律

在现代计算机中可能会有一堆处理器,每一个都会有其本地缓存(local cache)。为了效率,对内存的写入一般会在每一个处理器中缓冲,并在必要时一起flush到主存。这种情况下这些数据可能会以与当初goroutine写入顺序不同的顺序被提交到主存。导致程序运行串行了,又同时串行的代码访问了共享变量,尽管goroutine A中一定需要观察到x=1执行成功之后才会去读取y,但它没法确保自己观察得到goroutine B中对y的写入,所以A还可能会打印出y的一个旧版的值。

有两种方法解决:

 

1.变量限定在goroutine中使用,不访问共享变量

2.用互斥条件访问

以上为个人经验,希望能给大家一个参考,也希望大家多多支持服务器之家。如有错误或未考虑完全的地方,望不吝赐教。

原文链接:https://skaygo.blog.csdn.net/article/details/81748121

标签:

相关文章

热门资讯

2020微信伤感网名听哭了 让对方看到心疼的伤感网名大全
2020微信伤感网名听哭了 让对方看到心疼的伤感网名大全 2019-12-26
yue是什么意思 网络流行语yue了是什么梗
yue是什么意思 网络流行语yue了是什么梗 2020-10-11
背刺什么意思 网络词语背刺是什么梗
背刺什么意思 网络词语背刺是什么梗 2020-05-22
Intellij idea2020永久破解,亲测可用!!!
Intellij idea2020永久破解,亲测可用!!! 2020-07-29
苹果12mini价格表官网报价 iPhone12mini全版本价格汇总
苹果12mini价格表官网报价 iPhone12mini全版本价格汇总 2020-11-13
返回顶部