Go语言超时处理与通道监听的阻塞问题解决方法问询

嘿，你遇到的这个问题在Go并发编程里挺常见的——就是当你给一个已经没有接收者的通道发消息时，会陷入永久阻塞，再加上锁的位置没处理好，还容易触发死锁。我来给你拆解几个通用的解决思路：

1. 非阻塞发送（首推方案） #

给通道发消息时，用select配合default分支就能实现非阻塞发送。如果这时候通道已经没有接收者了（比如goroutine 1已经超时退出），发送操作会立刻跳到default分支，完全不会卡住。

把goroutine 2的发送逻辑改成这样就行：

mu.Lock()
msgCh, ok := msgChMap[index]
delete(msgChMap, index)
mu.Unlock()
if ok {
    select {
    case msgCh <- "yay":
        // 消息成功送到接收者手里
    default:
        // 没人收消息，直接放弃，绝不阻塞
    }
}

这么做的好处很明显：

• 从根源上解决了发送阻塞的问题
• 锁的逻辑保持原样，不会触发死锁
• 完全贴合Go的并发设计思路，简单易懂

2. 用带缓冲的通道兜底 #

如果你的场景里每个通道最多只发一次消息，可以创建一个大小为1的缓冲通道。这样就算接收者已经退出，消息也能先存在缓冲里，发送操作不会阻塞（后续没人取的话，缓冲里的消息会被GC自动回收）。

创建通道的时候改一下：

msgChMap[index] = make(chan string, 1)

goroutine 2的发送逻辑不用改，直接msgCh <- "yay"就行。

不过要注意，这个方法只适合发送次数不超过缓冲大小的场景，如果之后可能多次发消息，还是会有阻塞风险，所以通用性不如非阻塞发送。

3. 别用len/cap判断通道状态（踩坑提醒） #

有些同学可能会想着用len(msgCh)或者cap(msgCh)来判断有没有接收者，这俩方法根本不靠谱：

• len(msgCh)只能看到当前缓冲里的消息数，完全没法知道有没有goroutine在监听通道
• 无缓冲通道的len永远是0，啥信息都给不了你

所以这种思路直接pass，别浪费时间试。

为啥锁不能移到发送之后？ #

你之前说把锁移到发送之后会引发死锁，这个判断太对了：goroutine 2拿着锁卡在发送操作上，goroutine 1超时后又要拿锁删map，俩goroutine互相等，直接死锁。所以必须保持拿到通道、删完map就立刻释放锁的逻辑，绝对不能拿着锁做发送这种可能卡住的操作。

总的来说，非阻塞发送是解决这类问题最通用、最安全的模式，既能避免发送阻塞，又不会碰死锁的坑。

内容的提问来源于stack exchange，提问作者Ringil