golang中单机锁的具体实现详解

发布者: 皮3591 | 发布时间: 2025-8-14 10:30| 查看数: 32| 评论数: 0|帖子模式

1、锁的概念引入

首先，为什么需要锁？
在并发编程中，多个线程或进程可能同时访问和修改同一个共享资源（例如变量、数据结构、文件）等，若不引入合适的同步机制，会引发以下问题：

数据竞争：多个线程同时修改一个资源，最终的结果跟线程的执行顺序有关，结果是不可预测的。
数据不一致：一个线程在修改资源，而另一个线程读取了未修改完的数据，从而导致读取了错误的数据。
资源竞争：多线程竞争同一个资源，浪费系统的性能。

因此，我们需要一把锁，来保证同一时间只有一个人能写数据，确保共享资源在并发访问下的正确性和一致性。
在这里，引入两种常见的并发控制处理机制，即乐观锁与悲观锁：
乐观锁：假定在并发操作中，资源的抢占并不是很激烈，数据被修改的可能性不是很大，那这时候就不需要对共享资源区进行加锁再操作，而是先修改了数据，最终来判断数据有没有被修改，没有被修改则提交修改指，否则重试。
悲观锁：与乐观锁相反，它假设场景的资源竞争激烈，对共享资源区的访问必须要求持有锁。
针对不同的场景需要采取因地制宜的策略，比较乐观锁与悲观所，它们的优缺点显而易见：
策略优点缺点乐观锁不需要实际上锁，性能高若冲突时，需要重新进行操作，多次重试可能会导致性能下降明显悲观锁访问数据一定需要持有锁，保证并发场景下的数据正确性加锁期间，其他等待锁的线程需要被阻塞，性能低
2、Sync.Mutex

Go对单机锁的实现，考虑了实际环境中协程对资源竞争程度的变化，制定了一套锁升级的过程。具体方案如下：

首先采取乐观的态度，Goroutine会保持自旋态，通过CAS操作尝试获取锁。
当多次获取失败，将会由乐观态度转入悲观态度，判定当前并发资源竞争程度剧烈，进入阻塞态等待被唤醒。

从乐观转向悲观的判定规则如下，满足其中之一即发生转变：

Goroutine自旋尝试次数超过4次
当前P的执行队列中存在等待被执行的G（避免自旋影响GMP调度性能）
CPU是单核的（其他Goroutine执行不了，自旋无意义）

除此之外，为了防止被阻塞的协程等待过长时间也没有获取到锁，导致用户的整体体验下降，引入了饥饿的概念：

饥饿态：若Goroutine被阻塞等待的时间>1ms，则这个协程被视为处于饥饿状态
饥饿模式：表示当前锁是否处于特定的模式，在该模式下，锁的交接是公平的，按顺序交给等待最久的协程。

饥饿模式与正常模式的转变规则如下：
普通模式->饥饿模式：存在阻塞的协程，阻塞时间超过1ms
饥饿模式->普通模式：阻塞队列清空，亦或者获得锁的协程的等待时间小于1ms，则恢复
接下来步入源码，观看具体的实现。

2.1、数据结构

位于包sync/mutex.go中，对锁的定义如下：

type Mutex struct {
state int32
sema uint32
}

复制代码

state：标识目前锁的状态信息，包括了是否处于饥饿模式、是否存在唤醒的阻塞协程、是否上锁、以及处于等待锁的协程个数有多少。
seme：用于阻塞和唤醒协程的信号量。

将state看作一个二进制字符串，它存储信息的规则如下：

第一位标识是否处于上锁，0表示否，1表示上锁（mutexLocked）
第二位标识是否存在唤醒的阻塞协程（mutexWoken）
第三位标识是否处于饥饿模式（mutexStarving）
从第四位开始，记录了处于阻塞态的协程个数

const (
mutexLocked = 1 << iota // mutex is locked
mutexWoken
mutexStarving
mutexWaiterShift = iota
starvationThresholdNs = 1e6 //饥饿阈值
)

复制代码

2.2、获取锁Lock()

func (m *Mutex) Lock() {
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
return
}
m.lockSlow()
}

复制代码

尝试直接通过CAS操作直接获取锁，若成功则返回，否则说明锁被获取，步入LockSlow。

