Go并发编程-sync.Mutex总结

• 适合于读多写少的场景

• 写多读少不如直接加写锁

• Mutex和RWMutex都是不可重入的
  可重入锁：同一goroutine同一锁可以反反复复Lock；
  Java锁是可重入的，大部分分布式锁也是可重入的。

• 尽可能用 defer 来解锁，避免 panic

  panic 是直接中断，所以如果你此时拿着锁，那么你是没有办法释放掉的。但是 defer 可以确保即便你panic 了，这个动作也会执行。
  

要点

• Mutex 的公平性：Go 的锁是不公平锁。为什么它不设计为公平锁？
• Mutex 的两种模式，以及两种模式的切换时机：
  正常模式
  饥饿模式
• 为什么 Mutex 要设计出来这两种模式？
  这个问题基本等价于为什么它不设计为公平锁。如果队列里面有goroutine在等待锁，那么新来的goroutine有可能拿到锁吗?当然，而且大概率。（*正占用CPU）
• Mutex 是不是可重入的锁？显然不是。
• RWMutex和Mutex有什么区别?如何选择这两个?
  几乎完全是写操作的选Mutex,其它时候优先选择RWMutex。
• Mutex 是怎么做到挂起 goroutine 的，以及是如何唤醒 goroutine 的？
  在这个语境下，只需要回答sema 这个字段以及 runtime_SemacquireMutex 和 runtime_Semrelease 两个调用就可以。