文章目录
Mutex锁
mutex源码分析
Locker接口:
type Locker interface {
Lock()
Unlock()
}
在 Go 的 sync
包中,Mutex
是一个用于互斥锁的结构体,其中 state
表示锁的状态,而 sema
是用于信号量的字段,它在需要阻塞或者唤醒等待的 goroutine 时发挥作用。Mutex 就实现了这个接口,Lock请求锁,Unlock释放锁
type Mutex struct {
state int32 //锁状态,保护四部分含义
sema uint32 //信号量,用于阻塞等待或者唤醒
}
-
Locked:表示该 mutex 是否被锁定,0 表示没有,1 表示处于锁定状态;
-
Woken:表示是否有协程被唤醒,0 表示没有,1 表示有协程处于唤醒状态,并且在加锁过程中;
-
Starving:Go1.9 版本之后引入,表示 mutex 是否处于饥饿状态,0 表示没有,1 表示有协程处于饥饿状态;
-
Waiter: 等待锁的协程数量。
const (
// mutex is locked ,在低位,值 1
mutexLocked = 1 << iota
//标识有协程被唤醒,处于 state 中的第二个 bit 位,值 2
mutexWoken
//标识 mutex 处于饥饿模式,处于 state 中的第三个 bit 位,值 4
mutexStarving
// 值 3,state 值通过右移三位可以得到 waiter 的数量
// 同理,state += 1 << mutexWaiterShift,可以累加 waiter 的数量
mutexWaiterShift = iota
// 标识协程处于饥饿状态的最长阻塞时间,当前被设置为 1ms
starvationThresholdNs = 1e6
)
Lock
func (m *Mutex) Lock() {
// Fast path: grab unlocked mutex. //运气好,直接加锁成功
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
if race.Enabled {
race.Acquire(unsafe.Pointer(m))
}
return
}
// Slow path (outlined so that the fast path can be inlined)
//内联,加锁失败,就得去自旋竞争或者饥饿模式下竞争
m.lockSlow()
}
func (m *Mutex) lockSlow() {
var waitStartTime int64
// 标识是否处于饥饿模式
starving := false
// 唤醒标记
awoke := false
// 自旋次数
iter := 0
old := m.state
for {
// 非饥饿模式下,开启自旋操作
// 从 runtime_canSpin(iter) 的实现中(runtime/proc.sync_runtime_canSpin)可以知道,
// 如果 iter 的值大于 4,将返回 false
if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
// 如果没有其他 waiter 被唤醒,那么将当前协程置为唤醒状态,同时 CAS 更新 mutex 的 Woken 位
if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
awoke = true
}
// 开启自旋
runtime_doSpin()
iter++
// 重新检查 state 的值
old = m.state
continue
}
new := old
// 非饥饿状态
if old&mutexStarving == 0 {
// 当前协程可以直接加锁
new |= mutexLocked
}
// mutex 已经被锁住或者处于饥饿模式
// 那么当前协程不能获取到锁,将会进入等待状态
if old&(mutexLocked|mutexStarving) != 0 {
// waiter 数量加 1,当前协程处于等待状态
new += 1 << mutexWaiterShift
}
// 当前协程处于饥饿状态并且 mutex 依然被锁住,那么设置 mutex 为饥饿模式
if starving && old&mutexLocked != 0 {
new |= mutexStarving
}
if awoke {
if new&mutexWoken == 0 {
throw("sync: inconsistent mutex state")
}
// 清除唤醒标记
// &^ 与非操作,mutexWoken: 10 -> 01
// 此操作之后,new 的 Locked 位值是 1,如果能够成功写入到 m.state 字段,那么当前协程获取锁成功
new &^= mutexWoken
}
// CAS 设置新状态成功
if atomic.CompareAndSwapInt32(&m.state, old, new) {
// 旧的锁状态已经被释放并且处于非饥饿状态
// 这个时候当前协程正常请求到了锁,就可以直接返回了
if old&(mutexLocked|mutexStarving) == 0 {
break
}
// 处理当前协程的饥饿状态
// 如果之前已经处于等待状态了(已经在队列里面),那么将其加入到队列头部,从而可以被高优唤醒
queueLifo := waitStartTime != 0
if waitStartTime == 0 {
// 阻塞开始时间
waitStartTime = runtime_nanotime()
}
// P 操作,阻塞等待
runtime_SemacquireMutex(&m.sema, queueLifo, 1)
// 唤醒之后,如果当前协程等待超过 1ms,那么标识当前协程处于饥饿状态
starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
old = m.state
// mutex 已经处于饥饿模式
if old&mutexStarving != 0 {
// 1. 如果当前协程被唤醒但是 mutex 还是处于锁住状态
// 那么 mutex 处于非法状态
//
// 2. 或者如果此时 waiter 数量是 0,并且 mutex 未被锁住
// 代表当前协程没有在 waiters 中,但是却想要获取到锁,那么 mutex 状态非法
if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
throw("sync: inconsistent mutex state")
}
// delta 代表加锁并且将 waiter 数量减 1 两步操作
delta := int32(mutexLocked - 1<<mutexWaiterShift)
// 非饥饿状态 或者 当前只剩下一个 waiter 了(就是当前协程本身)
if !starving || old>>mutexWaiterShift == 1 {
// 那么 mutex 退出饥饿模式
delta -= mutexStarving
}
// 设置新的状态
atomic.AddInt32(&m.state, delta)
break
}
awoke = true
iter = 0
} else {
old = m.state
}
}
if race.Enabled {
race.Acquire(unsafe.Pointer(m))
}
}
解锁操作会根据 Mutex.state 的状态来判断需不需要去唤醒其他等待中的协程。
func (m *Mutex) unlockSlow(new int32) {
// new - state 字段原子减 1 之后的值,如果之前是处于加锁状态,那么此时 new 的末位应该是 0
// 此时 new+mutexLocked 正常情况下会将 new 末位变成 1
// 那么如果和 mutexLocked 做与运算之后的结果是 0,代表 new 值非法,解锁了一个未加锁的 mutex
if (new+mutexLocked)&mutexLocked == 0 {
throw("sync: unlock of unlocked mutex")
}
// 如果不是处于饥饿状态
if new&mutexStarving == 0 {
old := new
for {
// old>>mutexWaiterShift == 0 代表没有等待加锁的协程了,自然不需要执行唤醒操作
// old&mutexLocked != 0 代表已经有协程加锁成功,此时没有必要再唤醒一个协程(因为它不可能加锁成功)
// old&mutexWoken != 0 代表已经有协程被唤醒并且在加锁过程中,此时不需要再执行唤醒操作了
// old&mutexStarving != 0 代表已经进入了饥饿状态,
// 以上四种情况,皆不需要执行唤醒操作
if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
return
}
// 唤醒一个等待中的协程,将 state woken 位置为 1
// old - 1<<mutexWaiterShift waiter 数量减 1
new = (old - 1<<mutexWaiterShift) | mutexWoken
if atomic.CompareAndSwapInt32(&m.state, old, new) {
runtime_Semrelease(&m.sema, false, 1)
return
}
old = m.state
}
} else {
// 饥饿模式
// 将 mutex 的拥有权转移给下一个 waiter,并且交出 CPU 时间片,从而能够让下一个 waiter 立刻开始执行
runtime_Semrelease(&m.sema, true, 1)
}
}
UnLock
// 解锁操作
func (m *Mutex) Unlock() {
if race.Enabled {
_ = m.state
race.Release(unsafe.Pointer(m))
}
// mutexLocked 位设置为 0,解锁
new := atomic.AddInt32(&m.state, -mutexLocked)
// 如果此时 state 值不是 0,代表其他位不是 0(或者出现异常使用导致 mutexLocked 位也不是 0)
// 此时需要进一步做一些其他操作,比如唤醒等待中的协程等
if new != 0 {
m.unlockSlow(new)
}
}
信号量如何唤醒等待的goroutine
当一个 goroutine 尝试获取已经被锁定的 Mutex
时,如果锁不可用,goroutine 就会被阻塞。sema
字段在这个过程中起到了关键作用。具体过程如下:
-
获取锁失败:如果
Mutex
已经被其他 goroutine 锁定,那么尝试获取锁的 goroutine 会将自己加入等待队列,并被阻塞。 -
信号量作用:当其他 goroutine 释放这个锁时,
Mutex
会通过sema
来通知(唤醒)等待队列中的一个或多个被阻塞的 goroutine,表示锁现在已经可用。 -
唤醒等待的 goroutine:被唤醒的 goroutine 会从等待队列中取出,尝试重新获取锁。如果成功,则继续执行;如果仍然失败,则可能会继续阻塞或重试获取。
在 sync.Mutex
中,实际的信号量操作是通过 runtime_Semrelease
和 runtime_Semacquire
这两个底层函数来实现的:
runtime_Semacquire
:用于阻塞当前 goroutine,等待信号量释放。当锁不可用时调用。runtime_Semrelease
:用于释放信号量,唤醒被阻塞的 goroutine。当锁被释放时调用。
这种机制确保了多个 goroutine 在访问共享资源时不会发生竞态条件,并能按照一定的顺序安全地访问共享资源。
等待队列在哪里保存
在 Go 的 sync.Mutex
实现中,等待队列并不显式地存在于 Mutex
结构体中,而是由 Go 运行时系统在底层管理的。
当一个 goroutine 尝试获取锁并且失败时,它会被阻塞并放入一个由 Go 运行时管理的内部等待队列中。这个等待队列的管理和调度是通过 Go 运行时的调度器(scheduler)来完成的,具体细节涉及到 Go 运行时的一些底层数据结构和机制,如 Goroutine 的状态管理、P(处理器)的管理等。
简而言之:
-
内部管理:等待队列由 Go 运行时管理,并且与具体的
Mutex
结构体的实现细节是解耦的。Mutex
结构体中不会直接保存这个队列。 -
Goroutine 阻塞与唤醒:当 goroutine 需要等待时,Go 运行时会将其阻塞,并将其状态设置为等待信号量。这些 goroutine 会被组织到一个隐式的等待队列中,当锁释放时,Go 运行时通过信号量机制选择一个或多个 goroutine 并唤醒它们。
-
runtime 包中的实现:Go 语言的
runtime
包负责这一过程,它使用了底层的系统调用和数据结构来实现 goroutine 的阻塞和唤醒。
因此,等待队列的管理是隐式的,不直接暴露在 Mutex
结构体中,而是由 Go 运行时系统在后台处理。
mutex两种运行模式
Go1.9 引入饥饿模式,尽可能让等待较长的goroutine有多更激活获取锁
饥饿模式是对公平性和性能的一种平衡,它避免了某些 goroutine 长时间的等待锁。在饥饿模式下,优先对待的是那些一直在等待的 waiter。
mutex normal 正常模式
默认情况下,Mutex的模式为normal。
该模式下,协程如果加锁不成功不会立即转入阻塞排队,而是判断是否满足自旋的条件,如果满足则会启动自旋过程,尝试抢锁。
正常模式 高吞吐量
自旋
自旋是一种多线程同步机制,当前的进程在进入自旋的过程中会一直保持 CPU 的占用,持续检查某个条件是否为真。
在多核的 CPU 上,自旋可以避免 Goroutine 的切换,使用恰当会对性能带来很大的增益,但是使用的不恰当就会拖慢整个程序,所以 Goroutine 进入自旋的条件非常苛刻:
- 互斥锁只有在普通模式才能进入自旋;
- runtime.sync_runtime_canSpin 需要返回 true:
运行在多 CPU 的机器上 - 当前 Goroutine 为了获取该锁进入自旋的次数小于四次;
- 当前机器上至少存在一个正在运行的处理器 P 并且处理的运行队列为空;
https://draveness.me/golang/docs/part3-runtime/ch06-concurrency/golang-sync-primitives/
mutex starvation 饥饿模式
自旋过程中能抢到锁,一定意味着同一时刻有协程释放了锁,我们知道释放锁时如果发现有阻塞等待的协程,还会释放一个信号量来唤醒一个等待协程,被唤醒的协程得到CPU后开始运行,此时发现锁已被抢占了,自己只好再次阻塞,不过阻塞前会判断自上次阻塞到本次阻塞经过了多长时间,如果超过1ms的话,会将Mutex标记为"饥饿"模式,然后再阻塞。
处于饥饿模式下,不会启动自旋过程,也即一旦有协程释放了锁,那么一定会唤醒协程,被唤醒的协程将会成功获取锁,同时也会把等待计数减1。
在饥饿模式下,Mutex 的拥有者将直接把锁交给队列最前面的 waiter。新来的 goroutine 不会尝试获取锁,即使看起来锁没有被持有,它也不会去抢,也不会 spin(自旋),它会乖乖地加入到等待队列的尾部。
如果拥有 Mutex 的 waiter 发现下面两种情况的其中之一,它就会把这个 Mutex 转换成正常模式:
- 此 waiter 已经是队列中的最后一个 waiter 了,没有其它的等待锁的 goroutine 了;
- 此 waiter 的等待时间小于 1 毫秒(ms)。
锁的底层实现类型
锁内存总线,针对内存的读写操作,在总线上控制,限制程序的内存访问
锁缓存行,同一个缓存行的内容读写操作,CPU内部的高速缓存保证一致性
锁,作用在一个对象或者变量上。现代CPU会优先在高速缓存查找,如果存在这个对象、变量的缓存行数据,会使用锁缓存行的方式。否则,才使用锁总线的方式。
RWMutex
RWMutex 源码
type RWMutex struct {
w Mutex // 复用互斥锁能力
//写锁信号量 当阻塞写操作的读操作goroutine释放读锁时,通过该信号量通知阻塞的写操作的goroutine;
writerSem uint32
// 读锁信号量 当写操作goroutine释放写锁时,通过该信号量通知阻塞的读操作的goroutine
readerSem uint32
// 当前读操作的数量,包含所有已经获取到读锁或者被写操作阻塞的等待获取读锁的读操作数量
readerCount int32
// 获取写锁需要等待读锁释放的数量
readerWait int32
}
通过记录 readerCount 读锁的数量来进行控制,当有一个写锁的时候,会将读 锁数量设置为负数 1<<30。目的是让新进入的读锁等待之前的写锁释放通知读 锁。同样的当有写锁进行抢占时,也会等待之前的读锁都释放完毕,才会开始 21 进行后续的操作。 而等写锁释放完之后,会将值重新加上 1<<30, 并通知刚才 新进入的读锁(rw.readerSem),两者互相限制。
const rwmutexMaxReaders = 1 << 30
func (rw *RWMutex) Lock() {
// First, resolve competition with other writers.
// 写锁也就是互斥锁,复用互斥锁的能力来解决与其他写锁的竞争
// 如果写锁已经被获取了,其他goroutine在获取写锁时会进入自旋或者休眠
rw.w.Lock()
// 将readerCount设置为负值,告诉读锁现在有一个正在等待运行的写锁(获取互斥锁成功)
r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
// 获取互斥锁成功并不代表goroutine获取写锁成功,我们默认最大有2^30的读操作数目,减去这个最大数目
// 后仍然不为0则表示前面还有读锁,需要等待读锁释放并更新写操作被阻塞时等待的读操作goroutine个数;
if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
runtime_SemacquireMutex(&rw.writerSem, false, 0)
}
}
func (rw *RWMutex) Unlock() {
// Announce to readers there is no active writer.
// 将readerCount的恢复为正数,也就是解除对读锁的互斥
r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
if r >= rwmutexMaxReaders {
race.Enable()
throw("sync: Unlock of unlocked RWMutex")
}
// 如果后面还有读操作的goroutine则需要唤醒他们
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0)
}
// 释放互斥锁,写操作的goroutine和读操作的goroutine同时竞争
rw.w.Unlock()
}
读锁
func (rw *RWMutex) RLock() {
// 原子操作readerCount 只要值不是负数就表示获取读锁成功
if atomic.AddInt32(&rw.readerCount, 1) < 0 {
// 有一个正在等待的写锁,为了避免饥饿后面进来的读锁进行阻塞等待
runtime_SemacquireMutex(&rw.readerSem, false, 0)
}
}
func (rw *RWMutex) RUnlock() {
// 将readerCount的值减1,如果值等于等于0直接退出即可;否则进入rUnlockSlow处理
if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
// Outlined slow-path to allow the fast-path to be inlined
rw.rUnlockSlow(r)
}
}
读写锁的基本使用
在 Go 中,读写锁(sync.RWMutex)允许多个 goroutine 同时读取共享资源,但在写入时,必须独占锁,即只有一个 goroutine 能够进行写操作,且在写操作期间不允许其他 goroutine 进行读操作。
读写锁的基本使用包括:
- 读锁:使用 RLock() 方法加读锁,RUnlock() 方法释放读锁。
- 写锁:使用 Lock() 方法加写锁,Unlock() 方法释放写锁。
var rwMutex sync.RWMutex
var sharedData int
func readData() int {
rwMutex.RLock() // 加读锁
defer rwMutex.RUnlock() // 在函数返回时释放读锁
return sharedData // 读取共享数据
}
func writeData(data int) {
rwMutex.Lock() // 加写锁
defer rwMutex.Unlock() // 在函数返回时释放写锁
sharedData = data // 写入共享数据
}
读写锁代码示例
package main
import (
"fmt"
"sync"
"time"
)
var (
rwMutex sync.RWMutex
sharedData int
wg sync.WaitGroup
)
func readData(id int) {
defer wg.Done()
rwMutex.RLock()
fmt.Printf("Goroutine %d: Reading data: %d\n", id, sharedData)
time.Sleep(time.Second)
rwMutex.RUnlock()
}
func writeData(id, data int) {
defer wg.Done()
rwMutex.Lock()
fmt.Printf("Goroutine %d: Writing data: %d\n", id, data)
sharedData = data
time.Sleep(time.Second)
rwMutex.Unlock()
}
func main() {
wg.Add(3)
go readData(1)
go readData(2)
go writeData(3, 42)
wg.Wait()
fmt.Println("Final data:", sharedData)
}
在这个例子中,两个 goroutine 同时读取共享数据,而另一个 goroutine 写入数据。写操作会等待当前的读操作完成,然后才能进行写入。
其他共享内存线程安全的方式
官方不太推荐使用锁,更多的是通过channel做数据交换
思考
如何设计一个并发更高的锁?
在Go语言中,使用切片来设计并发更高效的锁是一种常见的做法,通常被称为"分段锁"或"分片锁"。
这种技术可以在一定程度上减小锁的粒度,从而提高并发性能。
package main
import (
"fmt"
"sync"
"hash/fnv"
)
const numSegments = 16
type ConcurrentMap struct {
segments []sync.Mutex
data map[interface{}]interface{}
}
func NewConcurrentMap() *ConcurrentMap {
segments := make([]sync.Mutex, numSegments)
data := make(map[interface{}]interface{})
return &ConcurrentMap{segments: segments, data: data}
}
func (cm *ConcurrentMap) getSegment(key interface{}) *sync.Mutex {
hash := hashFunction(key) % numSegments
return &cm.segments[hash]
}
func (cm *ConcurrentMap) Get(key interface{}) interface{} {
segment := cm.getSegment(key)
segment.Lock()
defer segment.Unlock()
return cm.data[key]
}
func (cm *ConcurrentMap) Set(key, value interface{}) {
segment := cm.getSegment(key)
segment.Lock()
defer segment.Unlock()
cm.data[key] = value
}
// 假设的哈希函数,仅用于示例目的
func hashFunction(key interface{}) int {
h := fnv.New32a()
// 将键的字节表示写入哈希函数
_, _ = h.Write([]byte(fmt.Sprintf("%v", key)))
return int(h.Sum32())
}
func main() {
concurrentMap := NewConcurrentMap()
var wg sync.WaitGroup
numItems := 1000
for i := 0; i < numItems; i++ {
wg.Add(1)
go func(index int) {
defer wg.Done()
key := fmt.Sprintf("key%d", index)
concurrentMap.Set(key, index)
}(i)
}
wg.Wait()
// 输出结果
for i := 0; i < numItems; i++ {
key := fmt.Sprintf("key%d", i)
fmt.Printf("%s: %v\n", key, concurrentMap.Get(key))
}
}