如何优雅地同步终止两个相互依赖的 Goroutine

本文介绍在 go 中通过共享退出通道（quit channel）协调多个 goroutine 生命周期的方法，确保任一 goroutine 异常或正常退出时，其他相关 goroutine 能立即响应并安全退出，避免资源泄漏和 goroutine 泄漏。

在 WebSocket 服务等并发场景中，常见模式是为每个连接启动一对协作的 Goroutine：一个负责读取客户端消息（readFromSocket），另一个负责向客户端写入消息（writeToSocket）。理想情况下，二者应“同生共死”——任一因错误、断连或主动关闭而退出时，另一个也应立即停止，而非继续阻塞在 channel 操作或网络调用上。

原始代码的问题在于：writeToSocket 使用 for m := range p.writeChan 监听写通道，该循环仅在 p.writeChan 被显式关闭后才自然退出；而 readFromSocket 是无缓冲的 for {} 循环，依赖 ReadJSON 错误触发 break。一旦 readFromSocket 先退出并调用 p.cleanup()，它会 close(p.writeChan)，但此时 writeToSocket 的 range 循环虽能感知通道关闭并退出，却无法及时中断正在执行的 p.conn.WriteJSON(m) 调用（尤其当连接卡住或慢速时），导致 Goroutine 卡死。更严重的是，若 writeToSocket 先因写失败退出，readFromSocket 仍无限循环，形成孤儿 Goroutine。

✅ 正确解法是引入统一的退出信号通道（quit chan struct{}），所有协作 Goroutine 均通过 select 监听该通道，实现即时响应：

func (p *Player) EventLoop() {
    l4g.Info("Starting player %s event loop", p)
    quit := make(chan struct{}) // 共享退出信号
    go p.readFromSocket(quit)
    go p.writeToSocket(quit)

    <-p.closeEventChan // 等待首个 Goroutine 通知退出
    close(quit)        // 广播退出信号给所有协作者
    <-p.closeEventChan // 等待第二个 Goroutine 完成清理（此处为 2 个，可扩展）
    p.cleanup()
}

func (p *Player) writeToSocket(quit <-chan struct{}) {
    defer func() { p.closeEventChan <- true }() // 统一退出通知
    for {
        select {
        case <-quit:
            return // 收到退出信号，立即返回
        case m, ok := <-p.writeChan:
            if !ok {
                return // writeChan 已关闭
            }
            if p.conn == nil {
                return
            }
            if reflect.DeepEqual(network.Packet{}, m) {
                return
            }
            if err := p.conn.WriteJSON(m); err != nil {
                return // 写入失败，主动退出
            }
        }
    }
}

func (p *Player) readFromSocket(quit <-chan struct{}) {
    defer func() { p.closeEventChan <- true }()
    for {
        select {
        case <-quit:
            return // 关键：随时响应退出指令
        default:
            if p.conn == nil {
                return
            }
            var m network.Packet
            if err := p.conn.ReadJSON(&m); err != nil {
                return // 读取失败（如断连、超时），退出
            }
            // 处理消息逻辑...
        }
    }
}

? 关键设计要点：

• quit 通道为 struct{} 类型：零内存开销，close(quit) 后所有
• select + default 或纯 ：避免 Goroutine 在 channel 操作上永久阻塞；default 可用于非阻塞探测（如检查连接状态），但本例中直接监听 quit 更简洁可靠。
• defer 统一通知机制：确保无论何种路径退出，均向 p.closeEventChan 发送信号，便于主流程计数与同步。
• close(quit) 的时机：必须在首个 Goroutine 退出后、执行 cleanup 前调用，以保证剩余 Goroutine 能收到信号并快速终止。

⚠️ 注意事项：

• 不要依赖 close(p.writeChan) 触发 writeToSocket 退出——它只影响 range 循环，无法中断正在进行的阻塞 I/O（如 WriteJSON）。quit 通道才是真正的“紧急制动”。
• 若存在更多协作 Goroutine（如心跳、日志上报），只需统一监听同一 quit 通道，并在 EventLoop 中增加对应
• 对于网络连接，建议设置 SetReadDeadline / SetWriteDeadline 配合 quit 通道，进一步防止底层 syscall 长时间挂起。

通过这种“中心化信号分发 + 协作式监听”的模式，可构建健壮、可预测的 Goroutine 生命周期管理，是 Go 并发编程中处理协同退出的标准实践。