# 并发该技能涵盖了 Google 的 Go 风格指南和 Uber 的 Go 风格指南中的并发模式和最佳实践，包括 goroutine 管理、通道使用、互斥处理和同步。 ** ** ## Goroutine 生命周期 > **规范** ：当您生成 goroutine 时，请明确它们何时或是否退出。 ### 为什么 Goroutine 生命周期很重要 Goroutine 可能会因阻塞通道发送或接收而发生泄漏。即使没有其他 goroutine 引用该通道，垃圾收集器**也不会终止**阻塞在通道上的 goroutine。即使 goroutine 没有泄漏，当不再需要时让它们继续运行也会导致： * **恐慌** ：在关闭的通道上发送会导致恐慌 * **数据竞争**：不需要结果后修改仍在使用的输入 * **内存问题**：长期存在的 goroutine 的内存使用量不可预测 * **资源泄漏** ：防止未使用的对象被垃圾收集 // 不好：在关闭的通道上发送会导致恐慌 ch := make(chan int) 章节 <- 42 关闭（通道） ch <- 13 // 恐慌 ### 让生命周期变得显而易见编写并发代码，使 goroutine 生命周期显而易见。将与同步相关的代码限制在函数范围内，并将逻辑分解为同步函数。 // 好：Goroutine 的生命周期很清楚 func (w *Worker) Run(ctx context.Context) 错误 { var wgsync.WaitGroup for item := 范围 w.q { 工作组.添加(1) 去函数（）{ 推迟 wg.Done() process(ctx, item) // 当上下文取消时返回 }() } wg.Wait() // 防止生成的 goroutine 超过此函数的寿命 } // 不好：不关心 goroutine 何时完成 func (w *Worker) Run() { for item := 范围 w.q { go process(item) // 什么时候完成？如果它永远不会发生怎么办？ } } ### 不要“一劳永逸”的 Goroutine 每个 goroutine 都必须有一个可预测的停止机制： * 停止运行的可预测时间，或者 * 一种指示它应该停止的方法 * 代码必须能够阻塞并等待 goroutine 完成 > **来源**：Uber Go 风格指南 // 不好：无法停止或等待这个 goroutine 去函数（）{ 对于{ 冲洗（）时间.睡眠（延迟） } }() // 好：用于受控关闭的停止/完成通道模式变量（ stop = make(chan struct{}) // 告诉 goroutine 停止 done = make(chan struct{}) // 告诉我们 goroutine 已退出）去函数（）{ 推迟关闭（完成）股票代码 := time.NewTicker(延迟) 延迟股票代码.Stop() 对于{ 选择{ case <-ticker.C: 冲洗（）案例<-停止：返回 } } }() // 关闭： close(stop) // 通知 goroutine 停止 <-done // 并等待它退出 ### 等待 Goroutine 对多个 goroutine 使用 `sync.WaitGroup`： var wgsync.WaitGroup 对于我：= 0；我 **来源**：Uber Go 风格指南 // 不好：产生无法控制的后台 goroutine 函数初始化（）{ 去工作（） } // 好：显式的生命周期管理类型工人结构{ 停止 chan 结构体{} 完成 chan 结构{} } func NewWorker() *Worker { w := &工人{ 停止：make(chan struct{}), 完成：make(chan struct{}), } 去 w.doWork() 返回w } func (w *Worker) 关闭() { 关闭（w.stop） <-w.完成 } ### 测试 Goroutine 泄漏使用 [go.uber.org/goleak]() 来测试生成 goroutine 的包中的 goroutine 泄漏。 > **原则**：永远不要在不知道 Goroutine 如何停止的情况下启动它。 ** ** ## 零值互斥体 `sync.Mutex` 和 `sync.RWMutex` 的零值是有效的，因此您几乎不需要指向互斥锁的指针。 > **来源**：Uber Go 风格指南 // 不好：不必要的指针 mu := new(sync.Mutex) mu.Lock() // 好：零值有效 var musync.Mutex mu.Lock() ### 不要嵌入互斥体如果通过指针使用结构体，则互斥体应该是非指针字段。即使未导出结构，也不要在结构上嵌入互斥体。 // 不好：嵌入式互斥体将锁定/解锁公开为 API 的一部分类型 SMap 结构体 { sync.Mutex // Lock() 和 Unlock() 成为 SMap 的方法数据映射[string]string } func (m *SMap) Get(k 字符串) 字符串 { m.Lock() 延迟 m.Unlock() 返回m.data[k] } // 好：命名字段将互斥体保留为实现细节类型 SMap 结构体 { mu同步互斥体数据映射[string]string } func (m *SMap) Get(k 字符串) 字符串 { m.mu.Lock() 延迟 m.mu.Unlock() 返回m.data[k] } 举个坏例子，“Lock”和“Unlock”方法无意中成为导出 API 的一部分。举个很好的例子，互斥量是对调用者隐藏的实现细节。 ** ** ## 同步函数 > **规范**：优先使用同步函数而不是异步函数。 ### 为什么更喜欢同步函数？ 1. **本地化 goroutine** ：将 goroutine 保留在调用中，使生命周期更容易推理 2. **避免泄漏和竞争**：更容易防止资源泄漏和数据竞争 3. **更容易测试**：调用者可以传递输入并检查输出而无需轮询 4. **调用者灵活性** ：调用者可以通过调用单独的 goroutine 来添加并发性 // 好：同步函数 - 调用者控制并发 func ProcessItems(items []Item) ([]Result, error) { var results []结果对于 _, item := 范围项 { 结果，错误：= processItem(item) 如果错误！= nil { 返回零，错误 } 结果=附加（结果，结果） } 返回结果，无 } // 如果需要，调用者可以添加并发：去函数（）{ 结果，err := ProcessItems(items) // 处理结果 }() > **咨询**：在调用方消除不必要的并发是相当困难的（有时是不可能的）。让调用者在需要时添加并发性。 ** ** ## 通道方向 > **规范**：尽可能指定通道方向。 ### 为什么要指定方向？ 1. **防止错误**：编译器捕获诸如关闭仅接收通道之类的错误 2. **传达所有权**：明确谁发送、谁接收 3. **自记录**：函数签名讲述故事 // 好：方向明确 - 所有权清晰 func sum(值 <-chan int) int { 总计:= 0 for v := 范围值 { 总计 += v } 返回总计 } // 不好：没有方向 - 允许意外误用 func sum(values chan int) (out int) { for v := 范围值 { 输出 += v } 关闭（值） // 错误！这可以编译，但不应该发生。 } ### 通道大小：一个或无通道的大小通常应为 1 或无缓冲。任何其他尺寸都必须接受审查。考虑： * 尺寸是如何确定的？ * 是什么阻止通道在负载下被填满？ * 当作者阻塞时会发生什么？ > **来源**：Uber Go 风格指南 // 不好：任意缓冲区大小 c := make(chan int, 64) // “对任何人来说都应该足够了！” // 好：有意调整大小 c := make(chan int, 1) // 1 的大小 c := make(chan int) // 无缓冲，大小为零 ### 常见模式 func Produce(out chan<- int) { /* 仅发送 */ } func Consumer(in <-chan int) { /* 仅接收 */ } func transform(in <-chan int, out chan<- int) { /* 两个方向 */ } ** ** ## 原子操作使用 [go.uber.org/atomic]() 进行类型安全的原子操作。标准的“sync/atomic”包对原始类型（“int32”、“int64”等）进行操作，因此很容易忘记一致地使用原子操作。 > **来源**：Uber Go 风格指南 // 不好：容易忘记原子操作类型 foo 结构 { 运行 int32 // 原子 } func (f *foo) 开始() { 如果atomic.SwapInt32(&f.running, 1) == 1 { return // 已经运行 } // 启动Foo } func (f *foo) isRunning() 布尔 { return f.running == 1 // 比赛！忘记了atomic.LoadInt32 } // 好：类型安全的原子操作类型 foo 结构 { 运行atomic.Bool } func (f *foo) 开始() { 如果 f.running.Swap(true) { return // 已经运行 } // 启动Foo } func (f *foo) isRunning() 布尔 { return f.running.Load() // 不会意外地以非原子方式读取 } `go.uber.org/atomic` 包通过隐藏底层类型来增加类型安全性，并包含方便的类型，如 `atomic.Bool`、`atomic.Int64` 等。 ** ** ## 记录并发性 > **建议** ：当操作类型不明显时，记录线程安全性。 Go 用户认为只读操作对于并发使用是安全的，而变异操作则不然。记录并发性： 1. **读取与变异尚不清楚** \- 例如，变异 LRU 状态的“查找” 2. **API提供同步** \- 例如，线程安全的客户端 3. **接口有并发要求** \-类型定义中的文档 ** ** ## 通道缓冲池使用缓冲通道作为空闲列表来重用分配的缓冲区。这种“泄漏缓冲区”模式使用“select”和“default”来实现非阻塞操作。请参阅 [references/BUFFER-POOLING.md]() 了解完整模式，以及使用 `sync.Pool` 的示例和生产替代方案。 ** ** ## 快速参考主题 |指导|类型 ---|---|--- Goroutine 生命周期 |明确退出条件 |规范性即发即忘 |不要这样做——总是有停止机制|规范性零值互斥体 |有效的;不要使用指针 |咨询互斥锁嵌入 |不要嵌入；使用命名字段|咨询同步功能|优于异步|规范性通道方向|始终指定 |规范性通道尺寸|默认情况下有一个或没有 |咨询原子操作 |使用 go.uber.org/atomic |咨询并发文档 |不明显时记录 |咨询 ### 并发检查表在生成 goroutine 之前，回答： * 这个goroutine将如何退出？ * 我可以示意它停止吗？ * 我可以等待它完成吗？ * 谁拥有其使用的渠道？ * 当上下文被取消时会发生什么？ * 这应该是一个同步函数吗？ ### 要避免的反模式反模式|问题 |修复 ---|---|--- 即发即忘 goroutine资源泄漏、未定义行为 |使用 WaitGroup、完成通道或上下文 init() 中的 Goroutine |生命周期不可控 |使用带有 Shutdown 方法的显式对象嵌入式互斥体 | API 泄露锁定/解锁 |使用名为“mu”字段指向互斥体的指针 |不必要的间接 |零值有效任意通道缓冲区 |隐藏的阻塞问题|默认为 0 或 1 原始同步/原子 |容易忘记的原子读取 |使用 go.uber.org/atomic 未记录的线程安全 |来电者可能会参加比赛|不清楚时记录 ** ** ## 另请参阅 * **go-style-core** ：基本风格原则（清晰、简单） * **go-error-handling** ：并发代码中的错误处理模式 * **go-defective** ：防御性编程，包括验证和安全 * **go-documentation** ：一般文档约定 ### 外部资源 * [永远不要在不知道 Goroutine 如何停止的情况下启动它]() * 戴夫·切尼 * [重新思考经典并发模式]() \- Bryan Mills (GopherCon 2018) * [Go 程序结束时]() \- Go Time 播客 * [go.uber.org/goleak]() \- 用于测试的 Goroutine 泄漏检测器 * [go.uber.org/atomic]() \- 类型安全的原子操作

Go并发

包含技能