使用 select 时如何避免死锁和无提示错误？

在IT行业这个发展更新速度很快的行业，只有不停止的学习，才不会被行业所淘汰。如果你是Golang学习者，那么本文《使用 select 时如何避免死锁和无提示错误？》就很适合你！本篇内容主要包括##content_title##，希望对大家的知识积累有所帮助，助力实战开发！

我正在通过示例学习 go。我刚刚实现了一个选择来等待多个通道，如下所示：

for i := 0; i < 2; i++ {
        select {
        case msg1 := <-c1:
            fmt.Println("received", msg1)
        case msg2 := <-c2:
            fmt.Println("received", msg2)
        }
    }

通过一些实验，我发现我可以天真地引入运行时错误，如下所示：

• 如果我将 i 减少到 1，则会收到第一条消息，但第二条消息会默默丢失（没有迹象表明我无意中忽略了它）。

• 如果我将 i 增加到 3，两条消息都会收到，但我收到 fatal 错误：所有 goroutine 都在睡眠 - 死锁！

继续阅读并在 stackoverflow 上搜索该错误消息，我可以看到 waitgroups 解决了这些类型的问题。但它们似乎不适用于 select，所以我觉得我一定错过了一些东西。

是否有一种语言构造（如 if/then/else）或软件模式可以用来防止或减轻实际代码中的这些错误？

正确答案

从概念上讲，您可以通过正确设计软件来缓解这种情况。如果您有两个频道，并且每个频道最多接收一条消息，请不要尝试从其中读取 3 次。这与尝试将三个项目放入一个二元素数组中，或者尝试除除数为 0 的两个数字没有什么不同。在所有这些情况下，语言都提供了发现错误并从错误中恢复的方法，但如果您实际上正在生成错误这些错误表明存在逻辑或设计缺陷。

您需要确保您的通道具有平衡的读取和写入数量，并且发送端在没有其他内容可发送时关闭通道，以便接收方可以停止等待不会到来的消息。否则，您最终会遇到一些等待的问题，或者缓冲区中的消息被忽略。

在这个非常具体的情况下，如果您想从两个通道读取但仅当消息准备就绪时，您可以添加一个 default 情况，如果没有通道可供读取，则将调用该情况，但这适用于您的通道尚未准备好，但最终会准备好。提供 default 并不是一个很好的解决方案来覆盖错误，因为通道永远不会准备好，但您仍然试图从中读取数据；这表明存在需要修复的逻辑级缺陷。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《使用 select 时如何避免死锁和无提示错误？》文章吧，也可关注golang学习网公众号了解相关技术文章。