本文详解 go 中无缓冲通道的阻塞机制，指出 chin
在 Go 并发编程中，通道（channel）是 Goroutine 间通信的核心原语，但其行为常被误解——尤其是“非阻塞”这一概念。问题中的代码看似逻辑清晰：主协程向 chin 发送数据，5 个 worker 并发消费，结果写入 chout 后由主协程批量更新数据库。然而程序卡在 chin
? 根本原因：无缓冲通道的同步语义
Go 的无缓冲通道（unbuffered channel）本质是同步队列：
- 发送操作 chin 必须等待至少一个接收方就绪（即另一个 Goroutine 正在执行
- 接收操作
你创建了全局无缓冲通道：
var chin = make(chan in) // ❌ 无缓冲 → 同步阻塞 var chout = make(chan out)
尽管已启动 go worker()，但 worker() 内部使用 for res := range chin —— 该循环仅在通道被关闭后才退出，而 range 本身在首次执行时会阻塞等待第一个值到达。若此时主协程尚未开始发送，worker 协程将全部卡在 range 的初始等待上，导致无人接收，进而使主协程的 chin
这就是“5 次后阻塞”的真相：你的 worker 协程并未真正进入循环体处理数据，它们全在 range 的入口处等待首个值；而 Go 调度器不保证 go worker() 启动后立即抢占执行权，主协程可能抢先执行完所有发送，却因无人接收而阻塞。
✅ 正确解法：分离发送/接收生命周期 + 显式控制通道关闭
要实现“主协程不阻塞地完成发送”，关键在于：让接收侧完全异步化，并明确告知何时停止。以下是推荐的重构方案：
1. 启动消费者 Goroutine，异步处理 chout
避免主协程在 for res := range chout 中同步等待，改为启动独立 Goroutine 处理结果：
// 启动结果处理器（异步）
go func() {
for res := range chout {
if err := update5.Exec(res.data, res.id); err != nil {
log.Printf("update failed: %v", err)
}
}
}()2. 发送完成后，显式关闭输入通道 chin
通知所有 worker 停止读取（range 遇到关闭的通道会自动退出）：
// ... 在 rows.Next() 循环结束后 ... rows.Close() close(chin) // ✅ 关键：告诉 workers "不再有新任务"
3. （可选但强烈推荐）为通道添加合理缓冲
缓解瞬时压力，避免因调度延迟导致的假性阻塞：
const workerCount = 5 var chin = make(chan in, workerCount*2) // 缓冲区大小 = 工作协程数 × 安全倍数 var chout = make(chan out, workerCount*2)
缓冲区大小不必过大（如 100），通常 workerCount × 2 ~ × 10 即可平衡内存与吞吐。
4. 完整工作流示例
func main() {
// 初始化带缓冲通道
chin := make(chan in, 10)
chout := make(chan out, 10)
// 启动 worker 池
for i := 0; i < 5; i++ {
go worker(chin, chout)
}
// 启动异步结果处理器
go func() {
for res := range chout {
if err := update5.Exec(res.data, res.id); err != nil {
log.Printf("DB update error: %v", err)
}
}
}()
// 主协程：加载并发送任务
rows, err := nextbatch2.Query()
if err != nil {
panic(err)
}
defer rows.Close()
for rows.Next() {
var id int
var data string
if err := rows.Scan(&id, &data); err != nil {
panic(err)
}
chin <- in{ID: id, Data: data} // ✅ 不再阻塞（有缓冲 + 接收者已就绪）
}
close(chin) // ✅ 所有任务发送完毕，关闭输入通道
// 等待所有结果处理完成（可选：如需确保 DB 更新结束）
// 实际中建议用 sync.WaitGroup 或 context 控制超时
}func worker(inCh <-chan in, outCh chan<- out) {
for task := range inCh { // ✅ range 自动退出当 inCh 关闭
result := out{
ID: task.ID,
Data: process(task.Data),
}
outCh <- result // ✅ 有缓冲，几乎不阻塞
}
}⚠️ 注意事项与最佳实践
- 永远不要对未关闭的无缓冲通道使用 range：它会导致 Goroutine 永久等待；
- 关闭通道的责任应单一：通常由发送方（主协程）在发送完毕后关闭，接收方绝不关闭；
- 检查 rows.Next() 返回值：确保循环正确终止，避免漏掉最后一行；
- 错误处理需健壮：数据库操作失败时应记录日志而非 panic，避免整个程序崩溃；
- 考虑上下文（context）：生产环境建议传入 context.Context 到 worker 和 update5.Exec，支持超时与取消；
- 监控通道状态：可通过 len(ch) 和 cap(ch) 辅助调试，但勿依赖其做业务逻辑判断。
通过以上改造，你的管道模型将具备确定性、可终止性和高吞吐特性——主协程专注生产，worker 专注计算，结果处理器专注持久化，三者解耦运行，彻底告别“发送即阻塞”的陷阱。
