1. sync.Mutex详解
sync.Mutex.lock().unlock()sync.Mutexsync.Mutexstate- mutexLocked — 表示互斥锁的锁定状态；
- mutexWoken — 表示从正常模式被从唤醒；
- mutexStarving — 当前的互斥锁进入饥饿状态；
- waitersCount — 当前互斥锁上等待的 goroutine 个数；
2. RWMutex详解
- 读操作如何防止并发读写问题的？
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时唤醒写操作。
3. sync.Map详解
一般情况下解决并发读写 map 的思路是加一把大锁，或者把一个 map 分成若干个小 map，对 key 进行哈希，只操作相应的小 map。前者锁的粒度比较大，影响效率；后者实现起来比较复杂，容易出错。
sync.map
在进行读操作的时候，会先在read中找，没有命中的话会锁住dirty并且寻找，如果找到了miss计数+1，超过阈值时将dirty赋值给read；
在进行添加操作时，直接在dirty中添加；
在进行修改操作时，先改read，再改dirty；
在进行删除操作时，将read中加上amended标记，dirty中直接删除。
4. 原子操作 atomic.Value
愿此操作的底层是靠 MESI 缓存一致性协议来维持的。
Go的 atomic.Value 需要注意应该放入只读对象。
5. 使用小技巧
- 减小临界区域（减少锁的持有时间）
如上所示，如果do sth3中是很费时的io操作，使用这个技巧可以将临界区减小，提高性能，不过，如果本身临界区就不大，锁操作后续没有什么费时操作，那么也就没有必要这样操作了。
- 减小锁的粒度
在高并发场景下，用锁的数量来换取并发效率，类似于java中ConcurrentHashmap的分段锁思想，增加锁的数量，减少一把锁控制的数据量。
- 读写分离(读写锁): RWMutex，sync.Map
在读多写少的情景下，可以使用读写锁，提高读操作的并发性能。
- 使用原子操作
原子操作是CPU指令级的操作，不会触发g调度机制。，不阻塞执行流