2.3、LockSlow()

源码较长，进行拆分讲解：

var waitStartTime int64
starving := false
awoke := false
iter := 0
old := m.state

复制代码

（1）定义了基本的常量，含义如下：

waitStartTime：记录当前协程等待的时间，只有被阻塞才会使用
awoke：标识当前协程是否被Unlock唤醒
iter：记录当前协程自旋尝试次数
old：记录旧的锁的状态信息

for {
//处于上锁状态，并且不处于饥饿状态中，并且当前的协程允许继续自旋下去
if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
awoke = true
}
runtime_doSpin()
iter++
old = m.state
continue
}
//...
}

复制代码

（2）进入尝试获取锁的循环中，两个if表示：

若锁处于上锁状态，并且不处于饥饿状态中，并且当前的协程允许继续自旋下去（非单核CPU、自旋次数<=4、调度器P的本地队列不存在等待执行的G），则步入：
- 若当前协程并非从等待队列唤醒、并且不存在被唤醒的等待协程、并且存在位于阻塞的协程、则尝试设置mutexWoken标识为1，若成功：
  - 标识当前的协程为被唤醒的协程。（虽然并非实际从阻塞中唤醒）
- 告诉P，当前的协程处于自旋态
- 更新
  1. iter
  复制代码
  计数器，与
  1. old
  复制代码
  记录的当前锁的状态信息，进行下一次重试循环

这里存在的唯一疑惑为，为什么要将awoke标识为true？
首先，因为当前锁并非处于饥饿模式，因此当前的抢占锁的模式是不公平的，若当前锁的阻塞队列还没有被唤醒的协程，那就要求不要唤醒了，尝试让当前正在尝试的协程获取到锁，避免唤醒协程进行资源竞争。

for {
//...
new := old
if old&mutexStarving == 0 {
new |= mutexLocked
}
if old&(mutexLocked|mutexStarving) != 0 {
new += 1 << mutexWaiterShift
}
if starving && old&mutexLocked != 0 {
new |= mutexStarving
}
if awoke {
new &^= mutexWoken
}
//...
}

复制代码

（3）进行状态更新：
当协程从步骤2走出来时，只能说明它位于以下两个状态之一：

旋不动了，或者锁进入饥饿模式了，锁要让给别人了，总之是获取不到锁了（悲观）。
锁被释放了。

不论如何，都需要进行一些状态的更新，为接下来的打算做准备。
用new存储一个锁即将要进入的新状态信息，更新规则：

若锁不处于饥饿模式：说明锁可能被释放了，也可能是自旋次数过多，不管接下来是否能拿到锁，锁都会被某一个协程获取，因此置
1. mutexLocked
复制代码
为1。
若锁可能处于饥饿状态，或者锁没有被释放：那说明自己是抢不到锁了，即将进入阻塞态，阻塞协程计数器+1。
若当前的协程是被唤醒的，并且已经处在饥饿态中而且锁仍然锁着：锁进入绝对公平的饥饿模式。
若当前协程是被唤醒的：清除
1. mutexWoken
复制代码
标识位，因为接下来可能需要有协程被唤醒（饥饿模式）。

虽然更新的有点多，但是可以归纳为：

若锁释放了，那就标识一下接下来锁要被获取即可。
若锁没有释放，并给当前协程等待了很久，那锁就进入饥饿状态，接下来需要有阻塞协程被唤醒。

（4）尝试更新信息：

if atomic.CompareAndSwapInt32(&m.state, old, new) {
//...
} else {
old = m.state
}

复制代码

接下来尝试将new更新进state，若更新失败，说明当前有另一个协程介入了，为了防止数据的一致性丢失，要全部重来一次。
（5）状态更新成功，具体判断是要沉睡还是获取锁成功：
步入步骤4的if主支中，此时有两个状态：

if atomic.CompareAndSwapInt32(&m.state, old, new) {
if old&(mutexLocked|mutexStarving) == 0 {
break // locked the mutex with CAS
}
//...
} else {
//...
}

复制代码

因为当前状态，可能是锁释放了，检查锁更新前是否已经被释放了并且不是饥饿模式，若是那说明获取锁成功了，函数结束了。

