Go无缓冲通道实战解析

无缓冲通道是 Go 中实现 goroutine 间同步通信的核心机制，它不存储数据，仅作为“接力交接点”，要求发送与接收操作必须严格配对且跨 goroutine 才能完成——任一方单独执行都会永久阻塞，同一 goroutine 内收发则必然触发死锁（fatal error: all goroutines are asleep - deadlock），理解其“双向等待、跨协程协作”的阻塞本质，是写出健壮并发代码的关键门槛。

无缓冲 channel 的阻塞行为怎么判断？

Go 里 make(chan int) 创建的就是无缓冲 channel，它不存数据，只做“接力交接”——发送方必须等到有接收方在等，才会继续执行。反过来也一样：接收方会卡住，直到有人往里发。

常见错误现象：fatal error: all goroutines are asleep - deadlock
这基本就是你写了 ch <- 1 或 <-ch，但另一端没人配合，程序直接死锁。

使用场景：

• 需要严格同步两个 goroutine 的执行节奏（比如“等 A 完成后再启动 B”）
• 实现信号通知（如 done := make(chan struct{})，只用来关闭，不传数据）
• 避免竞态时做简单协调（比 mutex 更轻量，但适用范围窄）

注意：无缓冲 channel 的容量是 0，cap(ch) 返回 0，len(ch) 永远是 0 —— 别想用 len 判断“有没有人等着”，它没意义。

为什么不能在同一个 goroutine 里 send 和 receive？

因为无缓冲 channel 的收发必须跨 goroutine 才能完成。写成这样必死锁：

ch := make(chan int)
ch <p>正确做法永远是至少一方跑在另一个 goroutine：</p>

• 发送放 goroutine 里：go func() { ch
• 接收放主 goroutine：<-ch
• 或者反过来，只要不写在同一执行流里

容易踩的坑：误以为 select + default 能绕过阻塞 —— 其实不能。select 对无缓冲 channel 的 case 依然要等配对操作，default 只是让 select 不阻塞，不代表 channel 本身不阻塞。

和有缓冲 channel 在性能/语义上差在哪？

无缓冲 channel 是同步原语，每次收发都涉及 goroutine 切换（唤醒+调度），本质是“握手协议”。有缓冲的（比如 make(chan int, 1)）则可能直接拷贝进缓冲区，不触发调度。

所以：

• 如果你只是想“丢个消息就走”，别用无缓冲 —— 容易卡住调用方，也拖慢吞吐
• 如果你需要确保“对方真的收到了”，才用无缓冲；否则用带缓冲的更稳
• 缓冲大小为 1 时，len(ch) 可能是 0 或 1，cap(ch) 是 1；无缓冲时二者都是 0，这是最直接的区分方式

另外，无缓冲 channel 无法被 close 后再读取（会 panic：`panic: send on closed channel` 或 `deadlock`），而有缓冲的 close 后还能读完剩余数据 —— 这点常被忽略。

如何安全地关闭无缓冲 channel？

无缓冲 channel 一般不该被 close，除非你明确只用它做“单次通知”。例如：

done := make(chan struct{})
go func() {
    defer close(done)  // 通知完成
    heavyWork()
}()
<-done  // 等它关掉

但要注意：

• 不能对无缓冲 channel 多次 close，会 panic：panic: close of closed channel
• 不能在发送端 close 后还试图 ch ，同样 panic
• 如果 channel 可能被多个 goroutine 写，得用 sync.Once 或额外标志位控制 close，不能靠 channel 自身保证线程安全

真正难处理的是“双向等待”场景：比如两个 goroutine 都要等对方先发再回，又都不肯先动 —— 这时候无缓冲 channel 会立刻死锁，得靠超时、select + time.After 或改用其他同步机制。

理论要掌握，实操不能落！以上关于《Go无缓冲通道实战解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！