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)
}
}
通过这些修改，既能限制协程数量，又能避免死锁，确保程序的正确运行。 关键在于正确地管理协程生命周期和通道的关闭时机。
