深入解析 Golang Mutex：实现互斥锁的底层原理与机制

Cora

发布时间：2026-10-15 | 6人浏览过

原创

Mutex 是 Golang 中最基础的并发原语，Channel 等高级结构也依赖其实现。本文深入剖析 Mutex 的 state 状态管理、自旋机制以及正常/饥饿双模式切换逻辑，解读从源码层面理解互斥锁如何高效处理并发竞争。

Mutex 数据结构与运行模式

Mutex 核心由两个字段组成：state 用于记录锁的状态（如是否锁定、等待者数量），sema 作为信号量用于协程阻塞与唤醒。其状态位常量定义如下：

const (
	mutexLocked = 1 << iota // 1: 当前是否已经上锁
	mutexWoken              // 2: 当前是否有唤醒的 goroutine
	mutexStarving           // 4: 当前是否为饥饿状态
	mutexWaiterShift = iota // 3: state >> mutexWaiterShift 得到等待者数量

	starvationThresholdNs = 1e6 // 判断是否要进入饥饿状态的阈值 (1ms)
)

Mutex 拥有“正常模式”和“饥饿模式”两种行为机制，以平衡吞吐量与长尾延迟：

正常模式：等待者入队，但被唤醒的等待者需与新到达的 goroutine 竞争锁。新来的 goroutine 拥有优势，因为可能已在 CPU 上运行。若单个 goroutine 超过 1ms 未获取到锁，系统将切换到饥饿模式。
饥饿模式：锁的所有权直接移交给队列头的 goroutine。新来的 goroutine 不会尝试旋转或获取锁，而是直接排在等待队列末尾。这避免了后续协程因频繁竞争导致长时间等待。

当等待者是最后一个，或者等待时间不足 1ms 时，系统会切回正常模式。

获取锁（Lock）操作流程

第1步：快路径获取

首先尝试通过原子比较交换（CAS）将 state 从 0 设为 mutexLocked。若初始状态为 0，表示无其他锁竞争，直接获取成功。

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

第2步：慢路径——自旋尝试

如果快速路径失败，进入 lockSlow。在未处于饥饿状态且自旋条件满足时，goroutine 会先进行短暂自旋，利用 CPU 缓存局部性提高成功率。

// 只要原状态已锁且不处于饥饿状态，并满足自旋条件
if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
    // ... 标记唤醒状态 ... 
    runtime_doSpin()
    iter++
    old = m.state
    continue
}

自旋的有效条件严格限制以避免浪费 CPU：

自旋次数小于 4 次。
系统为多核 CPU。
GOMAXPROCS > 1。
至少存在一个 P 的本地队列为空。

func sync_runtime_canSpin(i int) bool {
	if i >= active_spin || ncpu <= 1 || gomaxprocs <= int32(sched.npidle+sched.nmspinning)+1 {
		return false
	}
	if p := getg().m.p.ptr(); !runqempty(p) {
		return false
	}
	return true
}

自旋的具体实现在汇编层面调用 YIELD 指令（x86 上对应 PAUSE），让 CPU 进入低功耗等待，而非空转，循环次数由 active_spin_cnt = 30 控制。

TEXT runtime·procyield(SB),NOSPLIT,$0-0
    MOVWU    cycles+0(FP), R0
again:
    YIELD
    SUBW    $1, R0
    CBNZ    R0, again
    RET

第3步：计算期望状态（new state）

更新 state 的逻辑遵循以下规则：

设置已锁位：若原状态不处于饥饿模式，则新状态设置 mutexLocked。
增加等待计数：若原状态已锁或处于饥饿模式，等待者数量加 1。
进入饥饿模式：若已等待时间超过阈值 (starvationThresholdNs) 且原状态已锁，新状态设置 mutexStarving。
清除唤醒位：若当前 goroutine 已被唤醒（awoke），清除 mutexWoken 标志。

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 {
    if new&mutexWoken == 0 {
        throw("sync: inconsistent mutex state")
    }
    new &^= mutexWoken
}

第4步：CAS 尝试与排队

使用 CAS 尝试将状态从 old 更新为 new：

CAS 成功：
- 若原状态既未锁也未饥饿，直接返回，获取成功。
- 若原状态已锁，说明需要排队。调用 runtime_SemacquireMutex 阻塞等待信号量。被唤醒后，若处于饥饿模式，移交锁所有权并调整状态（减少等待数、可能退出饥饿模式）。
CAS 失败：说明中间有其他 goroutine 介入，更新 old 继续下一轮竞争。

if atomic.CompareAndSwapInt32(&m.state, old, new) {
    if old&(mutexLocked|mutexStarving) == 0 {
        break // locked the mutex with CAS
    }
    // ... 排队逻辑 ...
    runtime_SemacquireMutex(&m.sema, queueLifo, 1)
    // ... 饥饿模式处理 ...
}

释放锁（Unlock）操作流程

第1步：快路径释放

尝试原子减 1 移除 mutexLocked 位。若无等待者且非饥饿状态，直接成功返回。

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

第2步：慢路径唤醒

若快路径无效，进入 unlockSlow：

安全检查：确保原状态确实包含 mutexLocked，否则 panic。
正常模式唤醒：若不处于饥饿状态，计算新状态为“等待数减 1”且“标记正在唤醒”。CAS 成功后，调用 runtime_Semrelease 释放信号量唤醒一个等待者。若 CAS 失败，重试直至成功。
饥饿模式移交：若处于饥饿状态，直接调用 runtime_Semrelease 并放弃时间片，将锁所有权直接移交给队列头部的 goroutine，无需额外竞争。

func (m *Mutex) unlockSlow(new int32) {
    if (new+mutexLocked)&mutexLocked == 0 {
        throw("sync: unlock of unlocked mutex")
    }
    if new&mutexStarving == 0 {
        // ... 正常模式自旋唤醒逻辑 ...
    } else {
        // 饥饿模式下移交锁所有权
        runtime_Semrelease(&m.sema, true, 1)
    }
}