【go源码阅读笔记】 - Sync.Mutex

问题的起源

众所周知，对于一个共享变量来说，多个线程同时操作会产生神奇的效果，举一个形象点的例子：如果当前我在直播，现在在屏幕上有一个数字，观看直播的人有两个，他们都可以操作这个数字让它加1，一共加50次，也就是最终屏幕上的数字应该是50，但是现实却是会比理想的要小一点，speak is cheap，show you my code：

package main

import (
   "fmt"
   "sync"
)

var Num = 0 // 屏幕上的数字

func PersonOne() {
   Num += 1
}

func PersonTwo() {
   Num += 1
}

func main() {
   var wg sync.WaitGroup // 为了保证主线程退出不杀死自线程，加一个同步机制
   for i := 0; i < 25; i++ {
      go func() {
         wg.Add(1)
         defer wg.Done()
         PersonOne()
      }()
   }
   for i := 0; i < 25; i++ {
      go func() {
         wg.Add(1)
         defer wg.Done()
         PersonTwo()
      }()
   }
   wg.Wait()
   fmt.Println(Num)
}

上面代码的执行结果并不是50，这是因为+=并不是一个原子操作，也就是在编译成的机器命令中对应了多个指令，那很有可能一个线程在加完之后，并没有保存，此时另一个线程又对这个值进行了修改，导致最终结果于预期的差异。

go中的锁

那么如果解决上面的问题呢，在go中可以使用automic进行原子操作，这样就可以lock free，更普遍一点的做法自然是使用锁，但是这样性能方面会有一定的折损，讲了这么多，终于搬出了今天的主角: Sync.Mutex，接下来就让东东带你一起去感知go中Mutex的奇妙世界吧！！

首先先来看一下结构体的定义:

// A Mutex must not be copied after first use.
// go中的锁不要被拷贝
type Mutex struct {
   state int32        // 当前锁的状态
   sema  uint32       // 信号量，用于从等待队列中唤醒协程
}

锁的状态主要有四个区域，对应源码中的定义为:

const (
   mutexLocked = 1 << iota // mutex is locked  // 当前是否加锁
   mutexWoken                                  // 当前是否有已唤醒的协程
   mutexStarving                               // 当前是否处于饥饿状态
   mutexWaiterShift = iota                     // 等待队列中的协程数量
)

知道了这些状态之后，我们来看一下加锁和解锁的过程，里面大量的使用了CAS(Compare And Swap)操作，不懂的小伙伴可以先移步搜索CAS，之后再来阅读

加锁过程

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.

// 如果说当前锁正在被使用，则唤醒的协程序需要阻塞直到可以得到锁
func (m *Mutex) Lock() {
   // Fast path: grab unlocked mutex.
   // 加锁的fast way: 如果当前锁完全处于放空状态，则直接加锁，并返回
   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)
   // 加锁的slow way
   m.lockSlow()
   
}

