Go未关闭通道导致协程阻塞的解决方法

Go中未关闭通道会导致for range无限阻塞，使程序挂起、关键逻辑无法执行；根本原因在于range仅在通道关闭后才退出循环，而实际场景中常因遗漏close()或误判goroutine完成时机引发此问题，正确解法是显式控制接收次数或确保发送方及时关闭通道，从而保障并发流程的确定性和可终止性。

Go中对未关闭的无缓冲或带缓冲通道使用for range会永久阻塞，需明确限制接收次数或关闭通道以避免程序挂起。

在您提供的 Go 程序中，主 goroutine 使用 `for i := range ch` 从通道读取结果，但该通道从未被关闭。由于 `range` 语义规定：**只有当通道被显式关闭后，循环才会自然退出**；否则，它将持续等待更多值（即使所有 goroutine 已发送完毕），最终导致程序永远挂起——这正是 `"Im done"` 无法打印的根本原因。

正确做法：控制接收数量或关闭通道

最直接且推荐的方式是按预期消息数量循环接收，而非依赖 range：

// ✅ 推荐：明确接收 len(urls) 次
for i := 0; i < len(urls); i++ {
    resp := <-ch
    fmt.Println(resp)
}
fmt.Println("Im done")

此方式无需关闭通道，逻辑清晰、安全可靠，尤其适用于已知并发任务总数的场景（如本例中的 3 个 URL 请求）。

补充：若需使用 for range，务必关闭通道

若坚持使用 for range ch，则必须确保所有发送者完成发送后，由某一方（通常是主 goroutine）调用 close(ch)。注意：关闭操作只能执行一次，且应在所有 go asyncHttpGets(...) 启动后、接收前进行——但需配合同步机制（如 sync.WaitGroup）保证所有 goroutine 已结束发送：

import "sync"

func main() {
    fmt.Println("start")
    ch := make(chan *HttpResponse, len(urls))
    var wg sync.WaitGroup

    for _, url := range urls {
        wg.Add(1)
        go func(u string) {
            defer wg.Done()
            asyncHttpGets(u, ch)
        }(url)
    }

    // 启动 goroutine 在所有任务完成后关闭通道
    go func() {
        wg.Wait()
        close(ch) // ✅ 关键：通知 range 循环终止
    }()

    for resp := range ch { // 现在 safe
        fmt.Println(resp)
    }
    fmt.Println("Im done")
}

注意事项

• ❌ 不要在发送 goroutine 内部 close(ch) —— 多个 goroutine 同时关闭会 panic；
• ⚠️ 通道关闭后不可再发送，否则 panic；但可继续接收（已缓存值 + 零值）；
• ? 若存在错误处理（如 HTTP 请求失败），仍需确保每个 goroutine 都向通道发送（哪怕发送错误状态），否则主 goroutine 可能因收不到足够消息而卡住；
• ? 在 Go Playground 中，HTTP 请求被禁用，实际运行需本地环境；建议添加超时控制（如 http.Client{Timeout: 5 * time.Second}）提升健壮性。

通过明确接收边界或正确关闭通道，即可彻底解决此类“程序挂起”问题，写出更可靠、可预测的并发 Go 代码。

到这里，我们也就讲完了《Go未关闭通道导致协程阻塞的解决方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！