为什么需要锁
在高并发下或多goroutine同时执行下，可能会同时读写同一块内存，比如如下场景：
输出的值预期是1000，实际是 948，965等，多次运行结果不一致。
之所以出现这样的现象，是因为对于count=count+1来讲，每个goroutine执行步骤为：
- 读取当前count值
- count+1
- 修改count值
当多个goroutine同时执行修改数值时，后面执行的goroutine会把前面goroutine对count的修改覆盖。
在Go中对于并发程序进行公共资源的访问的限制最常用的就是互斥锁（sync.mutex）的方式
sync.mutex的常用方法有两个：
- Mutex.lock()用来获取锁
- Mutex.Unlock()用于释放锁
在 Lock 和 Unlock 方法之间的代码段称为资源的临界区，这一区间的代码是严格被锁保护的，是线程安全的，任何一个时间点最多只能有一个goroutine在执行。
基于此，上面的示例可以采用sync.mutex来改进：
输出结果为1000。
当某一goroutine执行了mutex.lock()方法后，如果有其他的goroutine来执行上锁操作，会被阻塞，直到当前的goroutine执行mutex.unlock()方法释放锁后其他的goroutine才会继续抢锁执行。
实现原理
sync.Mutex的数据结构
Go中的sync.Mutex的结构体为：
Sync.Mutex由两个字段构成，state用来表示当前互斥锁处于的状态，sema用于控制锁状态的信号量。相信各位道友读完这两个字段的描述后，好像懂了，又好像没懂。下面我们详细理解下这两个字段到底都作了哪些事。
互斥锁state主要记录了如下四种状态：
waiter_num： 记录了当前等待抢这个锁的goroutine数量
starving： 当前锁是否处于饥饿状态 (后文会详解锁的饥饿状态) 0: 正常状态 1: 饥饿状态
woken： 当前锁是否有goroutine已被唤醒。 0：没有goroutine被唤醒； 1: 有goroutine正在加锁过程
locked： 当前锁是否被goroutine持有。 0: 未被持有 1: 已被持有
sema信号量的作用：
当持有锁的gorouine释放锁后，会释放sema信号量，这个信号量会唤醒之前抢锁阻塞的gorouine来获取锁。
锁的两种模式
互斥锁在设计上主要有两种模式： 正常模式和饥饿模式。
之所以引入了饥饿模式，是为了保证goroutine获取互斥锁的公平性。所谓公平性，其实就是多个goroutine在获取锁时，goroutine获取锁的顺序，和请求锁的顺序一致，则为公平。
正常模式下，所有阻塞在等待队列中的goroutine会按顺序进行锁获取，当唤醒一个等待队列中的goroutine时，此goroutine并不会直接获取到锁，而是会和新请求锁的goroutine竞争。 通常新请求锁的goroutine更容易获取锁，这是因为新请求锁的goroutine正在占用cpu片执行，大概率可以直接执行到获取到锁的逻辑。
饥饿模式下， 新请求锁的goroutine不会进行锁获取，而是加入到队列尾部阻塞等待获取锁。
饥饿模式的触发条件：
- 当一个goroutine等待锁的时间超过1ms时，互斥锁会切换到饥饿模式
饥饿模式的取消条件：
- 当获取到锁的这个goroutine是等待锁队列中的最后一个goroutine，互斥锁会切换到正常模式
- 当获取到锁的这个goroutine的等待时间在1ms之内，互斥锁会切换到正常模式
注意事项
- 在一个goroutine中执行Lock()加锁成功后，不要再重复进行加锁，否则会panic。
- 在Lock() 之前 执行Unlock()释放锁 会panic
- 对于同一把锁，可以在一个goroutine中执行Lock加锁成功后，可以在另外一个gorouine中执行Unlock释放锁。
读写锁的使用
读写互斥锁sync.RWMutex不限制对资源的并发读，但是读写，写写操作无法并行执行。
读写锁一共有四个函数：
- RLock(): 申请读锁
- RUnlock(): 解除读锁
- Lock(): 申请写锁
- Unlock(): 解除写锁
实现原理
sync.RWMutex的数据结构
Go中sync.RWMutext的结构体为
接下来，我们结合底层数据结构来分析读写锁是如何实现对资源并发读写的控制的。
- 读操作如何防止并发读写问题的？
- RLock(): 申请读锁，每次执行此函数后，会对readerCount++，此时当有写操作执行Lock()时会判断readerCount>0,就会阻塞。
- RUnLock(): 解除读锁，执行readerCount--，释放信号量唤醒等待写操作的goroutine。
- 写操作如何防止并发读写、并发写写问题？
- Lock(): 申请写锁，获取互斥锁，此时会阻塞其他的写操作。并将readerCount 置为 -1，当有读操作进来，发现readerCount = -1， 即知道有写操作在进行，阻塞。
- Unlock(): 解除写锁，会先通知所有阻塞的读操作goroutine，然后才会释放持有的互斥锁。
- 为什么写操作不会被饿死？
这时候张三道友先跳出来问了一句，什么是写操作被饿死？
这是由于写操作要等待读操作结束后才可以获得锁，而写操作在等待期间可能还有新的读操作持续到来，如果写操作等待所有读操作结束，很可能会一直阻塞，这种现象称之为写操作被饿死。
通过RWMutex结构体中的readerWait属性可完美解决这个问题。
当写操作到来时，会把RWMutex.readerCount值拷贝到RWMutex.readerWait中，用于标记排在写操作前面的读者个数。
前面的读操作结束后，除了会递减RWMutex.readerCount，还会递减RWMutex.readerWait值，当RWMutex.readerWait值变为0时唤醒写操作。