golang中sync.RWMutex和sync.Mutex區別

golang中sync包實現了兩種鎖Mutex （互斥鎖）和RWMutex（讀寫鎖），其中RWMutex是基於Mutex實現的，只讀鎖的實現使用相似引用計數器的功能．

type Mutex

    func (m *Mutex) Lock()

    func (m *Mutex) Unlock()

type RWMutex

    func (rw *RWMutex) Lock()

    func (rw *RWMutex) RLock()

    func (rw *RWMutex) RLocker() Locker

    func (rw *RWMutex) RUnlock()

    func (rw *RWMutex) Unlock()

其中Mutex爲互斥鎖，Lock()加鎖，Unlock()解鎖，使用Lock()加鎖後，便不能再次對其進行加鎖，直到利用Unlock()解鎖對其解鎖後，才能再次加鎖．適用於讀寫不肯定場景，即讀寫次數沒有明顯的區別，而且只容許只有一個讀或者寫的場景，因此該鎖葉叫作全局鎖．

func (m *Mutex) Unlock()用於解鎖m，若是在使用Unlock()前未加鎖，就會引發一個運行錯誤．

已經鎖定的Mutex並不與特定的goroutine相關聯，這樣能夠利用一個goroutine對其加鎖，再利用其餘goroutine對其解鎖．

正常運行例子：

package main

import (
	"fmt"
	"sync"
)

func main() {
	var l *sync.Mutex
	l = new(sync.Mutex)
	l.Lock()
	defer l.Unlock()
	fmt.Println("1")
}
結果輸出：１ 

當Unlock()在Lock()以前使用時，便會報錯

package main

import (
	"fmt"
	"sync"
)

func main() {
	var l *sync.Mutex
	l = new(sync.Mutex)
	l.Unlock()
	fmt.Println("1")
	l.Lock()
}
運行結果： panic: sync: unlock of unlocked mutex 

當在解鎖以前再次進行加鎖，便會死鎖狀態

package main

import (
	"fmt"
	"sync"
)

func main() {
	var l *sync.Mutex
	l = new(sync.Mutex)
	l.Lock()
	fmt.Println("1")
	l.Lock()
}
運行結果：  1
  
  fatal error: all goroutines are asleep - deadlock!

RWMutex是一個讀寫鎖，該鎖能夠加多個讀鎖或者一個寫鎖，其常常用於讀次數遠遠多於寫次數的場景．

  func (rw *RWMutex) Lock()　　寫鎖，若是在添加寫鎖以前已經有其餘的讀鎖和寫鎖，則lock就會阻塞直到該鎖可用，爲確保該鎖最終可用，已阻塞的 Lock 調用會從得到的鎖中排除新的讀取器，即寫鎖權限高於讀鎖，有寫鎖時優先進行寫鎖定
  func (rw *RWMutex) Unlock()　寫鎖解鎖，若是沒有進行寫鎖定，則就會引發一個運行時錯誤．

package main

import (
	"fmt"
	"sync"
)

func main() {
	var l *sync.RWMutex
	l = new(sync.RWMutex)
	l.Unlock()
	fmt.Println("1")
	l.Lock()
}
運行結果：panic: sync: unlock of unlocked mutex

    func (rw *RWMutex) RLock() 讀鎖，當有寫鎖時，沒法加載讀鎖，當只有讀鎖或者沒有鎖時，能夠加載讀鎖，讀鎖能夠加載多個，因此適用於＂讀多寫少＂的場景

func (rw *RWMutex)RUnlock()　讀鎖解鎖，RUnlock 撤銷單次 RLock 調用，它對於其它同時存在的讀取器則沒有效果。若 rw 並無爲讀取而鎖定，調用 RUnlock 就會引起一個運行時錯誤(注：這種說法在go1.3版本中是不對的，例以下面這個例子)。

package main

import (
	"fmt"
	"sync"
)

func main() {
	var l *sync.RWMutex
	l = new(sync.RWMutex)
	l.RUnlock()　　　　//１個RUnLock
	fmt.Println("1")
	l.RLock()              
}

運行結果：１
可是程序中先嚐試 解鎖讀鎖，而後才加讀鎖，可是沒有報錯，而且可以正常輸出．

分析：go1.3版本中出現這種狀況的緣由分析，經過閱讀源碼能夠很清晰的獲得結果

func (rw *RWMutex) RUnlock() {
	if raceenabled {
		_ = rw.w.state
		raceReleaseMerge(unsafe.Pointer(&rw.writerSem))
		raceDisable()
	}<span style="color:#FF0000;">
	if atomic.AddInt32(&rw.readerCount, -1) < 0 {　//readercounter初始值爲０,調用RUnLock以後變爲-1，繼續往下執行
		// A writer is pending.
		if atomic.AddInt32(&rw.readerWait, -1) == 0 {　//此時readerwaiter變爲１，1-1以後變爲０,能夠繼續之後的操做．</span>
			// The last reader unblocks the writer.
			runtime_Semrelease(&rw.writerSem)
		}
	}
	if raceenabled {
		raceEnable()
	}
}

當RUnlock多於RLock多個時，便會報錯，進入死鎖．實例以下：

package main

import (
	"fmt"
	"sync"
)

type s struct {
	readerCount int32
}

func main() {
	l := new(sync.RWMutex)
	l.RUnlock()
	l.RUnlock()　　　　　　　　//此處出現死鎖
	fmt.Println("1")
	l.RLock()
}
運行結果：
1
  
  fatal error: all goroutines are asleep - deadlock!

總結：

因此在go1.3版本中，運行過程當中容許RUnLock早於RLock一個，也只能早於１個（注：雖然代碼容許，可是強烈不推薦使用），而且在早於以後必須利用RLock進行加鎖才能夠繼續使用．