func (m *Mutex) lockSlow() {
   var waitStartTime int64     // 等待时间，用于判断当前是否需要进入饥饿状态
   starving := false           // 判断当前是否处于饥饿状态
   awoke := false              // 判断当前是否有被唤醒的协程  
   iter := 0                   // 计数器，判断是否可以自旋的时候使用
   old := m.state              // 存储当前锁的老状态
   for {
      // Don't spin in starvation mode, ownership is handed off to waiters
      // so we won't be able to acquire the mutex anyway.
      // 如果当前已经加锁并且不是饥饿模式，并且可以自旋，则进行自旋，自旋的原因是首先当前处于
      // 加锁状态，所以需要等待重试，另外如果是饥饿模式的话，当前协程需要到等待队列，无需自旋
      if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
         // Active spinning makes sense.
         // Try to set mutexWoken flag to inform Unlock
         // to not wake other blocked goroutines.
         // 如果说当前是否有被唤醒的协程状态为0，则我们尝试将该状态置为1，这样当锁释放的时候，
         // 下次激活的就是当前阻塞的协程，而不是其它协程
         if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
            atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
            awoke = true
         }
         runtime_doSpin()
         iter++          // 自旋状态加1，超过4就停止自旋
         old = m.state
         continue
      }
      // 无论是以上什么情况，都需要更新状态，所以计算出期望的新状态
      new := old
      // Don't try to acquire starving mutex, new arriving goroutines must queue.
      // 如果说当前不是饥饿状态，也就是不需要在等待队列中等待被唤醒，则直接将加锁的状态置为1，即使
      // 说上面没有获得锁，也就是依旧block，这里更新状态也没有错
      if old&mutexStarving == 0 {
         new |= mutexLocked
      }
      // 如果说处于饥饿状态或者依旧被block，则将当前协程放入等待队列中
      if old&(mutexLocked|mutexStarving) != 0 {
         new += 1 << mutexWaiterShift
      }
      // The current goroutine switches mutex to starvation mode.
      // But if the mutex is currently unlocked, don't do the switch.
      // Unlock expects that starving mutex has waiters, which will not
      // be true in this case.
      // 如果当前已经是加锁状态并且当前处于饥饿模式，则更新状态，开启饥饿模式
      if starving && old&mutexLocked != 0 {
         new |= mutexStarving
      }
      // 如果当前协程被唤醒，因为已经被唤醒过了，所以重置该状态
      if awoke {
         // The goroutine has been woken from sleep,
         // so we need to reset the flag in either case.
         if new&mutexWoken == 0 {
            throw("sync: inconsistent mutex state")
         }
         new &^= mutexWoken
      }
      // 尝试更新旧状态到新的状态
      if atomic.CompareAndSwapInt32(&m.state, old, new) {
         // 如果说旧状态已经解锁并且不是饥饿模式，则说明当前协程加锁成功，直接返回
         if old&(mutexLocked|mutexStarving) == 0 {
            break // locked the mutex with CAS
         }
         // 这块就是计算当前是否需要进入饥饿模式，如果当前协程等待时间超过了1ms，则将改协程
         // 从等待队列中移到队头，并更新模式为饥饿模式
         // 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, 1)
         starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
         old = m.state
         // 这块儿是为了维护状态的连续性，也就是如果当前协程更新的状态是处于饥饿模式的，则
         // 之前的逻辑会先将它放入等待队列中，所以这块需要让当前协程加上锁并且从等待队列中
         // 移出去
         if old&mutexStarving != 0 {
            // If this goroutine was woken and mutex is in starvation mode,
            // ownership was handed off to us but mutex is in somewhat
            // inconsistent state: mutexLocked is not set and we are still
            // accounted as waiter. Fix that.
            if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
               throw("sync: inconsistent mutex state")
            }
            delta := int32(mutexLocked - 1<<mutexWaiterShift)
            if !starving || old>>mutexWaiterShift == 1 {
               // Exit starvation mode.
               // Critical to do it here and consider wait time.
               // Starvation mode is so inefficient, that two goroutines
               // can go lock-step infinitely once they switch mutex
               // to starvation mode.
               delta -= mutexStarving
            }
            atomic.AddInt32(&m.state, delta)
            break
         }
         // 如果是正常模式，则说明当前协程并没有加锁成功，继续自旋
         awoke = true
         iter = 0
      } else {
         old = m.state
      }
   }

   if race.Enabled {
      race.Acquire(unsafe.Pointer(m))
   }
}

解锁过程

// Unlock unlocks m.
// It is a run-time error if m is not locked on entry to Unlock.
//
// A locked Mutex is not associated with a particular goroutine.
// It is allowed for one goroutine to lock a Mutex and then
// arrange for another goroutine to unlock it.
func (m *Mutex) Unlock() {
   if race.Enabled {
      _ = m.state
      race.Release(unsafe.Pointer(m))
   }

   // Fast path: drop lock bit.
   // fast way: 直接将锁位的标志减去
   new := atomic.AddInt32(&m.state, -mutexLocked)
   if new != 0 {
      // Outlined slow path to allow inlining the fast path.
      // To hide unlockSlow during tracing we skip one extra frame when tracing GoUnblock.
      // slow way
      m.unlockSlow(new)
   }
}

func (m *Mutex) unlockSlow(new int32) {
   // 如果当前在重复解锁，则抛出异常
   if (new+mutexLocked)&mutexLocked == 0 {
      throw("sync: unlock of unlocked mutex")
   }
   // 如果当前处于正常模式
   if new&mutexStarving == 0 {
      old := new
      for {
         // If there are no waiters or a goroutine has already
         // been woken or grabbed the lock, no need to wake anyone.
         // In starvation mode ownership is directly handed off from unlocking
         // goroutine to the next waiter. We are not part of this chain,
         // since we did not observe mutexStarving when we unlocked the mutex above.
         // So get off the way.
         // 如果当前等待队列中没有协程，或者已经加锁或者已经有被唤醒的协程，则直接返回
         if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
            return
         }
         // Grab the right to wake someone.
         // 从等待队列中获取一个协程并设置相应的激活位，这块相当于多个协程在竞争该状态的更新，更新成功
         // 的才可以得到这把锁
         new = (old - 1<<mutexWaiterShift) | mutexWoken
         if atomic.CompareAndSwapInt32(&m.state, old, new) {
            runtime_Semrelease(&m.sema, false, 1)
            return
         }
         old = m.state
      }
   } else {
      // Starving mode: handoff mutex ownership to the next waiter, and yield
      // our time slice so that the next waiter can start to run immediately.
      // Note: mutexLocked is not set, the waiter will set it after wakeup.
      // But mutex is still considered locked if mutexStarving is set,
      // so new coming goroutines won't acquire it.
      // 如果当前是饥饿模式，则直接唤醒等待队列中的队首协程
      runtime_Semrelease(&m.sema, true, 1)
   }
}