什么是锁
- 锁的本质，就是一种资源，是由操作系统维护的一种专门用于同步的资源
- 比如说互斥锁，说白了就是一种互斥的资源。只能有一个进程（线程）占有。当一个进程（线程）通过竞争获得锁的时候，其他进程（或线程）将得不到这把锁。这是内核代码决定的
- 如果我们希望某种资源在多个进程(线程/协程)之间共享，但是某一时刻最多有一个进程占有，这不就是互斥锁的概念吗，也就是说，我们希望自己的资源也变成一种锁
- 最简单的办法就是将自己的资源和操作系统定义好的锁绑定到一起。也就是说，进程要获取我的资源之前，必须要获得操作系统的锁。进一步说，得锁得资源，失锁失资源。这样的话，我们的资源也变成了一把锁
为什么使用锁
并发编程中保证数据一致性和安全性的
Golang中的锁
Golang的提供的同步机制有sync模块下的Mutex、WaitGroup以及语言自身提供的chan等。 这些同步的方法都是以runtime中实现的底层同步机制（cas、atomic、spinlock、sem）为基础的
1. cas、atomic
cas(Compare And Swap)和原子运算是其他同步机制的基础
- 原子操作：指那些不能够被打断的操作被称为原子操作，当有一个CPU在访问这块内容addr时，其他CPU就不能访问
- CAS：比较及交换，其实也属于原子操作，但它是非阻塞的，所以在被操作值被频繁变更的情况下,CAS操作并不那么容易成功，不得不利用for循环以进行多次尝试
2. 自旋锁(spinlock)
自旋锁是指当一个线程在获取锁的时候，如果锁已经被其他线程获取，那么该线程将循环等待，然后不断地判断是否能够被成功获取，知直到获取到锁才会退出循环。获取锁的线程一直处于活跃状态
Golang中的自旋锁用来实现其他类型的锁,与互斥锁类似，不同点在于，它不是通过休眠来使进程阻塞，而是在获得锁之前一直处于活跃状态(自旋)
3. 信号量
实现休眠和唤醒协程的一种方式
信号量有两个操作P和V
P(S):分配一个资源
1. 资源数减1：S=S-1
2. 进行以下判断
如果S<0，进入阻塞队列等待被释放
如果S>=0,直接返回V(S):释放一个资源
1. 资源数加1：S=S+1
2. 进行如下判断
如果S>0，直接返回
如果S<=0,表示还有进程在请求资源，释放阻塞队列中的第一个等待进程
golang中信号量操作：runtime/sema.go
P操作：runtime_Semacquire
V操作：runtime_Semrelease
mutex的使用
mutex的必要性
锁在高度竞争时会不断挂起恢复线程从而让出cpu资源，原子变量在高度竞争时会一直占用cpu;原子操作时线程级别的，不支持协程
mutex演进
1. 互斥锁
state表示当前锁的状态，是一个共用变量
state: |32|31|....|3|2|1|
\__________/ | |
| | |
| | 当前mutex是否加锁
| |
| 当前mutex是否被唤醒
|
等待队列的goroutine协程数
Lock 方法申请对 mutex 加锁的时候分两种情况
- 无冲突 通过 CAS 操作把当前状态设置为加锁状态
- 有冲突 通过调用 semacquire 函数来让当前 goroutine 进入休眠状态，等待其他协程释放锁的时候唤醒
UnLock 解锁分两步
- 解锁，通过CAS操作把当前状态设置为解锁状态
- 唤醒休眠协程，CAS操作把当前状态的waiter数减1,然后唤醒休眠goroutine
知识点
使用&来判断位值，使用|来设置位值，使用&^来清空位置(内存对齐)
一代互斥锁的问题
处于休眠中的goroutine优先级低于当前活跃的，unlock解锁的瞬间最新的goroutine会抢到锁
大多数果锁的时间很短，所有的goroutine都要休眠，增加runtime调度开销
2. 自旋锁
Lock 方法申请对 mutex 加锁的时候分三种情况
- 无冲突 通过 CAS 操作把当前状态设置为加锁状态
- 有冲突 开始自旋，并等待锁释放，如果其他 goroutine 在这段时间内释放了该锁，直接获得该锁；如果没有释放，进入3
- 有冲突 通过调用 semacquire 函数来让当前 goroutine 进入等待状态，等待其他协程释放锁的时候唤醒
path: runtime/proc.go
问题：
- 还是没有解决休眠进程优先级低的问题
3. 公平锁
基本逻辑
- Mutex 两种工作模式，normal 正常模式，starvation 饥饿模式。normal 情况下锁的逻辑与老版相似，休眠的 goroutine 以 FIFO 链表形式保存在 sudog 中，被唤醒的 goroutine 与新到来活跃的 goroutine 竞解，但是很可能会失败。如果一个 goroutine 等待超过 1ms，那么 Mutex 进入饥饿模式
- 饥饿模式下，解锁后，锁直接交给 waiter FIFO 链表的第一个，新来的活跃 goroutine 不参与竞争，并放到 FIFO 队尾
- 如果当前获得锁的 goroutine 是 FIFO 队尾，或是等待时长小于 1ms，那么退出饥饿模式
- normal 模式下性能是比较好的，但是 starvation 模式能减小长尾 latency
LOCK流程：
- 无冲突 通过 CAS 操作把当前状态设置为加锁状态
- 有冲突 开始自旋 如果是饥饿模式禁止自旋，开始自旋，并等待锁释放，如果其他 goroutine 在这段时间内释放了该锁，直接获得该锁；如果没有释放，进入3
- 有冲突,且已经过了自旋阶段 通过调用 semacquire 函数来让当前 goroutine 进入等待状态，等待其他协程释放锁的时候唤醒，休眠前：如果是饥饿模式，把当前协程放到队列最前面；唤醒后：如果是饥饿模式唤醒的，直接获得锁
UnLock 解锁分两步
- 解锁，通过CAS操作把当前状态设置为解锁状态
- 唤醒休眠协程，CAS操作把当前状态的waiter数减1,然后唤醒休眠goroutine，如果是饥饿模式的话，唤醒等待队列的第一个