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，我们下节课见。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/Tony%20Bai%20%c2%b7%20Go%e8%af%ad%e8%a8%80%e7%ac%ac%e4%b8%80%e8%af%be/34%20%e5%b9%b6%e5%8f%91%ef%bc%9a%e5%a6%82%e4%bd%95%e4%bd%bf%e7%94%a8%e5%85%b1%e4%ba%ab%e5%8f%98%e9%87%8f%ef%bc%9f.md