Golang的锁机制

Golang 中的锁

Golang 中的有两种锁，为 sync.Mutex 和 sync.RWMutex。

• sync.Mutex 互斥锁，只有一种锁：Lock()，它是绝对锁，同一时间只能有一个锁。
• sync.RWMutex 读写锁，它有两种锁： RLock() 和 Lock()：
  RLock() 叫读锁。它不是绝对锁，比起互斥锁有着更高的并行性，它允许多个读者同时读取。
  Lock() 叫写锁，它是个绝对锁，就是说，如果一旦某人拿到了这个锁，别人就不能再获取此锁了。

另外，有一种特性：
当写锁阻塞时，新的读锁是无法申请的。
即在 sync.RWMutex 的使用中，一个线程请求了他的写锁（mx.Lock()）后，即便它还没有取到该锁（可能由于资源已被其他人锁定），后面所有的读锁的申请，都将被阻塞，只有取写锁的请求得到了锁且用完释放后，读锁才能去取。

如果一个线程因为某种原因，导致得不到CPU运行时间，这种状态被称之为 饥饿。当写锁阻塞时，新的读锁是无法申请的，这可以有效防止写者饥饿。然而，这种机制也禁止了读锁嵌套。读锁嵌套可能造成死锁。

是不是有点儿绕？下面举个“七秒例”： 🌰

第一秒：读者1在第1秒成功申请了读锁
第二秒：写者1在第2秒申请写锁，申请失败，阻塞，但它会防止新的读者获锁
第三秒：读者2在第3秒申请读锁，申请失败
第四秒：读者1释放读锁，写者1获得写锁
第五秒：写者1释放写锁，读者2获得读锁
第六秒：读者1再次申请读锁，申请成功，与读者2共享
第七秒：读者1、读者2释放读锁，结束

package main
import (
	"fmt"
	"sync"
	"time"
)
func main() {
	rw := new(sync.RWMutex)
	var deadLockCase time.Duration = 1
	go func() {
		time.Sleep(time.Second * deadLockCase)
		fmt.Println("Writer Try")
		rw.Lock()
		fmt.Println("Writer Fetch")
		time.Sleep(time.Second * 1)
		fmt.Println("Writer Release")
		rw.Unlock()
	}()
	fmt.Println("Reader 1 Try")
	rw.RLock()
	fmt.Println("Reader 1 Fetch")
	time.Sleep(time.Second * 2)
	fmt.Println("Reader 2 Try")
	rw.RLock()
	fmt.Println("Reader 2 Fetch")
	time.Sleep(time.Second * 2)
	fmt.Println("Reader 1 Release")
	rw.RUnlock()
	time.Sleep(time.Second * 1)
	fmt.Println("Reader 2 Release")
	rw.RUnlock()
	time.Sleep(time.Second * 2)
	fmt.Println("Done")
}

以上代码运行结果

Reader 1 Try
Reader 1 Fetch
Writer Try
Reader 2 Try
fatal error: all goroutines are asleep - deadlock!

分析死锁过程

再次总结一下

• 正常情况下，在请求 Lock() 锁时发现资源被锁住了，无论是 RLock() 锁还是 Lock() 锁，它都会等待。
• 正常情况下，在请求 RLock() 锁时发现资源被 Lock() 锁住了，它会等待。发现是被 RLock()
  锁住，自己也可以读取。（这个是用数字的原子操作来控制的，原理见附的文章的源码解释）
• 不要嵌套地去用 锁，这样则有可能发生死锁，即大家（所有 goroutine）都在等待锁的释放，此时发生死锁。

参考附：
http://zablog.me/2017/09/27/go_sync/