Go 中缓冲与非缓冲通道的行为差异及死锁成因深度解析-Golang-PHP中文网

Go 中缓冲与非缓冲通道的行为差异及死锁成因深度解析

本文详解 Go 语言中非缓冲通道导致死锁的典型场景，揭示 select 语句在通道就绪性判断中的确定性行为，并通过缓冲区容量变化（0/1/2+）对比分析 goroutine 协作机制与阻塞模型的本质差异。

本文详解 go 语言中非缓冲通道导致死锁的典型场景，揭示 `select` 语句在通道就绪性判断中的确定性行为，并通过缓冲区容量变化（0/1/2+）对比分析 goroutine 协作机制与阻塞模型的本质差异。

在 Go 并发编程中，通道（channel）是 goroutine 间通信的核心原语，而其是否带缓冲（buffered vs. unbuffered）会从根本上改变程序的执行流与阻塞行为。上述示例代码看似简单，却精准暴露了初学者常忽略的关键细节：非缓冲通道的发送操作必须与接收操作同步完成，否则立即阻塞；而 select 的“随机选择”仅作用于所有已就绪的 case，绝非无条件随机。

? 非缓冲通道（`make(chan string)`）为何必然死锁？

我们逐行还原执行逻辑：

主 goroutine 启动 test() 后，立即执行 ch1 —— 此时 ch1 是非缓冲通道，无 goroutine 在 select 中等待接收 ch1，因此该操作永久阻塞；
但注意：test() 已启动，其 select 循环会立刻尝试接收 —— 然而 ch1 尚未有值，ch2 也为空，两个 case 均不就绪；
此时 select 唯一可执行的是 case （2秒后触发），但主 goroutine 仍卡在 ch1 上，整个程序只有两个 goroutine：主 goroutine（阻塞）和 test goroutine（在 select 中空转等待超时）；
当 timeout 触发，test 返回并打印 "returning"，但主 goroutine 仍在阻塞发送，且无其他 goroutine 活跃 → Go 运行时检测到 "all goroutines are asleep"，抛出 fatal deadlock。

⚠️ 关键澄清：select 的“随机性”仅在多个 同时就绪 的 channel 操作间生效。本例中，ch1 先执行，使 ch1 产生一个待接收值；test 的 select 下一轮循环中，就绪而不就绪，因此 100% 选中 ch1 分支 —— 这不是随机，而是确定性就绪选择。若交换 ch1 和 ch2 ，则 ch2 先就绪，自然总是打印 "bye 2"。

? 缓冲区大小为 1：看似“工作”，实则隐含风险

ch1 := make(chan string, 1) // 可暂存 1 个值
ch2 := make(chan string, 1)

此时：

ch1 和 ch2 均能立即成功（缓冲区空，可写入）；
test() 的 select 启动后，ch1 和 ch2 均有值，两个 case 同时就绪 → select 真正随机选择其一（如 "hi 1" 或 "bye 2"）；
但问题在于：被选中的分支执行后（例如 "hi 1"），会执行 ch2 —— 此时 ch2 缓冲区已有一个 "bye"，再写 "ch2" 会导致阻塞（缓冲区满）；
另一分支同理。最终 test goroutine 在某次发送时永久阻塞，主 goroutine 等待 Scanln()，程序挂起。

✅ 结论：缓冲区为 1 仅避免了初始发送阻塞，但无法支撑双向持续通信，单次交互后即陷入僵局。

✅ 缓冲区 ≥ 2：实现稳定双向流水线

ch1 := make(chan string, 2)
ch2 := make(chan string, 2)

此时：

初始 ch1 和 ch2 均成功；
test 的 select 随机选一分支（如 ch1），输出 "hi 1"，然后 ch2 —— ch2 原有 "bye"，现写入 "ch2"，缓冲区占用 2/2，仍可容纳后续值吗？不！但关键在于：test 下一轮 select 会先尝试从 ch2 接收；
ch2 有 "bye" 和 "ch2" 两个值， 成功读取 "bye"，输出 "bye 2"，再执行 ch1 （ch1 此时为空，写入成功）；
如此形成闭环：ch1 和 ch2 缓冲区始终维持“一读一写”的平衡，只要超时未触发，即可持续交替运行。