if atomic.CompareAndSwapInt32(&m.state, old, new) {
if old&(mutexLocked|mutexStarving) == 0 {
break // locked the mutex with CAS
}
// If we were already waiting before, queue at the front of the queue.
queueLifo := waitStartTime != 0
if waitStartTime == 0 {
waitStartTime = runtime_nanotime()
}
runtime_SemacquireMutex(&m.sema, queueLifo, 2)
//....
} else {
//...
}

复制代码

否则，说明当前协程要进入阻塞态了，记录一下开始阻塞的时间，用于醒来是判断是否饥饿。然后进入阻塞沉睡中。
（6）若步骤5进入阻塞，则被唤醒后：

if atomic.CompareAndSwapInt32(&m.state, old, new) {
if old&(mutexLocked|mutexStarving) == 0 {
break // locked the mutex with CAS
}
// If we were already waiting before, queue at the front of the queue.
queueLifo := waitStartTime != 0
if waitStartTime == 0 {
waitStartTime = runtime_nanotime()
}
runtime_SemacquireMutex(&m.sema, queueLifo, 2)
//唤醒
starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
old = m.state
//若锁处于饥饿模式
if old&mutexStarving != 0 {
//锁的异常处理
if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
throw("sync: inconsistent mutex state")
}
//将要更新的信号量
delta := int32(mutexLocked - 1<<mutexWaiterShift)
if !starving || old>>mutexWaiterShift == 1 {
delta -= mutexStarving
}
atomic.AddInt32(&m.state, delta)
break
}
awoke = true
iter = 0
//....
} else {
//...
}

复制代码

从阻塞中唤醒，首先计算一些协程的阻塞时间，以及当前的最新锁状态。
若锁处于饥饿模式：那么当前协程将直接获取锁，当前协程是因为饥饿模式被唤醒的，不存在其他协程抢占锁。于是更新信号量，将记录阻塞协程数-1，将锁的上锁态置1。若当前从饥饿模式唤醒的协程，等待时间已经不到1ms了或者是最后一个等待的协程，那么将将锁从饥饿模式转化为正常模式。至此，获取成功，退出函数。
否则，只是普通的随机唤醒，于是开始尝试进行抢占，回到步骤1。

2.4、释放锁Unlock()

func (m *Mutex) Unlock() {
//直接释放锁
new := atomic.AddInt32(&m.state, -mutexLocked)
if new != 0 {
m.unlockSlow(new)
}
}

复制代码

通过原子操作，直接将锁的mutexLocked标识置为0。若置0后，锁的状态不为0，那就说明存在需要获取锁的协程，步入unlockSlow。

2.5、unlockSlow()

func (m *Mutex) unlockSlow(new int32) {
if (new+mutexLocked)&mutexLocked == 0 {
fatal("sync: unlock of unlocked mutex")
}
if new&mutexStarving == 0 {
old := new
for {
if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
return
}
new = (old - 1<<mutexWaiterShift) | mutexWoken
if atomic.CompareAndSwapInt32(&m.state, old, new) {
runtime_Semrelease(&m.sema, false, 2)
return
}
old = m.state
}
} else {
runtime_Semrelease(&m.sema, true, 2)
}
}

复制代码

（1）首先进行了异常状态处理，若释放了一个已经释放了到锁，那么直接fatal，程序终止。

if (new+mutexLocked)&mutexLocked == 0 {
fatal("sync: unlock of unlocked mutex")
}

复制代码

（2）若锁不处于饥饿状态：

若此时的等待协程数量为0，或者锁被上锁了、含有被唤醒的协程、锁处于饥饿模式：都说明有新的协程介入了流程，已经完成了交接，可以直接退出
唤醒一个处于阻塞态的协程。

否则，处于饥饿状态，唤醒等待最久的协程。

3、Sync.RWMutex

对于共享资源区的操作，可以划分为读与写两大类。假设在一个场景中，对共享资源区继续读的操作远大于写的操作，如果每个协程的读操作都需要获取互斥锁，这带来的性能损耗是非常大的。
RWMutex是一个可以运用在读操作>写操作中的提高性能的锁，可以将它视为由一个读锁与一个写锁构成。其运作规则具体如下：

