为什么需要锁？（锁就像一把钥匙，只有一个协程得到并打开共享资源的门）
解决并发访问共享资源时，出现的数据竞争和并发异常问题
如何设计和实现
首先定义结构体，需要
- 字段state int32类型来表示锁状态（0代表锁未持有，1代表锁已经被某个协程持有），使用atomic的cas来更新state字段，标记是否获取锁
- 需要等待队列queue存放阻塞goroutine（先入先出）,依次被唤醒，唤醒后g需要争抢获取锁；
- 唤醒和挂起都需要cpu开销，可以插入队列前先自旋抢锁，得到更高的吞吐量，但不能一直自旋，也需要记录自旋次数字段spin
- 信号量字段来唤醒等待的goroutine获取锁
- 进一步优化，释放锁后新创建g1和唤醒队首的g2争抢锁，往往新创建g1会获取锁，因为新创建在cpu运行+数量比较多 可能导致队列中g一直获取不到锁，造成尾部延时；增加互斥锁状态模式字段，表示正常/饥饿状态，如果一个等待goroutine超过1ms还没有获取锁切换到饥饿状态，互斥锁解锁后优先让队首g获取，新创建g直接插入队尾。如果g是队列最后一个元素or等待时间小于1ms会从饥饿状态切换正常状态。
type RWMutex struct {
w Mutex // 一个互斥锁的字段，用户进行写时加互斥锁
writerSem uint32 // 一个writer的信号量，类似互斥锁中的信号量
readerSem uint32 // 一个reader的信号量，类似互斥锁中的信号量
readerCount int32 // 两种作用，1:标记有多少拿到读锁的reader，2:是否有writer需要竞争
readerWait int32 // writer需要等待读锁解锁的reader的数量
}
const rwmutexMaxReaders = 1 << 30 // 最大reader的上限。即最多有多少的reader同时能拿到读锁- 读锁加锁：针对readerCount字段的判断，如果其+1仍未负数时就代表此时此刻写锁已经被获取，即需要进行阻塞等待写锁的解锁
- 读锁的解锁：判断是否有正在等待的写锁，如果没有就直接返回，否则就进行readerWait字段的校验判断是否是最后一个需要等待的读锁后唤醒，等待读锁释放完的writer进行写锁的获取。
- 写锁的加锁过程必须先对整体的结构体的Mutex进行加锁，以免有其他的写操作同时对写锁的竞争导致data race。然后进行当前持有读锁的reader的数量进行取反，并且将其值交给readerWait
- 用于标记需要等待释放锁的reader的数量，如果该字段不等于0则代表需要进行读锁解锁等待。当reader调用RUlock时会进行对此字段的-1并且判断，如果此字段为0时，则唤醒writer的阻塞，使得writer获取到写锁。
- 写锁的解锁方式很简单，先进行readerCount的取反，以便告知无writer正在竞争，然后依次去唤醒这些等待的reader去获取读锁，然后将互斥锁写锁，以便后续的writer进行写操作，在写操作时，加锁时先进行互斥锁的加锁，解锁时后进行互斥锁的解锁，为的是保证字段的修改也受到互斥锁的保护。
- go的读写锁采用的是Write-preferring（即写优先）的设计，这样可以保证写操作在大量的读操作进行时不会被饿死。但是相对于Read-preferring（即读优先）的设计会降低读的并发性，但是这种方式避免了写会出现饥饿问题。也是一种良好的解决办法