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

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

				?

									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的一个旧版的值。