首先可以先看看这篇文章，对锁有些了解
【锁】详解区分 互斥锁、⾃旋锁、读写锁、乐观锁、悲观锁
mutex-互斥锁
mutex 的实现主要借助了 cas 指令 + 自旋 + 信号量
数据结构：
type mutex struct {
state int32
sema uint32
}
上述两个加起来只占 8 字节空间的结构体表示了 go语言中的互斥锁
状态：
在默认情况下，互斥锁的所有状态位都是 0，int32 中的不同位分别表示了不同的状态：
- 1位表示是否被锁定
- 1位表示是否有协程已经被唤醒
- 1位表示是否处于饥饿状态
- 剩下29位表示阻塞的协程数
正常模式和饥饿模式
正常模式：所有goroutine按照fifo的顺序进行锁获取，被唤醒的goroutine和新请求锁的goroutine同时进行锁获取，通常新请求锁的goroutine更容易获取锁(持续占有cpu)，被唤醒的goroutine则不容易获取到锁
饥饿模式：所有尝试获取锁的goroutine进行等待排队，新请求锁的goroutine不会进行锁获取(禁用自旋)，而是加入队列尾部等待获取锁
如果一个 goroutine 获得了互斥锁并且它在队列的末尾或者它等待的时间少于 1ms，那么当前的互斥锁就会切换回正常模式。
与饥饿模式相比，正常模式下的互斥锁能够提供更好地性能，饥饿模式的能避免 goroutine 由于陷入等待无法获取锁而造成的高尾延时。
互斥锁加锁过程
- 如果互斥锁处于初始状态，会直接加锁
- 如果互斥锁处于加锁状态，并且工作在普通模式下，goroutine会进入自旋，等待锁的释放
goroutine 进入自旋的条件非常苛刻：
- 互斥锁只有在普通模式才能进入自旋；
runtime.sync_runtime_canspin需要返回 true运行在多 cpu 的机器上；
当前 goroutine 为了获取该锁进入自旋的次数小于四次；
当前机器上至少存在一个正在运行的处理器 p 并且处理的运行队列为空；
- 如果当前 goroutine 等待锁的时间超过了 1ms，互斥锁就会切换到饥饿模式；
- 互斥锁在正常情况下会通
runtime.sync_runtime_semacquiremutex将尝试获取锁的 goroutine 切换至休眠状态，等待锁的持有者唤醒； - 如果当前 goroutine 是互斥锁上的最后一个等待的协程或者等待的时间小于 1ms，那么它会将互斥锁切换回正常模式；
互斥锁解锁过程
当互斥锁已经被解锁时，再解锁会抛出异常
当互斥锁处于饥饿模式时，将锁的所有权交给等待队列最前面的 goroutine
当互斥锁处于正常模式时，如果没有 goroutine 等待锁的释放或者已经有被唤醒的 goroutine 获得了锁，会直接返回；在其他情况下会通过唤醒对应的 goroutine；
关于互斥锁锁的使用建议写业务时不能全局使用同一个 mutex千万不要将要加锁和解锁分到两个以上 goroutine 中进行mutex 千万不能被复制（包括不能通过函数参数传递），否则会复制传参前锁的状态：已锁定 or 未锁定。很容易产生死锁，关键是编译器还发现不了这个 deadlock~
rwmutex-读写锁
go 中 rwmutex 使用的是写优先的设计
数据结构：
type rwmutex struct {
w mutex //复用互斥锁提供的能力
writersem uint32 //writer信号量
readersem uint32 //reader信号量
readercount int32 //存储了当前正在执行的读操作数量
readerwait int32 // 表示写操作阻塞时，等待读操作完成的个数
}
写锁
获取写锁 ：
- 调用结构体持有的mutex结构体的mutex.lock阻塞后续的写操作
- 将
readercount减少2^30,成为负数，以阻塞后续读操作 - 如果有其他goroutine 持有读锁，该 goroutine会进入休眠状态等待所有读锁执行结束后释放
writersem信号量将当前协程唤醒
释放写锁：
- 将
readercount变回正数，释放读锁 - 唤醒所有因为读锁而睡眠的goroutine
- 调用mutex.unlock 释放写锁
获取写锁时会先阻塞写锁的获取，后阻塞读锁的获取，这种策略能够保证读操作不会被连续的写操作『饿死』。
读锁
获取读锁
获取读锁的方法 sync.rwmutex.rlock 很简单，该方法会将readercount加一：
- 如果该方法返回负数（代表其他 goroutine 获得了写锁，当前 goroutine 就会使其陷入休眠等待锁的释放
- 如果该方法返回结果为非负数，代表没有 goroutine 获得写锁，会成功返回
释放读锁
解锁读锁的方法sync.rwmutex.runlock，该方法会：
- 将
readercount减一，根据返回值的不同会分别进行处理 - 如果返回值大于等于0，读锁直接解锁成功
- 如果小于0代表有正在执行的写操作，会调用
sync.rwmutex.runlockslow，将readerwait减一，并且当所有读操作都被释放后触发信号量writersem，该信号量被触发时，调度器就会唤醒尝试获取写锁的 goroutine
waitgroup
sync.waitgroup可以等待一组 goroutine 的返回
sync.waitgroup 对外暴露了三个方法：
方法
| 方法名 | 功能 |
|---|---|
| (wg * waitgroup) add(delta int) | 计数器+delta |
| (wg *waitgroup) done() | 计数器减1 |
| (wg *waitgroup) wait() | 阻塞直到计数器变为0 |
方法
sync.waitgroup.done只是对 sync.waitgroup.add 方法的简单封装，相当于是加 -1
sync.map
go语言中内置的map不是并发安全的。
go语言的sync包中提供了一个开箱即用的并发安全版map–sync.map。使用互斥锁保证并发安全
数据结构：
type map struct {
mu mutex
read atomic.value // readonly
dirty map[interface{}]*entry
misses int
}
开箱即用表示不用像内置的map一样使用make函数初始化就能直接使用。同时sync.map内置了方法:
| 方法名 | 功能 |
|---|---|
| (m *sync.map)store(key, value interface{}) | 保存键值对 |
| (m *sync.map)load(key interface{}) | 根据key获取对应的值 |
| (m *sync.map)delete(key interface{}) | 删除键值对 |
| (m *sync.map)range(f func(key, value interface{}) bool) | 遍历 sync.map。range 的参数是一个函数 |
*sync.map 没有len( ) 方法
原子操作(atomic包)
代码中的加锁操作因为涉及内核态的上下文切换会比较耗时、代价比较高。针对基本数据类型我们还可以使用原子操作来保证并发安全，因为原子操作是go语言提供的方法它在用户态就可以完成，因此性能比加锁操作更好。go语言中原子操作由内置的标准库sync/atomic提供。
参考资料：
go 语言并发编程、同步原语与锁 | go 语言设计与实现 (draveness.me)
到此这篇关于go语言中并发安全和锁的文章就介绍到这了,更多相关go语言中并发安全和锁内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！
