Goroutines 在通道上阻塞的顺序是否决定了它们解除阻塞的顺序？我不关心发送的消息的顺序（它们保证是有序的），但会解除阻塞的 Goroutines 的顺序。
想象一个空 Channel ch 在多个 Goroutine（1、2 和 3）之间共享，每个 Goroutine 都试图在 ch 上接收消息。由于ch 为空，每个 Goroutine 都会阻塞。当我向ch 发送消息时，Goroutine 1 会先解锁吗？或者 2 或 3 可能会收到第一条消息？ （反之亦然，Goroutines 试图发送）
我有一个playground 似乎表明 Goroutines 阻塞的顺序是它们被解除阻塞的顺序，但我不确定这是否是由于实现而导致的未定义行为。
【问题讨论】：
我相信它是未指定的，因为memory model document 仅表示“通道上的发送发生在来自该通道的相应接收完成之前。” send statements 和 the receive operator 上的规范部分没有说明先解锁什么。现在 gc 工具链 uses 一个有序的 FIFO 队列来控制哪些 goroutine 解除阻塞，但我没有看到规范中的任何承诺，它必须始终如此。
（仅作为一般背景说明，Playground 代码以 GOMAXPROCS=1 运行，即在一个内核上运行，因此不会出现某些类型的与并发相关的不可预测性。）
【讨论】：
这是一个很好的问题——它涉及到并发设计时的一些重要问题。如前所述，根据当前的实现，您的具体问题的答案是基于 FIFO 的。它不太可能永远不同，除非实施者决定，比如说，后进先出法更好。
不过，无法保证。因此，您应该避免创建依赖特定实现的代码。
更广泛的问题涉及非确定性、公平和饥饿。
也许令人惊讶的是，基于 CSP 的系统中的非确定性并非来自并行发生的事情。 可能是因为并发，但不是因为是并发。相反，在做出选择时会出现不确定性。在 CSP 的形式代数中，这是在数学上建模的。幸运的是，您无需了解数学即可使用 Go。但在形式上，两个 goroutine 代码是并行执行的，只要排除所有选择，结果仍然可以确定。
Go 允许通过select 显式引入非确定性的选择，并通过在 goroutine 之间共享的通道末端隐式引入非确定性。如果你有点对点（一个读者，一个作者）的渠道，就不会出现第二种。因此，如果它在特定情况下很重要，您可以做出设计选择。
公平和饥饿通常是同一枚硬币的两面。饥饿是那些可能导致性能不佳，更有可能导致错误行为的动态问题之一（以及死锁、活锁和竞争条件）。这些动态问题是不可测试的 (more on this)，需要一些水平分析来解决。显然，如果系统的一部分因为无法访问某些资源而没有响应，那么在管理这些资源时需要更加公平。
由于当前的 FIFO 行为，对通道端的共享访问很可能提供一定程度的公平性，这似乎就足够了。但是，如果您希望它得到保证（不管实现不确定性如何），则可以使用select 和数组中的一束点对点通道。公平索引很容易实现，方法是始终按将最后选择的放在堆底部的顺序优先选择它们。此解决方案可以保证公平，但可能会带来很小的性能损失。
（除此之外：请参阅"Wot No Chickens"，了解英国坎特伯雷的研究人员关于 Java 虚拟机中的公平性缺陷的一些有趣的发现 - 该缺陷从未得到纠正！）
【讨论】：
select 编写应用程序土地保证公平调度程序，除非他们真的必须这样做。跨度>
select，这并没有什么坏处，并且知道如何进行公平的选择也是一项有用的技能。
未指定顺序，但当前实现使用 FIFO 队列等待 goroutines。
权威文档是Go Memory Model。内存模型没有为发送到同一通道的两个 goroutine 定义发生前的关系，因此没有指定顺序。接收同上。
【讨论】：