本篇内容介绍了“GO的锁和原子操作实例分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
锁 是用于解决隔离性的一种机制
某个协程（线程）在访问某个资源时先锁住，防止其它协程的访问，等访问完毕解锁后其他协程再来加锁进行访问
在我们生活中，我们应该不会陌生，锁是这样的
本意是指置于可启闭的器物上，以钥匙或暗码开启，引申义是用锁锁住、封闭
生活中用到的锁
上锁基本是为了防止外人进来、防止自己财物被盗
编程语言中的锁
锁的种类更是多种多样，每种锁的加锁开销以及应用场景也不尽相同
用来控制各个协程的同步，防止资源竞争导致错乱问题
在高并发的场景下，如果选对了合适的锁，则会大大提高系统的性能，否则性能会降低。
那么知道各种锁的开销，以及应用场景很有必要
GO中的锁有哪些？
互斥锁
读写锁
我们在编码中会存在多个 goroutine 协程同时操作一个资源（临界区），这种情况会发生竞态问题（数据竞态）
举一个生活中的例子
生活中最明显的例子就是，大家抢着上厕所，资源有限，只能一个一个的用
举一个编码中的例子
package main
import (
"fmt"
"sync"
)
// 全局变量
var num int64
var wg sync.WaitGroup
func add() {
for i := 0; i < 10000000; i++ {
num = num + 1
}
// 协程退出， 记录 -1
wg.Done()
}
func main() {
// 启动2个协程，记录 2
wg.Add(2)
go add()
go add()
// 等待子协程退出
wg.Wait()
fmt.Println(num)
}按照上述代码，我们的输出结果应该是 20000000，每一个协程计算 10000000 次，可是实际结果却是
10378923
每一次计算的结果还不一样，出现这个问题的原因就是上述提到的资源竞争
两个 goroutine 协程在访问和修改num变量，会存在2个协程同时对num+1 ， 最终num 总共只加了 1 ，而不是 2
这就导致最后的结果与期待的不符，那么我们如何解决呢？
我们当然是用锁控制同步了，保证各自协程在操作临界区资源的时候，先确实是否拿到锁，只有拿到锁了才能进行对临界区资源的修改
先来看看互斥锁
互斥锁的简单理解就像上述我们讲到上厕所的案例一样，同一时间点，只能有一个人在使用其他人只能排队等待
在编程中，引入了对象互斥锁的概念，来保证共享数据操作的完整性
每个对象都对应于一个可称为互斥锁的标记，这个标记用来保证在任一时刻，只能有一个协程访问该对象。
应用场景
写大于读操作的
它代表的资源就是一个，不管是读者还是写者，只要谁拥有了它，那么其他人就只有等待解锁后
我们来使用互斥锁解决上述的问题
互斥锁是一种常用的控制共享资源访问的方法，它能够保证同时只有一个 goroutine 协程可以访问共享资源
Go 中使用到如下 1个知识点来解决
sync包 的 Mutex类型 来实现互斥锁
package main
import (
"fmt"
"sync"
)
// 全局变量
var num int64
var wg sync.WaitGroup
var lock sync.Mutex
func add() {
for i := 0; i < 10000000; i++ {
// 访问资源前 加锁
lock.Lock()
num = num + 1
// 访问资源后 解锁
lock.Unlock()
}
// 协程退出， 记录 -1
wg.Done()
}
func main() {
// 启动2个协程，记录 2
wg.Add(2)
go add()
go add()
// 等待子协程退出
wg.Wait()
fmt.Println(num)
}执行上述代码，我们能看到，输出的结果与我们预期的一致
20000000
使用互斥锁能够保证同一时间有且只有一个goroutine 协程进入临界区，其他的goroutine则在等待锁
当互斥锁释放后，等待的 goroutine 协程才可以获取锁进入临界区
如何知道哪一个协程是先被唤醒呢？
可是，多个goroutine 协程同时等待一个锁时，如何知道哪一个协程是先被唤醒呢？
互斥锁这里的唤醒的策略是随机的，并不知道到底是先唤醒谁
为什么有了互斥锁 ，还要读写锁呢？
很明显就是互斥锁不能满足所有的应用场景，就催生出了读写锁，我们细细道来
互斥锁是完全互斥的，不管协程是读临界区资源还是写临界区资源，都必须要拿到锁，否则就无法操作（这个限制太死了对吗)
可是在我们实际的应用场景下是读多写少
若我们并发的去读取一个资源，且不对资源做任何修改的时候如果也要加锁才能读取数据，是不是就很没有必要呢
这种场景下读写锁就发挥作用了，他就相对灵活了，也很好的解决了读多写少的场景问题
读写锁的种类
读锁
写锁
当一个goroutine 协程获取读锁之后，其他的 goroutine 协程如果是获取读锁会继续获得锁
可如果是获取写锁就必须等待
当一个 goroutine 协程获取写锁之后，其他的goroutine 协程无论是获取读锁还是写锁都会等待
Go 中使用到如下 1个知识点来解决
sync包 的 RWMutex类型 来实现读写锁
package main
import (
"fmt"
"sync"
"time"
)
var (
num int64
wg sync.WaitGroup
//lock sync.Mutex
rwlock sync.RWMutex
)
func write() {
// 加互斥锁
// lock.Lock()
// 加写锁
rwlock.Lock()
num = num + 1
// 模拟真实写数据消耗的时间
time.Sleep(10 * time.Millisecond)
// 解写锁
rwlock.Unlock()
// 解互斥锁
// lock.Unlock()
// 退出协程前 记录 -1
wg.Done()
}
func read() {
// 加互斥锁
// lock.Lock()
// 加读锁
rwlock.RLock()
// 模拟真实读取数据消耗的时间
time.Sleep(time.Millisecond)
// 解读锁
rwlock.RUnlock()
// 解互斥锁
// lock.Unlock()
// 退出协程前 记录 -1
wg.Done()
}
func main() {
// 用于计算时间 消耗
start := time.Now()
// 开5个协程用作 写
for i := 0; i < 5; i++ {
wg.Add(1)
go write()
}
// 开500 个协程，用作读
for i := 0; i < 1000; i++ {
wg.Add(1)
go read()
}
// 等待子协程退出
wg.Wait()
end := time.Now()
// 打印程序消耗的时间
fmt.Println(end.Sub(start))
}我们开5个协程用于写，开1000个协程用于读，使用读写锁加锁，结果耗时 54.4871ms 如下
54.4871ms
如果我们将上述代码修改成加 互斥锁，运行之后的结果是 1.7750029s 如下
1.7750029s
是不是结果相差很大呢，对于不同的场景应用不同的锁，对于我们的程序性能影响也是很大，当然上述结果，若读协程，和写协程的个数差距越大，结果就会越悬殊
我们总结一下这一小块的逻辑：
写者是排他性的，一个读写锁同时只能有一个写者或多个读者
不能同时既有读者又有写者
如果读写锁当前没有读者，也没有写者，那么写者可以立刻获得读写锁，否则它必须自旋在那里，直到没有任何写者或读者。
如果读写锁没有写者，那么读者可以立即获得该读写锁，否则读者必须自旋在那里，直到写者释放该读写锁。
上述提了自旋锁，我们来简单解释一下，什么是自旋锁
自旋锁是专为防止多处理器并发而引入的一种锁，它在内核中大量应用于中断处理等部分（对于单处理器来说，防止中断处理中的并发可简单采用关闭中断的方式，即在标志寄存器中关闭/打开中断标志位，不需要自旋锁）。
简单来说，在并发过程中，若其中一个协程拿不到锁，他会不停的去尝试拿锁，不停的去看能不能拿，而不是阻塞睡眠
互斥锁
当拿不到锁的时候，会阻塞等待，会睡眠，等待锁释放后被唤醒
自旋锁
当拿不到锁的时候，会在原地不停的看能不能拿到锁，所以叫做自旋，他不会阻塞，不会睡眠
对于 C/C++ 而言
若加锁后的业务操作消耗，大于互斥锁阻塞后切换上下文的消耗 ，那么就选择互斥锁
若加锁后的业务操作消耗，小于互斥锁阻塞后切换上下文的消耗，那么选择自旋锁
对于 GO 而言
若写的频次大大的多余读的频次，那么选择互斥锁
若读的频次大大的多余写的频次，那么选择读写锁
我们都是对自身要求比较高的同学，那么有没有比锁还好用的东西呢？
自然是有的，我们来看看原子操作
"原子操作(atomic operation)是不需要synchronized"，这是多线程编程的老生常谈了。所谓原子操作是指不会被线程调度机制打断的操作
这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。
原子操作的特性：
原子操作是不可分割的，在执行完毕之前不会被任何其它任务或事件中断
上述我们的加锁案例，咱们编码中的加锁操作会涉及内核态的上下文切换会比较耗时、代价比较高
针对基本的数据类型我们还可以使用原子操作来保证并发安全
因为原子操作是Go语言提供的方法它在用户态就可以完成，因此性能比加锁操作更好
不用我们自己写汇编，这里 GO 也提供了原子操作的包，供我们一起来使用 sync/atomic
我们对上述的案例做一个延伸
package main
import (
"fmt"
"sync"
"sync/atomic"
"time"
)
var num int64
var l sync.Mutex
var wg sync.WaitGroup
// 普通版加函数
func add() {
num = num + 1
wg.Done()
}
// 互斥锁版加函数
func mutexAdd() {
l.Lock()
num = num + 1
l.Unlock()
wg.Done()
}
// 原子操作版加函数
func atomicAdd() {
atomic.AddInt64(&num, 1)
wg.Done()
}
func main() {
// 目的是 记录程序消耗时间
start := time.Now()
for i := 0; i < 20000; i++ {
wg.Add(1)
// go add() // 无锁的 add函数 不是并发安全的
// go mutexAdd() // 互斥锁的 add函数 是并发安全的，因为拿不到互斥锁会阻塞，所以加锁性能开销大
go atomicAdd() // 原子操作的 add函数 是并发安全，性能优于加锁的
}
// 等待子协程 退出
wg.Wait()
end := time.Now()
fmt.Println(num)
// 打印程序消耗时间
fmt.Println(end.Sub(start))
}我们使用上述 demo 代码，模拟了3种情况下，程序的耗时以及计算结果对比
不加锁
无锁的 add函数 不是并发安全的
19495
11.9474ms
加互斥锁
互斥锁的 add函数 是并发安全的，因为拿不到互斥锁会阻塞，所以加锁性能开销大
20000
14.9586ms
使用原子操作
原子操作的 add函数 是并发安全，性能优于加锁的
20000
9.9726ms
“GO的锁和原子操作实例分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
