Go基础系列：互斥锁Mutex和读写锁RWMutex用法详述
2018-12-03 08:00
295 查看
sync.Mutex
Go中使用sync.Mutex类型实现mutex(排他锁、互斥锁。在源代码的sync/mutex.go文件中，有如下定义：
// A Mutex is a mutual exclusion lock.
// The zero value for a Mutex is an unlocked mutex.
//
// A Mutex must not be copied after first use.
type Mutex struct {
state int32
sema uint32
}
这没有任何非凡的地方。和mutex相关的所有事情都是通过sync.Mutex类型的两个方法sync.Lock()和sync.Unlock()函数来完成的，前者用于获取sync.Mutex锁，后者用于释放sync.Mutex锁。sync.Mutex一旦被锁住，其它的Lock()操作就无法再获取它的锁，只有通过Unlock()释放锁之后才能通过Lock()继续获取锁。也就是说，已有的锁会导致其它申请Lock()操作的goroutine被阻塞，且只有在Unlock()的时候才会解除阻塞。另外需要注意，sync.Mutex不区分读写锁，只有Lock()与Lock()之间才会导致阻塞的情况，如果在一个地方Lock()，在另一个地方不Lock()而是直接修改或访问共享数据，这对于sync.Mutex类型来说是允许的，因为mutex不会和goroutine进行关联。如果想要区分读、写锁，可以使用sync.RWMutex类型，见后文。在Lock()和Unlock()之间的代码段称为资源的临界区(critical section)，在这一区间内的代码是严格被Lock()保护的，是线程安全的，任何一个时间点都只能有一个goroutine执行这段区间的代码。以下是使用sync.Mutex的一个示例，稍后是非常详细的分析过程。
package main第一次执行结果：
import (
"fmt"
"sync"
"time"
)
// 共享变量
var (
m sync.Mutex
v1 int
)
// 修改共享变量
// 在Lock()和Unlock()之间的代码部分是临界区
func change(i int) {
m.Lock()
time.Sleep(time.Second)
v1 = v1 + 1
if v1%10 == 0 {
v1 = v1 - 10*i
}
m.Unlock()
}
// 访问共享变量
// 在Lock()和Unlock()之间的代码部分是是临界区
func read() int {
m.Lock()
a := v1
m.Unlock()
return a
}
func main() {
var numGR = 21
var wg sync.WaitGroup
fmt.Printf("%d", read())
// 循环创建numGR个goroutine
// 每个goroutine都执行change()、read()
// 每个change()和read()都会持有锁
for i := 0; i < numGR; i++ {
wg.Add(1)
go func(i int) {
defer wg.Done()
change(i)
fmt.Printf(" -> %d", read())
}(i)
}
wg.Wait()
}
第二次执行结果：注意其中的-74和-72之间跨了一个数v1 = v1 - i*10，但这个i可能是任意0到numGR之间的值(因为无法保证并发的goroutine的调度顺序)，这使得v1的值从第10个goroutine开始出现随机性。但从第10到第19个goroutine被调度的过程中，也只是对共享变量v1做加1运算，这些值是可以根据第10个数推断出来的，到第20个goroutine，又再次随机。依此类推。此外，每个goroutine中的read()也都会参与锁竞争，所以并不能保证每次change(i)之后会随之执行到read()，可能goroutine 1的change()执行完后，会跳转到goroutine 3的change()上，这样一来，goroutine 1的read()就无法读取到goroutine 1所修改的v1值，而是访问到其它goroutine中修改后的值。所以，前面的第二次执行结果中出现了一次数据跨越。只不过执行完change()后立即执行read()的几率比较大，所以多数时候输出的数据都是连续的。总而言之，Mutex保证了每个critical section安全，某一时间点只有一个goroutine访问到这部分，但也因此而出现了随机性。如果Lock()后忘记了Unlock()，将会永久阻塞而出现死锁。如果
适合sync.Mutex的数据类型
其实，对于内置类型的共享变量来说，使用sync.Mutex和Lock()、Unlock()来保护也是不合理的，因为它们自身不包含Mutex属性。真正合理的共享变量是那些包含Mutex属性的struct类型。例如：
type mytype struct {
m sync.Mutex
var int
}
x := new(mytype)这时只要想保护var变量，就先x.m.Lock()，操作完var后，再x.m.Unlock()。这样就能保证x中的var字段变量一定是被保护的。sync.RWMutex
Go中使用sync.RWMutex类型实现读写互斥锁rwmutex。在源代码的sync/rwmutex.go文件中，有如下定义：
// A RWMutex is a reader/writer mutual exclusion lock.上面的注释和源代码说明了几点：
// The lock can be held by an arbitrary number of readers or a single writer.
// The zero value for a RWMutex is an unlocked mutex.
//
// A RWMutex must not be copied after first use.
//
// If a goroutine holds a RWMutex for reading and another goroutine might
// call Lock, no goroutine should expect to be able to acquire a read lock
// until the initial read lock is released. In particular, this prohibits
// recursive read locking. This is to ensure that the lock eventually becomes
// available; a blocked Lock call excludes new readers from acquiring the
// lock.
type RWMutex struct {
w Mutex // held if there are pending writers
writerSem uint32 // 写锁需要等待读锁释放的信号量
readerSem uint32 // 读锁需要等待写锁释放的信号量
readerCount int32 // 读锁后面挂起了多少个写锁申请
readerWait int32 // 已释放了多少个读锁
}
RWMutex是基于Mutex的，在Mutex的基础之上增加了读、写的信号量，并使用了类似引用计数的读锁数量
读锁与读锁兼容，读锁与写锁互斥，写锁与写锁互斥，只有在锁释放后才可以继续申请互斥的锁：
可以同时申请多个读锁
有读锁时申请写锁将阻塞，有写锁时申请读锁将阻塞
只要有写锁，后续申请读锁和写锁都将阻塞
此类型有几个锁和解锁的方法：
func (rw *RWMutex) Lock()其中：
func (rw *RWMutex) RLock()
func (rw *RWMutex) RLocker() Locker
func (rw *RWMutex) RUnlock()
func (rw *RWMutex) Unlock()
Lock()和Unlock()用于申请和释放写锁
RLock()和RUnlock()用于申请和释放读锁
一次RUnlock()操作只是对读锁数量减1，即减少一次读锁的引用计数
如果不存在写锁，则Unlock()引发panic，如果不存在读锁，则RUnlock()引发panic
RLocker()用于返回一个实现了Lock()和Unlock()方法的Locker接口此外，无论是Mutex还是RWMutex都不会和goroutine进行关联，这意味着它们的锁申请行为可以在一个goroutine中操作，释放锁行为可以在另一个goroutine中操作。由于RLock()和Lock()都能保证数据不被其它goroutine修改，所以在RLock()与RUnlock()之间的，以及Lock()与Unlock()之间的代码区都是critical section。以下是一个示例，此示例中同时使用了Mutex和RWMutex，RWMutex用于读、写，Mutex只用于读。
package mainChange()函数申请写锁，并睡眠3秒后修改数据，然后释放写锁。rwMutexShow()函数申请读锁，并睡眠一秒后取得数据，并释放读锁。注意，rwMutexShow()中的print和return是相隔一秒钟的。mutexShow()函数申请Mutex锁，和RWMutex互不相干。和rwMutexShow()唯一不同之处在于申请的锁不同。main()中，先根据命令行参数数量决定运行哪一个show()。之所以能根据函数变量来赋值，是因为先定义了一个show()函数，它的函数签名和rwMutexShow()、mutexShow()的签名相同，所以可以相互赋值。for循环中激活了5个goroutine并发运行，for瞬间激活5个goroutine后，继续执行main()代码会激活另一个用于申请写锁的goroutine。这6个goroutine的执行顺序是随机的。如果show选中的函数是rwMutexShow()，则5个goroutine要申请的RLock()锁和写锁是冲突的，但5个RLock()是兼容的。所以，只要某个时间点调度到了写锁的goroutine，剩下的读锁goroutine都会从那时开始阻塞3秒。除此之外，还有一个不严格准确，但在时间持续长短的理论上来说能保证的一个规律：当修改数据结束后，各个剩下的goroutine都申请读锁，因为申请后立即print输出，然后睡眠1秒，但1秒时间足够所有剩下的goroutine申请完读锁，使得
import (
"fmt"
"os"
"sync"
"time"
)
var Password = secret{password: "myPassword"}
type secret struct {
RWM sync.RWMutex
M sync.Mutex
password string
}
// 通过rwmutex写
func Change(c *secret, pass string) {
c.RWM.Lock()
fmt.Println("Change with rwmutex lock")
time.Sleep(3 * time.Second)
c.password = pass
c.RWM.Unlock()
}
// 通过rwmutex读
func rwMutexShow(c *secret) string {
c.RWM.RLock()
fmt.Println("show with rwmutex",time.Now().Second())
time.Sleep(1 * time.Second)
defer c.RWM.RUnlock()
return c.password
}
// 通过mutex读，和rwMutexShow的唯一区别在于锁的方式不同
func mutexShow(c *secret) string {
c.M.Lock()
fmt.Println("show with mutex:",time.Now().Second())
time.Sleep(1 * time.Second)
defer c.M.Unlock()
return c.password
}
func main() {
// 定义一个稍后用于覆盖(重写)的函数
var show = func(c *secret) string { return "" }
// 通过变量赋值的方式，选择并重写showFunc函数
if len(os.Args) != 2 {
fmt.Println("Using sync.RWMutex!",time.Now().Second())
show = rwMutexShow
} else {
fmt.Println("Using sync.Mutex!",time.Now().Second())
show = mutexShow
}
var wg sync.WaitGroup
// 激活5个goroutine，每个goroutine都查看
// 根据选择的函数不同，showFunc()加锁的方式不同
for i := 0; i < 5; i++ {
wg.Add(1)
go func() {
defer wg.Done()
fmt.Println("Go Pass:", show(&Password),time.Now().Second())
}()
}
// 激活一个申请写锁的goroutine
go func() {
wg.Add(1)
defer wg.Done()
Change(&Password, "123456")
}()
// 阻塞，直到所有wg.Done
wg.Wait()
}
show with rwmutex输出是连在一起，输出的
Go Pass: 123456又是连在一起的。某次结果如下：
Using sync.RWMutex! 58如果show选中的函数是mutexShow()，则读数据和写数据互不冲突，但读和读是冲突的(因为Mutex的Lock()是互斥的)。某次结果如下：
show with rwmutex 58
Change with rwmutex lock
Go Pass: myPassword 59
show with rwmutex 2
show with rwmutex 2
show with rwmutex 2
show with rwmutex 2
Go Pass: 123456 3
Go Pass: 123456 3
Go Pass: 123456 3
Go Pass: 123456 3
Using sync.Mutex! 30
Change with rwmutex lock
show with mutex: 30
Go Pass: myPassword 31
show with mutex: 31
Go Pass: myPassword 32
show with mutex: 32
Go Pass: 123456 33
show with mutex: 33
show with mutex: 34
Go Pass: 123456 34
Go Pass: 123456 35
用Mutex还是用RWMutex
Mutex和RWMutex都不关联goroutine，但RWMutex显然更适用于读多写少的场景。仅针对读的性能来说，RWMutex要高于Mutex，因为rwmutex的多个读可以并存。文章转载来自于作者骏马金龙，
原文链接：
http://www.cnblogs.com/f-ck-need-u/p/9998729.html
阅读更多
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Go基础系列：互斥锁Mutex和读写锁RWMutex用法详述
- Go基础系列：WaitGroup用法说明
- Go基础系列：双层channel用法示例
- Go基础系列：nil channel用法示例
- J2SE基础夯实系列之Iterator(迭代器)的一般用法 （转）
- C#基础系列——多线程的常见用法详解
- POSIX---互斥锁(pthread_mutex)和条件变量(pthread_cond)的用法
- Go基础系列：Go实现工作池的两种方式
- Go基础系列：import导包和初始化阶段
- J2SE基础夯实系列之Iterator(迭代器)的一般用法 （转）
- leo学习系列之五——leo基础用法@root
- Golang 入门系列（三）Go语言基础知识汇总
- Go基础系列：Go中的方法
- Go语言学习之sync包(临时对象池Pool、互斥锁Mutex、等待Cond)(the way to go)
- go基础系列：数组
- Go基础系列：常量和变量
- Go基础系列：数据类型转换(strconv包)
- PLSQL_基础系列12_替换函数用法REPLACE / TRANSLATE / REGEXP_REPLACE
- C#基础系列——多线程的常见用法详解
- html基础知识点系列1--常见元素及其语义用法