第九章 基于共享变量的并发（三）锁

使用锁的一般流程

一、互斥锁

思想

对资源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的开销较大，故满足以下两个条件的时候才适合使用读写锁：

1. 多数尝试获取该锁的goroutines都是读操作
2. 该锁在竞争条件下（under contention）

锁的竞争条件

根据可能同时尝试获取该锁的goroutine的数量来区分

竞争锁：goroutine经常需要被阻塞等待来获取该锁

非竞争锁：一个goroutine来需求该锁的时候没有别的goroutine来竞争（注意不一定自始至终只有一个goroutine，只是不会同时来尝试获取）

实际应用中通常分为两类：经常性竞争（mostly contended）和非经常性竞争（mostly uncontended）。一般通过提升非竞争锁的性能来优化程序整体的性能^[2]。

1/20/2018

---

1. 第九章 基于共享变量的并发（一）竞争条件 ↩

2. Synchronization optimizations in Mustang ↩