在go语言并发编程中，限制协程数量以避免资源耗尽至关重要。然而，不当的协程控制和数据传递方式可能导致死锁。本文将分析一个使用sync.WaitGroup和通道进行协程数量限制和数据传递的案例，并提出解决方案，避免fatal Error: all goroutines are asleep – deadlock!错误。
问题描述
示例代码使用一个通道c限制并发协程数，另一个通道creport用于收集协程结果。由于不恰当的通道关闭和数据读取方式，导致死锁。
立即学习“go语言免费学习笔记（深入）”；
问题代码分析与改进
原始代码中存在两个主要问题：
-
defer close(creport) 的错误放置: defer close(creport)语句在主函数中，但由于主循环持续读取creport通道，该语句永远无法执行，导致creport通道无法关闭，从而阻塞协程。
-
重复的读取操作: 主函数和子协程都试图从creport通道读取数据，造成资源竞争和死锁风险。
为了解决这些问题，我们进行如下修改：
-
移除defer close(creport): 将creport通道的关闭操作移至wg.Wait()之后，确保所有协程都已完成任务。
-
优化主函数数据接收: 移除主函数中重复的creport通道读取操作，改为在wg.Wait()之后处理结果。
-
清晰的错误处理: 在select语句中添加ok判断，处理通道关闭情况，避免panic。
改进后的代码 (示例，需根据实际代码调整):
package main import ( "fmt" "log" "math/rand" "sync" "time" ) // ... (省略部分代码，假设Bag类型已定义) func main() { // ... (省略部分代码) var ( cLimit = 3 // 协程限制数量 wg = sync.WaitGroup{} ) c := make(chan int, cLimit) c2 := make(chan int, 10) cReport := make(chan Bag, 100) defer close(c) // 保持原有c通道的关闭 // 启动工作协程 for i := 0; i < 10; i++ { wg.Add(1) go func(i int) { defer wg.Done() c <- 1 // 获取执行许可 defer func() { <-c }() // 释放执行许可 // ... (协程工作逻辑，并将结果发送到cReport) cReport <- Bag{data: fmt.Sprintf("Result %d", i)} }(i) } wg.Wait() // 等待所有协程完成 close(cReport) // 在所有协程结束后关闭cReport通道 // 处理结果 for result := range cReport { fmt.Println("Received:", result.data) } log.Println("All goroutines finished.") }
通过以上改进，我们有效地避免了死锁，并确保了协程的正确管理和数据处理。 记住，在并发编程中，仔细考虑通道的关闭时机和避免资源竞争至关重要。 根据实际业务逻辑调整代码，确保所有通道在所有协程结束后再关闭。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
