26 KiB
因收到Google相关通知，网站将会择期关闭。相关通知内容
34 并发：如何使用共享变量？
你好，我是Tony Bai。
在前面的讲解中，我们学习了Go的并发实现方案，知道了Go基于Tony Hoare的CSP并发模型理论，实现了Goroutine、channel等并发原语。
并且，Go语言之父Rob Pike还有一句经典名言：“不要通过共享内存来通信，应该通过通信来共享内存（Don’t communicate by sharing memory, share memory by communicating）”，这就奠定了Go应用并发设计的主流风格：使用channel进行不同Goroutine间的通信。
不过，Go也并没有彻底放弃基于共享内存的并发模型，而是在提供CSP并发模型原语的同时，还通过标准库的sync包，提供了针对传统的、基于共享内存并发模型的低级同步原语，包括：互斥锁（sync.Mutex）、读写锁（sync.RWMutex）、条件变量（sync.Cond）等，并通过atomic包提供了原子操作原语等等。显然，基于共享内存的并发模型在Go语言中依然有它的“用武之地”。
所以，在并发的最后一讲，我们就围绕sync包中的几个同步结构与对应的方法，聊聊基于共享内存的并发模型在Go中的应用。
我们先来看看在哪些场景下，我们需要用到sync包提供的低级同步原语。
sync包低级同步原语可以用在哪？
这里我要先强调一句，一般情况下，我建议你优先使用CSP并发模型进行并发程序设计。但是在下面一些场景中，我们依然需要sync包提供的低级同步原语。
首先是需要高性能的临界区（critical section）同步机制场景。
在Go中，channel并发原语也可以用于对数据对象访问的同步，我们可以把channel看成是一种高级的同步原语，它自身的实现也是建构在低级同步原语之上的。也正因为如此，channel自身的性能与低级同步原语相比要略微逊色，开销要更大。
这里，关于sync.Mutex和channel各自实现的临界区同步机制，我做了一个简单的性能基准测试对比，通过对比结果，我们可以很容易看出两者的性能差异：
var cs = 0 // 模拟临界区要保护的数据 var mu sync.Mutex var c = make(chan struct{}, 1)
func criticalSectionSyncByMutex() { mu.Lock() cs++ mu.Unlock() }
func criticalSectionSyncByChan() { c <- struct{}{} cs++ <-c }
func BenchmarkCriticalSectionSyncByMutex(b *testing.B) { for n := 0; n < b.N; n++ { criticalSectionSyncByMutex() } }
func BenchmarkCriticalSectionSyncByMutexInParallel(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { criticalSectionSyncByMutex() } }) }
func BenchmarkCriticalSectionSyncByChan(b *testing.B) { for n := 0; n < b.N; n++ { criticalSectionSyncByChan() } }
func BenchmarkCriticalSectionSyncByChanInParallel(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { criticalSectionSyncByChan() } }) }
运行这个对比测试（Go 1.17），我们得到：
$go test -bench . goos: darwin goarch: amd64 ... ... BenchmarkCriticalSectionSyncByMutex-8 88083549 13.64 ns/op BenchmarkCriticalSectionSyncByMutexInParallel-8 22337848 55.29 ns/op BenchmarkCriticalSectionSyncByChan-8 28172056 42.48 ns/op BenchmarkCriticalSectionSyncByChanInParallel-8 5722972 208.1 ns/op PASS
通过这个对比实验，我们可以看到，无论是在单Goroutine情况下，还是在并发测试情况下，sync.Mutex实现的同步机制的性能，都要比channel实现的高出三倍多。
因此，通常在需要高性能的临界区（critical section）同步机制的情况下，sync包提供的低级同步原语更为适合。
第二种就是在不想转移结构体对象所有权，但又要保证结构体内部状态数据的同步访问的场景。
基于channel的并发设计，有一个特点：在Goroutine间通过channel转移数据对象的所有权。所以，只有拥有数据对象所有权（从channel接收到该数据）的Goroutine才可以对该数据对象进行状态变更。
如果你的设计中没有转移结构体对象所有权，但又要保证结构体内部状态数据在多个Goroutine之间同步访问，那么你可以使用sync包提供的低级同步原语来实现，比如最常用的sync.Mutex。
了解了这些应用场景之后，接着我们就来看看如何使用sync包中的各个同步结构，不过在使用之前，我们需要先看看一个sync包中同步原语使用的注意事项。
sync包中同步原语使用的注意事项
在sync包的注释中（在$GOROOT/src/sync/mutex.go文件的头部注释），我们看到这样一行说明：
// Values containing the types defined in this package should not be copied.
翻译过来就是：“不应复制那些包含了此包中类型的值”。
在sync包的其他源文件中，我们同样看到类似的一些注释：
// $GOROOT/src/sync/mutex.go // A Mutex must not be copied after first use. （禁止复制首次使用后的Mutex）
// $GOROOT/src/sync/rwmutex.go // A RWMutex must not be copied after first use.（禁止复制首次使用后的RWMutex）
// $GOROOT/src/sync/cond.go // A Cond must not be copied after first use.（禁止复制首次使用后的Cond） ... ...
那么，为什么首次使用Mutex等sync包中定义的结构类型后，我们不应该再对它们进行复制操作呢？我们以Mutex这个同步原语为例，看看它的实现是怎样的。
Go标准库中sync.Mutex的定义是这样的：
// $GOROOT/src/sync/mutex.go type Mutex struct { state int32 sema uint32 }
我们看到，Mutex的定义非常简单，由两个整型字段state和sema组成：
state：表示当前互斥锁的状态； sema：用于控制锁状态的信号量。
初始情况下，Mutex的实例处于Unlocked状态（state和sema均为0）。对Mutex实例的复制也就是两个整型字段的复制。一旦发生复制，原变量与副本就是两个单独的内存块，各自发挥同步作用，互相就没有了关联。
如果发生复制后，你仍然认为原变量与副本保护的是同一个数据对象，那可就大错特错了。我们来看一个例子：
func main() { var wg sync.WaitGroup i := 0 var mu sync.Mutex // 负责对i的同步访问
wg.Add(1)
// g1
go func(mu1 sync.Mutex) {
mu1.Lock()
i = 10
time.Sleep(10 * time.Second)
fmt.Printf("g1: i = %d\n", i)
mu1.Unlock()
wg.Done()
}(mu)
time.Sleep(time.Second)
mu.Lock()
i = 1
fmt.Printf("g0: i = %d\n", i)
mu.Unlock()
wg.Wait()
}
在这个例子中，我们使用一个sync.Mutex类型变量mu来同步对整型变量i的访问。我们创建一个新Goroutine：g1，g1通过函数参数得到mu的一份拷贝mu1，然后g1会通过mu1来同步对整型变量i的访问。
那么，g0通过mu和g1通过mu的拷贝mu1，是否能实现对同一个变量i的同步访问呢？我们来看看运行这个示例的运行结果：
g0: i = 1 g1: i = 1
从结果来看，这个程序并没有实现对i的同步访问，第9行g1对mu1的加锁操作，并没能阻塞第19行g0对mu的加锁。于是，g1刚刚将i赋值为10后，g0就又将i赋值为1了。
出现这种结果的原因就是我们前面分析的情况，一旦Mutex类型变量被拷贝，原变量与副本就各自发挥作用，互相没有关联了。甚至，如果拷贝的时机不对，比如在一个mutex处于locked的状态时对它进行了拷贝，就会对副本进行加锁操作，将导致加锁的Goroutine永远阻塞下去。
通过前面这个例子，我们可以很直观地看到：如果对使用过的、sync包中的类型的示例进行复制，并使用了复制后得到的副本，将导致不可预期的结果。所以，在使用sync包中的类型的时候，我们推荐通过闭包方式，或者是传递类型实例（或包裹该类型的类型实例）的地址（指针）的方式进行。这就是使用sync包时最值得我们注意的事项。
接下来，我们就来逐个分析日常使用较多的sync包中同步原语。我们先来看看互斥锁与读写锁。
互斥锁（Mutex）还是读写锁（RWMutex）？
sync包提供了两种用于临界区同步的原语：互斥锁（Mutex）和读写锁（RWMutex）。它们都是零值可用的数据类型，也就是不需要显式初始化就可以使用，并且使用方法都比较简单。在上面的示例中，我们已经看到了Mutex的应用方法，这里再总结一下：
var mu sync.Mutex mu.Lock() // 加锁 doSomething() mu.Unlock() // 解锁
一旦某个Goroutine调用的Mutex执行Lock操作成功，它将成功持有这把互斥锁。这个时候，如果有其他Goroutine执行Lock操作，就会阻塞在这把互斥锁上，直到持有这把锁的Goroutine调用Unlock释放掉这把锁后，才会抢到这把锁的持有权并进入临界区。
由此，我们也可以得到使用互斥锁的两个原则：
尽量减少在锁中的操作。这可以减少其他因Goroutine阻塞而带来的损耗与延迟。 一定要记得调用Unlock解锁。忘记解锁会导致程序局部死锁，甚至是整个程序死锁，会导致严重的后果。同时，我们也可以结合第23讲学习到的defer，优雅地执行解锁操作。
读写锁与互斥锁用法大致相同，只不过多了一组加读锁和解读锁的方法：
var rwmu sync.RWMutex rwmu.RLock() //加读锁 readSomething() rwmu.RUnlock() //解读锁 rwmu.Lock() //加写锁 changeSomething() rwmu.Unlock() //解写锁
写锁与Mutex的行为十分类似，一旦某Goroutine持有写锁，其他Goroutine无论是尝试加读锁，还是加写锁，都会被阻塞在写锁上。
但读锁就宽松多了，一旦某个Goroutine持有读锁，它不会阻塞其他尝试加读锁的Goroutine，但加写锁的Goroutine依然会被阻塞住。
通常，互斥锁（Mutex）是临时区同步原语的首选，它常被用来对结构体对象的内部状态、缓存等进行保护，是使用最为广泛的临界区同步原语。相比之下，读写锁的应用就没那么广泛了，只活跃于它擅长的场景下。
那读写锁（RWMutex）究竟擅长在哪种场景下呢？我们先来看一组基准测试：
var cs1 = 0 // 模拟临界区要保护的数据 var mu1 sync.Mutex
var cs2 = 0 // 模拟临界区要保护的数据 var mu2 sync.RWMutex
func BenchmarkWriteSyncByMutex(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { mu1.Lock() cs1++ mu1.Unlock() } }) }
func BenchmarkReadSyncByMutex(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { mu1.Lock() _ = cs1 mu1.Unlock() } }) }
func BenchmarkReadSyncByRWMutex(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { mu2.RLock() _ = cs2 mu2.RUnlock() } }) }
func BenchmarkWriteSyncByRWMutex(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { mu2.Lock() cs2++ mu2.Unlock() } }) }
这些基准测试都是并发测试，度量的是Mutex、RWMutex在并发下的读写性能。我们分别在cpu=2、8、16、32的情况下运行这个并发性能测试，测试结果如下：
goos: darwin goarch: amd64 ... ... BenchmarkWriteSyncByMutex-2 73423770 16.12 ns/op BenchmarkReadSyncByMutex-2 84031135 15.08 ns/op BenchmarkReadSyncByRWMutex-2 37182219 31.87 ns/op BenchmarkWriteSyncByRWMutex-2 40727782 29.08 ns/op
BenchmarkWriteSyncByMutex-8 22153354 56.39 ns/op BenchmarkReadSyncByMutex-8 24164278 51.12 ns/op BenchmarkReadSyncByRWMutex-8 38589122 31.17 ns/op BenchmarkWriteSyncByRWMutex-8 18482208 65.27 ns/op
BenchmarkWriteSyncByMutex-16 20672842 62.94 ns/op BenchmarkReadSyncByMutex-16 19247158 62.94 ns/op BenchmarkReadSyncByRWMutex-16 29978614 39.98 ns/op BenchmarkWriteSyncByRWMutex-16 16095952 78.19 ns/op
BenchmarkWriteSyncByMutex-32 20539290 60.20 ns/op BenchmarkReadSyncByMutex-32 18807060 72.61 ns/op BenchmarkReadSyncByRWMutex-32 29772936 40.45 ns/op BenchmarkWriteSyncByRWMutex-32 13320544 86.53 ns/op
通过测试结果对比，我们得到了一些结论：
并发量较小的情况下，Mutex性能最好；随着并发量增大，Mutex的竞争激烈，导致加锁和解锁性能下降； RWMutex的读锁性能并没有随着并发量的增大，而发生较大变化，性能始终恒定在40ns左右； 在并发量较大的情况下，RWMutex的写锁性能和Mutex、RWMutex读锁相比，是最差的，并且随着并发量增大，RWMutex写锁性能有继续下降趋势。
由此，我们就可以看出，读写锁适合应用在具有一定并发量且读多写少的场合。在大量并发读的情况下，多个Goroutine可以同时持有读锁，从而减少在锁竞争中等待的时间。
而互斥锁，即便是读请求的场合，同一时刻也只能有一个Goroutine持有锁，其他Goroutine只能阻塞在加锁操作上等待被调度。
接下来，我们继续看条件变量sync.Cond。
条件变量
sync.Cond是传统的条件变量原语概念在Go语言中的实现。我们可以把一个条件变量理解为一个容器，这个容器中存放着一个或一组等待着某个条件成立的Goroutine。当条件成立后，这些处于等待状态的Goroutine将得到通知，并被唤醒继续进行后续的工作。这与百米飞人大战赛场上，各位运动员等待裁判员的发令枪声的情形十分类似。
条件变量是同步原语的一种，如果没有条件变量，开发人员可能需要在Goroutine中通过连续轮询的方式，检查某条件是否为真，这种连续轮询非常消耗资源，因为Goroutine在这个过程中是处于活动状态的，但它的工作又没有进展。
这里我们先看一个用sync.Mutex 实现对条件轮询等待的例子：
type signal struct{}
var ready bool
func worker(i int) { fmt.Printf("worker %d: is working...\n", i) time.Sleep(1 * time.Second) fmt.Printf("worker %d: works done\n", i) }
func spawnGroup(f func(i int), num int, mu *sync.Mutex) <-chan signal { c := make(chan signal) var wg sync.WaitGroup
for i := 0; i < num; i++ {
wg.Add(1)
go func(i int) {
for {
mu.Lock()
if !ready {
mu.Unlock()
time.Sleep(100 * time.Millisecond)
continue
}
mu.Unlock()
fmt.Printf("worker %d: start to work...\n", i)
f(i)
wg.Done()
return
}
}(i + 1)
}
go func() {
wg.Wait()
c <- signal(struct{}{})
}()
return c
}
func main() { fmt.Println("start a group of workers...") mu := &sync.Mutex{} c := spawnGroup(worker, 5, mu)
time.Sleep(5 * time.Second) // 模拟ready前的准备工作
fmt.Println("the group of workers start to work...")
mu.Lock()
ready = true
mu.Unlock()
<-c
fmt.Println("the group of workers work done!")
}
就像前面提到的，轮询的方式开销大，轮询间隔设置的不同，条件检查的及时性也会受到影响。- sync.Cond为Goroutine在这个场景下提供了另一种可选的、资源消耗更小、使用体验更佳的同步方式。使用条件变量原语，我们可以在实现相同目标的同时，避免对条件的轮询。
我们用sync.Cond对上面的例子进行改造，改造后的代码如下：
type signal struct{}
var ready bool
func worker(i int) { fmt.Printf("worker %d: is working...\n", i) time.Sleep(1 * time.Second) fmt.Printf("worker %d: works done\n", i) }
func spawnGroup(f func(i int), num int, groupSignal *sync.Cond) <-chan signal { c := make(chan signal) var wg sync.WaitGroup
for i := 0; i < num; i++ {
wg.Add(1)
go func(i int) {
groupSignal.L.Lock()
for !ready {
groupSignal.Wait()
}
groupSignal.L.Unlock()
fmt.Printf("worker %d: start to work...\n", i)
f(i)
wg.Done()
}(i + 1)
}
go func() {
wg.Wait()
c <- signal(struct{}{})
}()
return c
}
func main() { fmt.Println("start a group of workers...") groupSignal := sync.NewCond(&sync.Mutex{}) c := spawnGroup(worker, 5, groupSignal)
time.Sleep(5 * time.Second) // 模拟ready前的准备工作
fmt.Println("the group of workers start to work...")
groupSignal.L.Lock()
ready = true
groupSignal.Broadcast()
groupSignal.L.Unlock()
<-c
fmt.Println("the group of workers work done!")
}
我们运行这个示例程序，得到：
start a group of workers... the group of workers start to work... worker 2: start to work... worker 2: is working... worker 3: start to work... worker 3: is working... worker 1: start to work... worker 1: is working... worker 4: start to work... worker 5: start to work... worker 5: is working... worker 4: is working... worker 4: works done worker 2: works done worker 3: works done worker 1: works done worker 5: works done the group of workers work done!
我们看到，sync.Cond实例的初始化，需要一个满足实现了sync.Locker接口的类型实例，通常我们使用sync.Mutex。
条件变量需要这个互斥锁来同步临界区，保护用作条件的数据。加锁后，各个等待条件成立的Goroutine判断条件是否成立，如果不成立，则调用sync.Cond的Wait方法进入等待状态。Wait方法在Goroutine挂起前会进行Unlock操作。
当main goroutine将ready置为true，并调用sync.Cond的Broadcast方法后，各个阻塞的Goroutine将被唤醒，并从Wait方法中返回。Wait方法返回前，Wait方法会再次加锁让Goroutine进入临界区。接下来Goroutine会再次对条件数据进行判定，如果条件成立，就会解锁并进入下一个工作阶段；如果条件依旧不成立，那么会再次进入循环体，并调用Wait方法挂起等待。
和sync.Mutex 、sync.RWMutex等相比，sync.Cond 应用的场景更为有限，只有在需要“等待某个条件成立”的场景下，Cond才有用武之地。
其实，面向CSP并发模型的channel原语和面向传统共享内存并发模型的sync包提供的原语，已经能够满足Go语言应用并发设计中99.9%的并发同步需求了。而剩余那0.1%的需求，我们可以使用Go标准库提供的atomic包来实现。
原子操作（atomic operations）
atomic包是Go语言给用户提供的原子操作原语的相关接口。原子操作（atomic operations）是相对于普通指令操作而言的。
我们以一个整型变量自增的语句为例说明一下：
var a int a++
a++这行语句需要3条普通机器指令来完成变量a的自增：
LOAD：将变量从内存加载到CPU寄存器； ADD：执行加法指令； STORE：将结果存储回原内存地址中。
这3条普通指令在执行过程中是可以被中断的。而原子操作的指令是不可中断的，它就好比一个事务，要么不执行，一旦执行就一次性全部执行完毕，中间不可分割。也正因为如此，原子操作也可以被用于共享数据的并发同步。
原子操作由底层硬件直接提供支持，是一种硬件实现的指令级的“事务”，因此相对于操作系统层面和Go运行时层面提供的同步技术而言，它更为原始。
atomic包封装了CPU实现的部分原子操作指令，为用户层提供体验良好的原子操作函数，因此atomic包中提供的原语更接近硬件底层，也更为低级，它也常被用于实现更为高级的并发同步技术，比如channel和sync包中的同步原语。
我们以atomic.SwapInt64函数在x86_64平台上的实现为例，看看这个函数的实现方法：
// $GOROOT/src/sync/atomic/doc.go func SwapInt64(addr *int64, new int64) (old int64)
// $GOROOT/src/sync/atomic/asm.s
TEXT ·SwapInt64(SB),NOSPLIT,$0 JMP runtime∕internal∕atomic·Xchg64(SB)
// $GOROOT/src/runtime/internal/atomic/asm_amd64.s TEXT runtime∕internal∕atomic·Xchg64(SB), NOSPLIT, $0-24 MOVQ ptr+0(FP), BX MOVQ new+8(FP), AX XCHGQ AX, 0(BX) MOVQ AX, ret+16(FP) RET
从函数SwapInt64的实现中，我们可以看到：它基本就是对x86_64 CPU实现的原子操作指令XCHGQ的直接封装。
原子操作的特性，让atomic包也可以被用作对共享数据的并发同步，那么和更为高级的channel以及sync包中原语相比，我们究竟该怎么选择呢？
我们先来看看atomic包提供了哪些能力。
atomic包提供了两大类原子操作接口，一类是针对整型变量的，包括有符号整型、无符号整型以及对应的指针类型；另外一类是针对自定义类型的。因此，第一类原子操作接口的存在让atomic包天然适合去实现某一个共享整型变量的并发同步。
我们再看一个例子：
var n1 int64
func addSyncByAtomic(delta int64) int64 { return atomic.AddInt64(&n1, delta) }
func readSyncByAtomic() int64 { return atomic.LoadInt64(&n1) }
var n2 int64 var rwmu sync.RWMutex
func addSyncByRWMutex(delta int64) { rwmu.Lock() n2 += delta rwmu.Unlock() }
func readSyncByRWMutex() int64 { var n int64 rwmu.RLock() n = n2 rwmu.RUnlock() return n }
func BenchmarkAddSyncByAtomic(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { addSyncByAtomic(1) } }) }
func BenchmarkReadSyncByAtomic(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { readSyncByAtomic() } }) }
func BenchmarkAddSyncByRWMutex(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { addSyncByRWMutex(1) } }) }
func BenchmarkReadSyncByRWMutex(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { readSyncByRWMutex() } }) }
我们分别在cpu=2、 8、16、32的情况下运行上述性能基准测试，得到结果如下：
goos: darwin goarch: amd64 ... ... BenchmarkAddSyncByAtomic-2 75426774 17.69 ns/op BenchmarkReadSyncByAtomic-2 1000000000 0.7437 ns/op BenchmarkAddSyncByRWMutex-2 39041671 30.16 ns/op BenchmarkReadSyncByRWMutex-2 41325093 28.48 ns/op
BenchmarkAddSyncByAtomic-8 77497987 15.25 ns/op BenchmarkReadSyncByAtomic-8 1000000000 0.2395 ns/op BenchmarkAddSyncByRWMutex-8 17702034 67.16 ns/op BenchmarkReadSyncByRWMutex-8 29966182 40.37 ns/op
BenchmarkAddSyncByAtomic-16 57727968 20.39 ns/op BenchmarkReadSyncByAtomic-16 1000000000 0.2536 ns/op BenchmarkAddSyncByRWMutex-16 15029635 78.61 ns/op BenchmarkReadSyncByRWMutex-16 29722464 40.28 ns/op
BenchmarkAddSyncByAtomic-32 58010497 20.40 ns/op BenchmarkReadSyncByAtomic-32 1000000000 0.2402 ns/op BenchmarkAddSyncByRWMutex-32 11748312 93.15 ns/op BenchmarkReadSyncByRWMutex-32 29845912 40.54 ns/op
通过这个运行结果，我们可以得出一些结论：
读写锁的性能随着并发量增大的情况，与前面讲解的sync.RWMutex一致； 利用原子操作的无锁并发写的性能，随着并发量增大几乎保持恒定； 利用原子操作的无锁并发读的性能，随着并发量增大有持续提升的趋势，并且性能是读锁的约200倍。
通过这些结论，我们大致可以看到atomic原子操作的特性：随着并发量提升，使用atomic实现的共享变量的并发读写性能表现更为稳定，尤其是原子读操作，和sync包中的读写锁原语比起来，atomic表现出了更好的伸缩性和高性能。
由此，我们也可以看出atomic包更适合一些对性能十分敏感、并发量较大且读多写少的场合。
不过，atomic原子操作可用来同步的范围有比较大限制，只能同步一个整型变量或自定义类型变量。如果我们要对一个复杂的临界区数据进行同步，那么首选的依旧是sync包中的原语。
小结
好了，今天的课讲到这里就结束了，现在我们一起来回顾一下吧。
虽然Go推荐基于通信来共享内存的并发设计风格，但Go并没有彻底抛弃对基于共享内存并发模型的支持，Go通过标准库的sync包以及atomic包提供了低级同步原语。这些原语有着它们自己的应用场景。
如果我们考虑使用低级同步原语，一般都是因为低级同步原语可以提供更佳的性能表现，性能基准测试结果告诉我们，使用低级同步原语的性能可以高出channel许多倍。在性能敏感的场景下，我们依然离不开这些低级同步原语。
在使用sync包提供的同步原语之前，我们一定要牢记这些原语使用的注意事项：不要复制首次使用后的Mutex/RWMutex/Cond等。一旦复制，你将很大可能得到意料之外的运行结果。
sync包中的低级同步原语各有各的擅长领域，你可以记住：
在具有一定并发量且读多写少的场合使用RWMutex； 在需要“等待某个条件成立”的场景下使用Cond； 当你不确定使用什么原语时，那就使用Mutex吧。
如果你对同步的性能有极致要求，且并发量较大，读多写少，那么可以考虑一下atomic包提供的原子操作函数。
思考题
使用基于共享内存的并发模型时，最令人头疼的可能就是“死锁”问题的存在了。你了解死锁的产生条件么？能编写一个程序模拟一下死锁的发生么？
欢迎你把这节课分享给更多对Go并发感兴趣的朋友。我是Tony Bai，我们下节课见。