Go语言的100个错误使用场景（55-60）｜并发基础

前言

大家好，这里是白泽。**《Go语言的100个错误以及如何避免》**是最近朋友推荐我阅读的书籍，我初步浏览之后，大为惊喜。就像这书中第一章的标题说到的：“Go: Simple to learn but hard to master”，整本书通过分析100个错误使用 Go 语言的场景，带你深入理解 Go 语言。

我的愿景是以这套文章，在保持权威性的基础上，脱离对原文的依赖，对这100个场景进行篇幅合适的中文讲解。所涉内容较多，总计约 8w 字，这是该系列的第七篇文章，对应书中第55-60个错误场景。

🌟 当然，如果您是一位 Go 学习的新手，您可以在我开源的学习仓库中，找到针对**《Go 程序设计语言》**英文书籍的配套笔记，其他所有文章也会整理收集在其中。

📺 B站：白泽talk，公众号【白泽talk】，聊天交流群：622383022，原书电子版可以加群获取。

前文链接：

• 《Go语言的100个错误使用场景（1-10）｜代码和项目组织》

• 《Go语言的100个错误使用场景（11-20）｜项目组织和数据类型》

• 《Go语言的100个错误使用场景（21-29）｜数据类型》

• 《Go语言的100个错误使用场景（30-40）｜数据类型与字符串使用》

• 《Go语言的100个错误使用场景（40-47）｜字符串&函数&方法》

• 《Go语言的100个错误使用场景（48-54）｜错误管理》

8. 并发基础

🌟 章节概述

• 理解并发和并行
• 为什么并发并不总是更快
• cup 负载和 io 负载的影响
• 使用 channel 对比使用互斥锁
• 理解数据竞争和竞态条件的区别
• 使用 Go context

8.1 混淆并发与并行的概念（#55）

以一家咖啡店的运作为例讲解一下并发和并行的概念。

• 并行：强调执行，如两个咖啡师同时在给咖啡拉花
• 并发：两个咖啡师竞争一个咖啡研磨机器的使用

8.2 认为并发总是更快（#56）

• 线程：OS 调度的基本单位，用于调度到 CPU 上执行，线程的切换是一个高昂的操作，因为要求将当前 CPU 中运行态的线程上下文保存，切换到可执行态，同时调度一个可执行态的线程到 CPU 中执行。
• 协程：线程由 OS 上下文切换 CPU 内核，而 Goroutine 则由 Go 运行时上下文切换协程。Go 协程占用内存比线程少（2KB/2MB），协程的上下文切换比线程快80～90%。

🌟 GMP 模型：

• G：Goroutine
  • 执行态：被调度到 M 上执行
  • 可执行态：等待被调度
  • 等待态：因为一些原因被阻塞
• M：OS thread
• P：CPU core
  • 每个 P 有一个本地 G 队列（任务队列）
  • 所有 P 有一个公共 G 队列（任务队列）

协程调度规则：每一个 OS 线程（M）被调度到 P 上执行，然后每一个 G 运行在 M 上。

🌟 上图中展示了一个4核 CPU 的机器调度 Go 协程的场景：

此时 P2 正在闲置因为 M3 执行完毕释放了对 P2 的占用，虽然 P2 的 Local queue 中已经空了，没有 G 可以调度执行，但是每隔一定时间，Go runtime 会去 Global queue 和其他 P 的 local queue 偷取一些 G 用于调度执行（当前存在6个可执行的G）。

特别的，在 Go1.14 之前，Go 协程的调度是合作形式的，因此 Go 协程发生切换的只会因为阻塞等待（IO/channel/mutex等），但 Go1.14 之后，运行时间超过 10ms 的协程会被标记为可抢占，可以被其他协程抢占 P 的执行。

🌟 为了印证有时候多协程并不一定会提高性能，这里以归并排序为例举三个例子：

示例一：

func sequentialMergesort(s []int) {if len(s) <= 1 {return}middle := len(s) / 2sequentialMergesort(s[:middle])sequentialMergesort(s[middle:])merge(s, middle)
}func merge(s []int, middle int) {// ...
}

示例二：

func sequentialMergesortV1(s []int) {if len(s) <= 1 {return}middle := len(s) / 2var wg sync.WaitGroup()wg.Add(2)go func() {defer wd.Done()parallelMergesortV1(s[:middle])}()go func() {defer wd.Done()parallelMergesortV1(s[middle:])}()wg.Wait()merge(s, middle)
}

示例三：

const max = 2048func sequentialMergesortV2(s []int) {if len(s) <= 1 {return}if len(s) < max {sequentialMergesort(s)} else {middle := len(s) / 2var wg sync.WaitGroup()wg.Add(2)go func() {defer wd.Done()parallelMergesortV2(s[:middle])}()go func() {defer wd.Done()parallelMergesortV2(s[middle:])}()wg.Wait()merge(s, middle)   }
}

