Go面试题：锁的实现原理sync-mutex篇

本文介绍: 在Go中，主要实现了两种锁：sync.Mut e x(互斥锁) 以及 sync.RWMute x(读写锁)。本篇主要给大家介绍 sync.Mute x的使用和实现原理。

在Go中，主要实现了两种锁：sync.Mute x(互斥锁) 以及 sync.RWMutex(读写锁)。

为什么 需要锁

在高并发下或多goroutine同时执行下，可能会同时读写同一块内存，比如如下场景：

var count int
var mu sync.Mutex

func func1() {
	for i := 0; i < 1000; i++ {
		go func() {
			count = count + 1
		}()
	}
	time.Sleep(time.Second)
	fmt.Println(count)
}

输出的值预期是1000，实际是 948，965等，多次运行结果不一致。
之所以出现这样的现象，是因为对于count=count+1来讲，每个 goroutine 执行步骤为：

读取当前 count值
count+1
修改 count值

当多个 goroutine同时执行修改数值时，后面执行的goroutine会把前面 goroutine对count的修改覆盖。

在Go中对于并发 程序进行公共 资源的访问的限制最常用的就是互斥锁（syn c.mutex）的方式

syn c.mute x的常用方法有两个：

Mutex.lock()用来获取锁
Mutex.Unlock()用于释放锁
在 Loc k 和 Unlock 方法之间的代码段称为资源的临界区，这一区间的代码是严格被锁保护的，是线程安全的，任何一个时间点最多只能有一个 goroutine在执行。

基于此，上面的示例可以采用 syn c.mutex来改进：

var count int
var mutex sync.Mutex

func func2() {
	for i := 0; i < 1000; i++ {
		go func() {
			mutex.Lock()
			count = count + 1
			mutex.Unlock()
		}()
	}
	time.Sleep(time.Second)
	fmt.Println(count)
}

输出结果为1000。

当某一goroutine执行了mutex.loc k()方法后，如果有其他的gorout ine来执行上锁操作，会被阻塞，直到当前的gorout ine执行mutex.unloc k()方法释放锁后其他的gorout ine才会继续抢锁执行。

实现原理

sync.Mutex的数据结构
Go中的sync.Mutex的结构体为：

type Mutex struct {
	state int32
	sema  uint32
}

Sy nc.Mutex由两个字段构成，state用来表示当前互斥锁处于的状态，s ema 用于控制锁状态的信号量。相信各位道友读完这两个字段的描述后，好像懂了，又好像没懂。下面我们详细理解下这两个字段到底都作了哪些事。
互斥锁state主要记录了如下四种状态：

waiter_num：记录了当前等待抢这个锁的gorout ine数量
star ving：当前锁是否处于饥饿状态 (后文会详解锁的饥饿状态) 0: 正常状态 1: 饥饿状态
woken：当前锁是否有goroutine已被唤醒。 0：没有goroutine被唤醒； 1: 有goroutine正在加锁过程
loc ked：当前锁是否被goroutine持有。 0: 未被持有 1: 已被持有
s ema 信号量的作用：
当持有锁的gorouine释放锁后，会释放s ema 信号量，这个信号量会唤醒之前抢锁阻塞的gorouine来获取锁。

锁的两种模式

互斥锁在设计上主要有两种模式：正常模式和饥饿模式。

之所以引入了饥饿模式，是为了保证goroutine获取互斥锁的公平性。所谓公平性，其实就是多个goroutine在获取锁时，goroutine获取锁的顺序，和请求锁的顺序一致，则为公平。
正常模式下，所有阻塞在等待队列中的goroutine会按顺序进行锁获取，当唤醒一个等待队列中的goroutine时，此goroutine并不会直接获取到锁，而是会和新请求锁的goroutine竞争。通常新请求锁的goroutine更容易获取锁，这是因为新请求锁的goroutine正在占用 cpu片执行，大概率可以直接执行到获取到锁的逻辑。