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

(编辑:jimmy 日期: 2024/12/24 浏览:2)

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

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")
}

执行结果:

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),通过写入读取用阻塞的方式锁定住指定的代码块的访问。

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

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

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)

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

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.用互斥条件访问

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

一句话新闻

一文看懂荣耀MagicBook Pro 16
荣耀猎人回归!七大亮点看懂不只是轻薄本,更是游戏本的MagicBook Pro 16.
人们对于笔记本电脑有一个固有印象:要么轻薄但性能一般,要么性能强劲但笨重臃肿。然而,今年荣耀新推出的MagicBook Pro 16刷新了人们的认知——发布会上,荣耀宣布猎人游戏本正式回归,称其继承了荣耀 HUNTER 基因,并自信地为其打出“轻薄本,更是游戏本”的口号。
众所周知,寻求轻薄本的用户普遍更看重便携性、外观造型、静谧性和打字办公等用机体验,而寻求游戏本的用户则普遍更看重硬件配置、性能释放等硬核指标。把两个看似难以相干的产品融合到一起,我们不禁对它产生了强烈的好奇:作为代表荣耀猎人游戏本的跨界新物种,它究竟做了哪些平衡以兼顾不同人群的各类需求呢?