本文解析 go 语言中 goroutine 和 channel 的生命周期关系，重点说明无缓冲通道可能导致 goroutine 泄漏，而适当设置缓冲区可确保资源被垃圾回收器安全回收。
本文解析 go 语言中 goroutine 和 channel 的生命周期关系，重点说明无缓冲通道可能导致 goroutine 泄漏，而适当设置缓冲区可确保资源被垃圾回收器安全回收。
在 Go 中，goroutine 和 channel 的垃圾回收并非“捆绑”进行，而是各自遵循独立的可达性规则：只要没有活跃引用指向它们，且它们不再能执行或通信，就会被 GC 回收。但关键在于——goroutine 是否能自然终止，这直接决定了它能否被回收。
以原始示例为例：
func waitForOneOfTwoProcesses() {
c := make(chan bool) // 无缓冲通道
go func() {
time.Sleep(1 * time.Second)
c <- true // 阻塞等待接收者
}()
go func() {
time.Sleep(2 * time.Second)
c <- true // 同样阻塞
}()
<-c // 仅接收一个值
}此处 c 是无缓冲通道，发送操作 <- c 是同步阻塞的。主 goroutine 仅从 c 接收一次，因此两个匿名 goroutine 中只有一个能成功发送并退出，另一个将永远阻塞在 c <- true 上，无法结束。该 goroutine 及其持有的栈、闭包变量（包括对 c 的引用）将持续存在——构成典型的 goroutine 泄漏。即使 c 在函数作用域结束后“不可达”，只要仍有 goroutine 在等待向它发送，GC 就不能回收该 channel（因为它是阻塞发送的必要上下文），进而也无法回收该 goroutine。
✅ 正确解法：使用带缓冲的 channel
只需将 make(chan bool) 改为 make(chan bool, 1)（缓冲大小 ≥1 即可）：
func waitForOneOfTwoProcessesFixed() {
c := make(chan bool, 1) // 缓冲容量为 1
go func() {
time.Sleep(1 * time.Second)
c <- true // 立即返回（缓冲区有空位）
}()
go func() {
time.Sleep(2 * time.Second)
c <- true // 同样立即返回
}()
<-c // 接收第一个到达的值
// 函数返回后，c 被回收；两个 goroutine 已执行完毕，栈和闭包均无引用，可被 GC 清理
}此时，两次发送均非阻塞（缓冲区足够容纳至少一个值），两个 goroutine 均能顺利执行完并退出。函数返回后，局部变量 c 失去所有引用，channel 对象变为不可达；两个已终止的 goroutine 不再持有任何有效栈帧或闭包引用，其内存将随下一轮 GC 被安全回收。
⚠️ 注意事项：
- 缓冲大小必须 ≥ 发送端数量中「可能未被接收」的最大值。本例中最多 2 次发送、仅 1 次接收，故缓冲 1 即可（第 2 次发送写入缓冲区后立即返回）。
- 若缓冲大小为 0（即无缓冲）或小于未接收的发送次数，就存在阻塞风险。
- 不要依赖 runtime.GC() 强制回收——Go 的 GC 是自动、异步且基于可达性的，唯一可靠方式是确保 goroutine 正常终止、channel 不再被引用。
- 更健壮的做法是结合 context 或 select + default 避免永久阻塞，例如超时控制或取消信号。
总结：Go 不会“主动识别 channel 已失效而唤醒阻塞 goroutine”。goroutine 的退出完全取决于其自身逻辑是否执行完毕。通道缓冲区是解耦发送与接收的关键设计——它让发送方不必等待接收方，从而保障 goroutine 可终止，最终使 GC 能正确回收全部资源。
