在Golang中是锁或Channel还是Atomic

Posted 2021-06-19 LxFly

  与其他编程语言一样在并发环境下如不对多个goroutine（线程）访问或修改的共享资源元素的进行控制，让进入临界区的对象互斥。就可能会出现数据异常情况；
  一个非线程安全对象如下，如不对Id的访问进行控制，多个goroutine进行更新Id字段是就会出现数据不一致的情况，如下示例：

type Conf struct {
  Id int32
}
func(c *Conf)update(n int32){
  c.Id +=n
}

  启动100个goroutine用于更新对象c中的Id字段值，此时由于出现多个协程同时进入临界区同时对Id变量进行修改。导致对象c中的Id字段值出现了不可预知的情况。此时程序输出的结果可能是：98、93、95等；

func main() {
 var c=&Conf{}
 for i := 0; i<100;i++  {
	go func(n int) {
		//模拟停顿
		time.Sleep(1*time.Millisecond)
		c.update(1)
	}(i)
 }
time.Sleep(10*time.Second)
fmt.Println(c.Id)
}

  下面分别使用锁与channel对临界区进行并发控制，使得输出得到正常的结果，并简单对比两者的性能；

使用锁

  现在在结构体Conf中添加一个读写锁变量sync.RWMutex，此时Conf继承了RWMutex中所有的方法字段等。通过此对象就可以对Id变量的访问进行加锁， struct变为如下：

type Conf struct {
  Id int32
  sync.RWMutex
}

定义一个新方法，此方法使用了锁对临界区访问进行了并发控制：

func(c *Conf) updateOfLock(n int32){
   c.Lock()
   defer c.Unlock()
   c.Id +=n
}

  此时程序总是能够输出正确的结果：100

func main() {
var c=&Conf{}
for i := 0; i<100;i++  {
	go func(n int) {
		//模拟停顿
		time.Sleep(1*time.Millisecond)
		c.updateOfLock(1)
	}(i)
}
time.Sleep(10*time.Second)
fmt.Println(c.Id)
}

使用channel

  用channel控制临界资源的访问，原理也非常简单，创建一个长度为1的channel变量，进去临界区前往channel中写入一个值，由于长度为1，此时别的协程将无法往channel中写入值堵塞在此处channel上，前一个协程访问完临界区后从channel读取值，此后别的协程可再此往channel中写入值，从而能够进入临界区，结构体修改如下；

type Conf struct {
   Id int32
   lockChan chan bool
}
func (c *Conf) updateOfChannel(n int32) {
   c.lockChan<-true
   defer func() {<-c.lockChan}()
   c.Id +=n
}

  使用channel进行并发控制，需要注意取出lockChan中的值，此处使用了defer用于控制channel值的释放。

 func main() {
    var c=&Conf{lockChan: make(chan bool,1)}
     for i := 0; i<100;i++  {
	go func(n int) {
		//模拟停顿
		time.Sleep(1*time.Millisecond)
		c.updateOfChannel(1)
	}(i)
     }
time.Sleep(10*time.Second)
fmt.Println(c.Id)
}

原子变量

  无需修改Conf结构体，直接调用atomic的相关方法即可，方法如下，此时也是能够得到正确的值；

  func (c *Conf) updateOfAtomic(n int32) {
    atomic.AddInt32(&c.Id,n)
  }

性能简单对比

  通过跑Golang基准测试看看锁、原子变量、channel三者的性能如何，毫无疑问原子变量肯定是性能最好的，这是对底层的CAS操作连临界区都没有产生；这里主要对比锁与channel性能，三个测试函数都和下函数类似；

 func BenchmarkAtomicTest(b *testing.B) {
    var c=&Conf{}
     for i := 0; i<b.N;i++  {
       c.updateOfAtomic(1)
    }
}

  此时可以看到毫无悬念的atomic原子操作的方式性能最高，比其他两种低一个数量级，锁的方式比channel时间快了一倍，每次平均执行时间只需44.45纳秒，而channel每次需要84.12ns纳秒；当然此处的只是简单对比；

  能用atomic时肯定是用atomic，至于锁和channel选哪个，还是要看应用场景、业务逻辑、可维护性等，总体来说两者性能差别不算太大，如果不太熟悉channel在过于复杂的业务逻辑中channel或许可读性会降低；但golang中的两个核心就是goroutine和channel；