本文详解 Go 中通过关闭 channel 实现多 goroutine 协同取消的正确模式，指出直接向无缓冲 channel 发送值导致死锁的根本原因，并提供线程安全、可重入的 Stopper 封装方案。
本文详解 go 中通过关闭 channel 实现多 goroutine 协同取消的正确模式，指出直接向无缓冲 channel 发送值导致死锁的根本原因，并提供线程安全、可重入的 `stopper` 封装方案。
在 Go 并发编程中，向未被接收的无缓冲 channel 发送值会永久阻塞当前 goroutine——这正是你程序挂起（hang）的根源。你的 failChannel 是一个无缓冲 int 类型 channel（如 make(chan int)），而发送端（failChannel <- 0）在没有任何 goroutine 正在 select 接收该值时，将无限等待，导致整个控制流卡死。
根本问题不在于“逻辑错误”，而在于 channel 语义误用：你本意是广播“停止信号”，却选择了需要配对收发的 消息通道，而非更轻量、更语义清晰的 完成信号通道。
✅ 正确做法：使用 chan struct{} + close()
struct{} 占用零内存，close(ch) 不会阻塞，且所有监听 <-ch 的 goroutine 会立即收到零值并退出（或进入 case <-ch: 分支）。更重要的是：关闭 channel 是广播操作，无需配对接收，天然支持任意数量的监听者。
// 创建取消信号通道（推荐方式）
failSignal := make(chan struct{})
// 在 worker goroutine 中监听（非阻塞检查）
for angle := 0.0; angle < 360; angle++ {
select {
case <-failSignal:
// 收到取消信号，立即退出循环
break loop
default:
log.Print(angle)
// 执行实际工作...
}
}// 在主逻辑中触发取消（安全！不阻塞） close(failSignal) // ✅ 关闭即广播，无需担心谁来接收
⚠️ 注意事项：
- ❌ 切勿多次 close(ch) —— 将 panic；
- ❌ 避免对已关闭 channel 再次发送（ch <- x）—— 同样 panic；
- ✅ close(ch) 后，所有 <-ch 操作立即返回零值（struct{} 的零值即本身），且 ok 值为 false，可安全用于判断。
为彻底规避重复关闭风险，建议封装成线程安全的 Stopper：
import "sync"
type Stopper struct {
C chan struct{}
once sync.Once
}
func NewStopper() *Stopper {
return &Stopper{C: make(chan struct{})}
}
func (s *Stopper) Stop() {
s.once.Do(func() { close(s.C) })
}
// 使用示例
stopper := NewStopper()
go func() {
for {
select {
case <-stopper.C:
return // 优雅退出
default:
// 工作逻辑...
}
}
}()
// ...后续某处调用
stopper.Stop() // 安全，可多次调用总结：在 Go 中实现取消/停止信号，应优先选择 关闭 chan struct{} 而非向普通 channel 发送值。它简洁、高效、无竞争、符合 Go 的并发哲学。你的性能瓶颈（大量冗余 goroutine）本质是取消机制失效所致，修复 channel 信号模式后，配合合理的工作分发（如 context.WithCancel 或 errgroup），即可实现高响应、低开销的并发控制。