读锁允许多个读协程同时读取共享资源区，若有协程需要修改资源区的数据，那么它需要被阻塞。
写锁具有严格的排他性，当共享资源区被上了写锁时，任何其他goroutine都不得访问。
可见在最坏的情况下，所有的协程都是需要写操作时，读写锁会退化成普通的Mutex。

3.1、数据结构

type RWMutex struct {
w Mutex // held if there are pending writers
writerSem uint32 // semaphore for writers to wait for completing readers
readerSem uint32 // semaphore for readers to wait for completing writers
readerCount atomic.Int32 // number of pending readers
readerWait atomic.Int32 // number of departing readers
}
const rwmutexMaxReaders = 1 << 30 //最大的读协程数量

复制代码

w：一个互斥的写锁
writerSem：关联被阻塞的写协程的信号量
readerSem：关联被阻塞的读协程的信号量
readerCount：正常情况下，记录正在读取的协程数量；但若当前是写协程正在持有锁，那么实际记录读协程的数量为readerCount - rwmutexMaxReader
readerWait：记录释放下一个写协程，还需要等待读协程完成的数量

3.2、读锁流程RLock()

func (rw *RWMutex) RLock() {
if rw.readerCount.Add(1) < 0 {
// A writer is pending, wait for it.
runtime_SemacquireRWMutexR(&rw.readerSem, false, 0)
}
}

复制代码

对readerCount+1，表示新加入一个读协程。若结果<0，说明当前锁正在被写协程占据，令当前的读协程阻塞。

3.3、读释放锁流程RUnlock()

func (rw *RWMutex) RUnlock() {
if r := rw.readerCount.Add(-1); r < 0 {
// Outlined slow-path to allow the fast-path to be inlined
rw.rUnlockSlow(r)
}
}

复制代码

对readerCount-1，表示减少一个读协程。若结果<0，说明当前锁正在被写协程占据，步入runlockslow。

3.4、rUnlockSlow()

func (rw *RWMutex) rUnlockSlow(r int32) {
if r+1 == 0 || r+1 == -rwmutexMaxReaders {
race.Enable()
fatal("sync: RUnlock of unlocked RWMutex")
}
if rw.readerWait.Add(-1) == 0 {
// The last reader unblocks the writer.
runtime_Semrelease(&rw.writerSem, false, 1)
}
}

复制代码

首先进行错误处理，若发现当前协程为占用过读锁，或者读流程的协程数量上限，系统出现异常，fatal。
否则，对readerWait-1，若结果为0，说明当前协程是最后一个介入读锁流程的协程，此时需要释放一个写锁。

3.5、写锁流程Lock()

func (rw *RWMutex) Lock() {
// First, resolve competition with other writers.
rw.w.Lock()
// Announce to readers there is a pending writer.
r := rw.readerCount.Add(-rwmutexMaxReaders) + rwmutexMaxReaders
// Wait for active readers.
if r != 0 && rw.readerWait.Add(r) != 0 {
runtime_SemacquireRWMutex(&rw.writerSem, false, 0)
}
}

复制代码

首先尝试获取写锁，若获取成功，需要将readerCount-最大读协程数，表示现在锁被读协程占据。
r表示处于读流程的协程数量，若r不为0，那么就将readerWait加上r，等这些读协程都读取完毕，再去写。将这个写协程阻塞。（读写锁并非读、写公平，读协程优先。）

3.6、写释放锁流程Unlock()

func (rw *RWMutex) Unlock() {
// Announce to readers there is no active writer.
r := rw.readerCount.Add(rwmutexMaxReaders)
if r >= rwmutexMaxReaders {
race.Enable()
fatal("sync: Unlock of unlocked RWMutex")
}
// Unblock blocked readers, if any.
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0)
}
// Allow other writers to proceed.
rw.w.Unlock()
}

复制代码

重新将readerCount置为正常指，表示释放了写锁。若读协程超过最大上限，则异常。
然后唤醒所有阻塞的读协程。（读协程优先）
解锁。
以上就是golang中单机锁的具体实现详解的详细内容，更多关于go单机锁的资料请关注脚本之家其

来源：互联网
免责声明：如果侵犯了您的权益，请联系站长（1277306191@qq.com），我们会及时删除侵权内容，谢谢合作！

golang中单机锁的具体实现详解

最新评论

新人须知

常见问题

维权申诉

关注微博

扫描微信

关于合作

通讯联系