由于创建协程和调度协程本身也有开销，第二种情况无论多少个元素都使用协程去进行并行排序，导致归并很少的元素也需要创建协程和调度，开销比排序更多，导致性能还比不上第一种顺序归并。

而在本台电脑上，经过调试第三种方式可以获得比第一种方式更优的性能，因为它在元素大于2048个的时候，选择并行排序，而少于则使用顺序排序。但是2048是一个魔法数，不同电脑上可能不同。这里这是为了证明，完全依赖并发/并行的机制，并不一定会提高性能，需要注意协程本身的开销。

8.3 分不清何时使用互斥锁或 channel（#57）

• mutex：针对 G1 和 G2 这种并行执行的两个协程，它们可能会针对同一个对象进行操作，比如切片。此时是一个发生资源竞争的场景，因此适合使用互斥锁。
• channel：而上游的 G1 或者 G2 中任何一个都可以在执行完自己逻辑之后，通知 G3 开始执行，或者传递给 G3 某些处理结果，此时使用 channel，因为 Go 推荐使用 channel 作为协程间通信的手段。

8.4 不理解竞态问题（#58）

🌟 数据竞争：多个协程同时访问一块内存地址，且至少有一次写操作。

假设有两个并发协程对 i 进行自增操作：

i := 0go func() {i++
}()go func() {i++
}()

因为 i++ 操作可以被分解为3个步骤:

1. 读取 i 的值
2. 对应值 + 1
3. 将值写会 i

当并发执行两个协程的时候，i 的最终结果是无法预计的，可能为1，也可能为2。

修正方案一：

var i int64go func() {atomic.AddInt64(&i, 1)  
}()go func() {atomic.AddInt64(&i, 1)  
}()

使用 sync/atomic 包的原子运算，因为原子运算不能被打断，因此两个协程无法同时访问 i，因为客观上两个协程按顺序执行，因此最终的结果为2。

但是因为 Go 语言只为几种类型提供了原子运算，无法应对 slices、maps、structs。

修正方案二：

i := 0
mutex := sync.Mutex{}go func() {mutex.Lock()i++mutex.UnLock()
}()go func() {mutex.Lock()i++mutex.UnLock()
}()

此时被 mutex 包裹的部分，同一时刻只能允许一个协程访问。

修正方案三：

i := 0
ch := make(chan int)go func() {ch <- 1
}go func() {ch <- 1
}i += <-ch
i += <-ch

使用阻塞的 channel，主协程必须从 ch 中读取两次才能执行结束，因此结果必然是2。

🌟 Go 语言的内存模型

我们使用 A < B 表示事件 A 发生在事件 B 之前。

i := 0
go func() {i++
}()

因为创建协程发生在协程的执行，因此读取变量 i 并给 i + 1在这个例子中不会造成数据竞争。

i := 0
go func() {i++
}()
fmt.Println(i)

协程的退出无法保证一定发生在其他事件之前，因此这个例子会发生数据竞争。

i := 0
ch := make(chan struct{})
go func() {<-chfmt.Println(i)
}()
i++
ch <- struct{}{}

这个例子由于打印 i 之前，一定会执行 i++ 的操作，并且子协程等待主协程的 channel 的解除阻塞信号。

i := 0
ch := make(chan struct{})
go func() {<-chfmt.Println(i)
}()
i++
close()

和上一个例子有点像，channel 在关闭事件发生在从 channel 中读取信号之前，因此不会发生数据竞争。

i := 0
ch := make(chan struct{}, 1)
go func() {i = 1<-ch
}()
ch <- struct{}{}
fmt.Println(i)

主协程向 channel 放入值的操作执行，并不能确保与子协程的执行事件顺序，因此会发生数据竞争。

i := 0
ch := make(chan struct{})
go func() {i = 1<-ch
}()
ch <- struct{}{}
fmt.Println(i)

主协程的存入 channel 的事件，必然发生在子协程从 channel 取出事件之前，因此不会发生数据竞争。

i := 0
ch := make(chan struct{})
go func() {i = 1<-ch
}()
ch <- struct{}{}
fmt.Println(i)

无无缓冲的 channel 确保在主协程执行打印事件之前，必须会执行 i = 1 的赋值操作，因此不会发生数据竞争。

8.5 不了解工作负载类型对并发性能的影响（#59）

🌟 工作负载执行时间受到下述条件影响：

• CPU 执行速度：例如执行归并排序，此时工作负载称作——CPU约束。
• IO 执行速度：对DB进行查询，此时工作负载称作——IO约束。
• 可用内存：此时工作负载称作——内存约束。

🌟 接下来通过一个场景讲解为何讨论并发性能，需要区分负载类型：假设有一个 read 函数，从循环中每次读取1024字节，然后将获得的内容传递给一个 task 函数执行，返回一个 int 值，并每次循环对这个 int 进行求和。

