golang协程数量限制与死锁避免
在go语言编程中，限制并发协程数量是常见需求，但稍有不慎就会导致死锁（fatal Error: all goroutines are asleep – deadlock!）。本文探讨如何安全地限制协程数量，避免死锁。
问题描述
使用sync.WaitGroup管理协程生命周期，并通过通道限制并发协程数，可能出现死锁。 问题源于协程间数据传输和协程数量控制机制的冲突。
代码示例及问题分析
以下代码片段展示了可能导致死锁的场景：
package main import ( "fmt" "log" "math/rand" "sync" "time" ) // ... (Row, Report, Bag 结构体定义，与原文相同) ... func GetRows() (rows []Row) { // ... (GetRows 函数实现，与原文相同) ... } func processRow(row Row, c chan struct{}, creport chan Bag) { defer func() { <-c // 释放协程槽位 }() // ... (处理row逻辑，产生Bag数据，与原文相同) ... creport <- bag // 发送报告结果 } func main() { c := make(chan struct{}, 10) // 限制同时运行的协程数量为10 creport := make(chan Bag) var wg sync.WaitGroup rows := GetRows() for _, row := range rows { c <- struct{}{} // 获取协程槽位 wg.Add(1) go func(row Row) { defer wg.Done() processRow(row, c, creport) }(row) } // 以下循环会导致死锁 //go func() { // for bag := range creport { // fmt.Println(bag) // } //}(creport) wg.Wait() // 等待所有协程完成 close(creport) // 关闭creport通道，避免死锁 //处理creport中的数据 for bag := range creport { fmt.Println(bag) } }
原代码中defer close(creport)和主协程中的死循环接收creport通道数据是导致死锁的关键。
立即学习“go语言免费学习笔记（深入）”；
解决方案
为了避免死锁，需要进行如下修改：
-
移除defer close(creport): 在原代码中，creport通道的关闭操作永远无法执行到。
-
移除主协程中的循环接收: 主协程中的循环接收creport与子协程的功能重复，且是死循环，导致creport关闭后仍然尝试读取，从而死锁。
-
在wg.Wait()之后关闭creport: 确保所有协程完成后再关闭creport通道，避免死锁。
修改后的代码如下：
// ... (其它代码与前面相同) ... func main() { // ... (其它代码与前面相同) ... wg.Wait() // 等待所有协程完成 close(creport) // 在wg.Wait()之后关闭creport通道 // 处理creport中的数据 for bag := range creport { fmt.Println(bag) } }
通过这些修改，既能限制协程数量，又能避免死锁，确保程序的正确运行。 关键在于正确地管理协程生命周期和通道的关闭时机。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
