一、互斥锁
思想
对资源A，同一时刻只能由一个goroutine占有
实现
1. 模式
监控（monitor）模式：一个或多个变量被封装起来，只暴露（exported）一些函数/方法作为访问这些变量的唯一方式。每个函数在一开始就获取互斥锁并在最后释放锁，从而保证共享变量不会被并发访问。
与之前的文章[1]中提到的"monitor goroutine"用法类似，都是使用一个代理人（broker）来保证变量被顺序访问，互斥锁使用的是一个二元信号量。
二元信号量（binary semaphore）：一个只能为1或0的信号量
2. 使用channel
使用buffer大小为1的channel来保证最多只有一个goroutine在同一时刻访问一个共享变量
// create a binary semaphore (global variable)
var sema = make(chan struct{}, 1)
var resource int
// in each goroutine
// acquire token
sema <- struct{}{} //struct{}是类型，第二个{}是初始化内容
// use resource
resource = 1
// release token
<- sema
2. 使用sync.Mutex
Go的sync包里提供了sync.Mutex类型互斥锁。使用Lock()方法尝试获取锁，若已被其他goroutine获取则会阻塞直到其他goroutine释放；使用Unlock()方法释放锁
// create lock
var mu sync.Mutex
var resource int // mutex保护的变量一般在mutex声明后立即声明
// in each goroutine
// acquire lock
mu.Lock()
// use resource
resource = 1
// release lock
mu.Unlock()
临界区（critical section）：Lock()和Unlock()之间的内容
无论哪条路径都要释放
其他的goroutine只有在当前持有锁的goroutine调用Unlock()之后才能获得锁，因此必须保证在goroutine结束之后持有的锁被释放。无论以哪条路径通过函数，包括错误路径。在结构复杂的代码中，很难靠人去判断Lock()和Unlock()是否在所有路径中都严格配对，因此需要Go中的defer来调用Unlock()。
使用defer关键字
使用defer来调用Unlock()时，临界区会隐式地延伸到函数作用域的最后，即使在临界区发生panic的时候也会执行。由Go自动完成。
func UseResource() int {
mu.Lock()
defer mu.Unlock() // 在return之后执行
return resource
}
defer调用的成本比直接调用Unlock()会高一些，是为了代码的可读性和整洁度做出的trade-off。
As always with concurrent programs, favor clarity and resist premature optimization.
sync.Mutex不具可重入性（re-entrant）
// ***错误示例***
func Op1() {
mu.Lock()
defer mu.Unlock()
Op2() // 错误，会死锁，会卡在Op2()中的mu.Lock()
// do something
}
func Op2() {
mu.Lock()
defer mu.Unlock()
// do something
}
当goroutine A调用Op1()时，在进入Op2()后无法再次获得互斥锁，即使占用该锁的goroutine是当前goroutine A。
对应的是Java中的java.util.concurrent.locks.ReentrantLock，这个可重入的，同一线程内部调用的方法可以再次获得当前线程持有的锁。
一个通用的解决方案：将一个函数分离为多个函数，比如分离出的实际操作数据的函数subOp2()，该函数默认goroutine在进入该函数前就已经持有相应的互斥锁。
// 正确示例
func Op1() {
mu.Lock()
defer mu.Unlock()
subOp2() // subOp2()并不去尝试获取锁
// do something
}
func Op2() {
mu.Lock()
defer mu.Unlock()
subOp2()
}
func subOp2() {
// do something
}
二、读写锁
sync.RWMutex：多读单写锁（multiple readers, single writer lock）
var mu sync.RWMutex
// 读锁
// 只与写锁互斥，与其他占用读锁的goroutine不互斥
mu.RLock() // 获取读锁
mu.RUnlock() // 释放读锁
// 写锁
// 与读锁和写锁都互斥，跟sync.Mutex表现一致
mu.Lock() //获取写锁
mu.Unlock() //释放写锁
何时使用
因为RWMutex的开销较大，故满足以下两个条件的时候才适合使用读写锁：
- 多数尝试获取该锁的goroutines都是读操作
- 该锁在竞争条件下（under contention）
锁的竞争条件
根据可能同时尝试获取该锁的goroutine的数量来区分
竞争锁：goroutine经常需要被阻塞等待来获取该锁
非竞争锁：一个goroutine来需求该锁的时候没有别的goroutine来竞争（注意不一定自始至终只有一个goroutine，只是不会同时来尝试获取）
实际应用中通常分为两类：经常性竞争（mostly contended）和非经常性竞争（mostly uncontended）。一般通过提升非竞争锁的性能来优化程序整体的性能[2]。
1/20/2018
