Go channel 缓冲区满了怎么判断发送会阻塞

如果你在生产者代码里看到发送语句偶尔停住，先不要把原因归咎于 goroutine 调度。Go 规范给出的判断很直接：无缓冲 channel 要等接收者就绪，有缓冲 channel 要等缓冲区出现空位；如果只是想“现在能发就发，不能发就放弃”，应该用 select 配合 default。

本文只讨论发送阻塞条件和非阻塞写法，不展开 channel 关闭通知与调度器内部实现。示例是静态说明，代码块中的注释解释了关键边界。

先分清四种 channel 发送边界

判断发送是否等待，要先看 channel 的状态。nil channel 的发送会永久阻塞；无缓冲 channel 没有存放位置，只有接收端同时准备好才能继续；有缓冲 channel 在 len(ch) 时通常有空位，缓冲区满了就要等接收者取走数据；已关闭 channel 则不能继续发送，发送会触发运行时 panic。

这里的“通常”是为了强调并发语境：len(ch) 只是某个时刻的快照，不是发送许可。另一个 goroutine 可能在你读取长度之后立刻发送或接收，所以它适合观察和记录，不适合单独做同步决策。

用 len 和 cap 理解“缓冲区满了”

有缓冲 channel 的 cap(ch) 是创建时确定的容量，len(ch) 表示当前尚未被接收的元素数量。两者相等时，可以把它理解为当前没有空位，但这并不意味着生产者必须永久等待：只要接收端消费一个元素，后续发送就可能继续。

package main

import "fmt"

func main() {
	jobs := make(chan int, 2) // 中文注释：创建容量为 2 的有缓冲 channel
	jobs 

这个观察方式适合日志、指标和排查。真正决定发送能否继续的仍是 channel 通信本身：阻塞发送会等待条件成立，而不是根据你提前读到的 len 值做承诺。

用 select 实现一次“能发就发”

如果当前业务允许丢弃、降级或稍后重试，可以把发送放进 select。发送分支能够立即进行时，代码进入该分支；否则因为存在 default，不会等待缓冲区变空。

func trySend(jobs chan

这个写法不是“让 channel 永远不满”，而是把等待策略交给业务。队列必须保证每个任务最终处理时，应使用普通发送并配合取消信号；遥测、刷新通知等允许合并或丢弃的消息，才适合尝试非阻塞发送。

工程里最容易踩的三个坑

第一，不要用读取 len(ch) 后再发送来“证明”发送不会阻塞，这个判断和实际发送之间存在并发窗口。第二，不要为了避免阻塞就把所有发送都改成 default，否则业务任务可能悄悄丢失。第三，阻塞发送要有退出条件，例如把发送和取消信号放在同一个 select 中，让上游停止后能够释放等待中的 goroutine。

可以按下面的速查表做选择：

相关问题

无缓冲 channel 为什么更容易让发送停住？因为它没有缓冲空位，发送必须和已经准备好的接收操作匹配。

有缓冲 channel 满了会丢数据吗？普通发送不会自动丢数据，而是等待空位；使用 default 的非阻塞写法才会由业务代码决定放弃或重试。

应该用 len(channel) 判断是否安全发送吗？不应该把它当作并发同步条件。它可以帮助记录积压量，发送是否可行应交给通信操作或 select。