串行实现：

func read(r io.Reader) (int, error) {count := 0for {b := make([]byte, 1024)_, err := r.Read(b)if err != nil {if err == io.EOF {break}return 0, err}count += task(b)}return count, nil
}

并发实现：Worker pooling pattern（工作池模式）是一种并发设计模式，用于管理一组固定数量的工作线程（worker threads）。这些工作线程从一个共享的工作队列中获取任务，并执行它们。这个模式的主要目的是提高并发性能，通过减少线程的创建和销毁，以及通过限制并发执行的任务数量来避免资源竞争。

func read(r io.Reader) (int, error) {var count int64wg := sync.WaitGroup{}var n = 10ch := make(chan []byte, n)wg.Add(n)for i := 0; i < n; i++ {go func() {defer wg.Done()for b := range ch {v := tasg(b)atomic.AddInt64(&count, int64(v))}}()}for {b := make([]byte, 1024)ch <- b}close(ch)wg.Wait()return int(count), nil
}

这个例子中，关键在于如何确定 n 的大小：

• 如果工作负载被 IO 约束：则 n 取决于外部系统，使得系统获得最大吞吐量的并发数。
• 如果工作负载被 CPU 约束：最佳实践是取决于 GOMAXPROOCS，这是一个变量存放系统允许分配给执行协程的最大线程数量，默认情况下，这个变量用于设置逻辑 CPU 的数量，因为理想状态下，只能允许最大线程数量的协程同时执行，

8.6 不懂得使用 Go contexts（#60）

🌟 A Context carries a deadline, a cancellation signal, and other values across API boundaries.

截止时间

• time.Duration（250ms）
• time.Time（2024-02-28 00:00:00 UTC）

当截止时间到达的时候，一个正在执行的行为将停止。（如IO请求，等待从 channel 中读取消息）

假设有一个雷达程序，每隔四秒钟，向其他应用提供坐标坐标信息，且只关心最新的坐标。

type publisher interface {Publish(ctx context.Content, position flight.Position) error
}type publishHandler struct {pub publisher
}func (h publishHandler) publishPosition(position flight.Position) error {ctx, cancel := context.WithTimeout(context.Background(), 4*time.Second)defer cancel()return h.pub.Publish(ctx, position)
}

通过上述代码，创建一个过期时间4秒中的 context 上下文，则应用可以通过判断 ctx.Done() 判断这个上下文是否过期或者被取消，从而判断是否为4秒内的有效坐标。

cancel() 在 return 之前调用，则可以通过 cancel 方法关闭上下文，避免内存泄漏。

取消信号

func main() {ctx. cancel := context.WithCancel(context.Background())defer cacel()go func() {CreateFileWatcher(ctx, "foo.txt") }()
}

在 main 方法执行完之前，通过调用 cancel 方法，将 ctx 的取消信号传递给 CreateFileWatcher() 函数。

上下文传递值

ctx := context.WithValue(context.Background(), "key", "value")
fmt.Println(ctx.Value("key"))# value

key 和 value 是 any 类型的。

package providertype key stringconst myCustomKey key = "key"func f(ctx context.Context) {ctx = context.WithValue(ctx, myCustomKey, "foo")// ...
}

为了避免两个不同的 package 对同一个 ctx 存入同样的 key 导致冲突，可以将 key 设置成不允许导出的类型。

一些用法：

1. 在借助 ctx 在函数之间传递同一个 id，实现链路追踪。
2. 借助 ctx 在多个中间件之间传递，存放处理信息。

type key stringconst inValidHostKey key = "isValidHost"func checkValid(next http.Handler) http.Handler {return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {validHost := r.Host == "came"ctx := context.WithValue(r.Context(), inValidHostKey, validHost)next.ServeHTTP(w, r.WithContext(ctx))})
}

checkValid 作为一个中间件，优先处理 http 请求，将处理结果存放在 ctx 中，传递给下一个处理步骤。

捕获 context 取消

context.Context 类型提供了一个 Done 方法，返回了一个接受关闭信号的 channel：<-chan struct{}，触发条件如下：

• 如果 ctx 通过 context.WithCancel 创建，则可以通过 cancel 函数关闭。
• 如果 ctx 通过 context.WithDeadline 创建，当过期的时候 channel 关闭。

此外，context.Context 提供了一个 Err 方法，将返回导致 channel 关闭的原因，如果没有关闭，调用则返回 nil。

• 返回 context.Canceled error 如果 channel 被 cancel 方法关闭。
• 返回 context.DeadlineExceeded 如果达到 deadline 过期。

func handler(ctx context.Context, ch chan Message) error {for {select {case msg := <-ch:// Do something with msgcase <-ctx.Done():return ctx.Err()}}
}

小结

你已完成《Go语言的100个错误》全书学习进度60%，欢迎追更。