Golang中sync.mutex源码问题解析

Golang中sync.mutex源码问题解析 源代码：Go 编程语言

  1. 在第 174 行，为什么先检查 !starving？既然我们已经满足了第 165 行的条件 old&mutexStarving != 0，那么 starving 应该总是为 true，不是吗？

  2. 有人能解释一下第 177-179 行之间的注释吗？一旦两个 goroutine 将互斥锁切换到饥饿模式，它们就可以无限地锁步前进 这句话是什么意思？

感谢任何帮助~

2 回复

pppwj:

starving

互斥锁有两种状态：正常状态和饥饿状态，这两种状态之间的转换是为了避免一个 goroutine 长时间持有互斥锁。

更多关于Golang中sync.mutex源码问题解析的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


  1. 关于第174行的 !starving 检查：

在饥饿模式下，starving 确实为 true，但这里的关键是检查是否应该退出饥饿模式。当一个新的 goroutine 获取锁时（第165行检测到饥饿模式），如果当前没有其他等待者（waiters == 1），或者等待时间很短（!starving），就会退出饥饿模式。

示例代码说明状态转换：

// 简化版的状态转换逻辑
if old&mutexStarving != 0 {
    // 当前处于饥饿模式
    if waiters == 1 || !starving {
        // 退出饥饿模式
        new &^= mutexStarving
    }
}
  1. 关于第177-179行的注释：

这个注释描述的是两个 goroutine 可能出现的"锁步"竞争情况。当互斥锁处于饥饿模式时，解锁的 goroutine 会直接将锁交给等待队列中的下一个 goroutine。如果两个 goroutine 交替获取和释放锁，它们可能会形成一种交替执行的模式，导致其他 goroutine 一直无法获取锁。

示例说明：

// goroutine A 和 B 可能形成的锁步模式
for {
    // A 获取锁
    mutex.Lock()
    // ... 操作
    mutex.Unlock() // 直接交给等待的 B
    
    // B 获取锁
    mutex.Lock()
    // ... 操作  
    mutex.Unlock() // 直接交给等待的 A
}
// 其他 goroutine C 可能一直无法获取锁

这种设计确保了在饥饿模式下，等待时间最长的 goroutine 能够优先获得锁，避免某些 goroutine 长时间饥饿。

回到顶部