Go 的 select 语句采用均匀伪随机选择，以确保通信操作的公平性并防止饥饿。当 select 中的多个情况同时准备就绪时，运行时会生成情况顺序的随机排列，并依次评估它们，直到有一个成功。这一设计确保没有单个 Channel 在始终准备就绪的情况下持续主导执行，从而在所有准备就绪的情况下均匀分配选择概率。
考虑一个高频交易平台，其中主要的 Goroutine 从三个独立的交易所数据源聚合市场数据。这些数据源通过不同的 Channels 提供更新：NYSE、NASDAQ 和 Forex。Forex 通道以微秒级别传输货币波动，而 NYSE 每十毫秒更新一次，NASDAQ 在正常情况下每五十毫秒发送偶发的大宗交易通知。
如果 Go 以固定的词法顺序评估 select 情况，Forex 通道的持续准备就绪会在波动交易期间灾难性地使 NASDAQ 通知发生饥饿。这种饥饿会导致聚合引擎错过重要的交易执行，可能会违反最佳执行报告的监管要求。系统需要一种公平机制，确保每个数据源都能获得处理时间，而不管相对速度或到达频率。
我们最初考虑通过在应用代码中维护一个循环索引来实现手动轮询。这种方法通过显式跟踪最后服务的通道并相应地移动光标来提供确定性的公平性。然而，这种解决方案引入了相当大的复杂性，需要我们在并发访问中管理共享状态，并模糊了以干净的语法等待多个 Channels 的直接意图。
第二种方法涉及实施权重优先系统，人工限制高频 Forex 更新，以为较慢的通道创造带宽。虽然这允许对消息吞吐量的细粒度控制，但它要求根据市场波动条件不断调整节流率。维护负担被证明过于沉重，因为错误配置可能导致在闪电崩盘期间悄然丢失关键价格波动，当时系统需要原始吞吐量，而不是公平分配。
最终，我们依赖于 Go 的内置伪随机 select 行为，它在不增加应用层复杂性的情况下提供统计公平性。均匀分布确保在数百万次迭代中，每个 Channel 根据其实际准备频率相对于其源代码中的位置获得比例执行机会。这一选择完全消除了饥饿事件，并且非确定性特性意外地在压力测试中暴露了潜在的竞争条件，而确定性顺序先前掩盖了这些问题。
为什么 Go 不保证 select 情况的特定评估顺序？
Go 有意规定，准备好的 Channels 之间的选择是非确定性的，以防止开发人员编写依赖于特定实现顺序的代码。运行时可能在不同版本之间更改其随机化算法，因此程序必须将所有情况视为同等可能。这个设计哲学迫使开发出健壮的并发模式，以免 Goroutines 不小心依赖于可能在编译器升级期间破裂的时间假设或通道优先级。
你能否使用语言原语强制 select 优先于一个 Channel 而不是另一个？
虽然 Go 的 select 本质上是公平的，开发人员可以通过嵌套 select 语句或使用辅助控制 Channels 来模拟优先级，但这违反了惯用的 Go 风格。一种反模式涉及使用超时逻辑包装快速 Channels 或在忙循环中使用默认情况，这会导致忙等待并浪费 CPU 周期。正确的方法是接受均匀随机性作为语言特性，并重新设计架构以不需要在同等等待的 Channels 之间严格的优先级。
什么同步机制允许 select 原子地等待多个 Channels？
select 在所有相关 Channels 的等待队列中同时注册 Goroutine，然后进入休眠，创建等待状态的一致快照。当任何 Channel 变为就绪时，它会唤醒 Goroutine，然后 Goroutine 必须竞争获取锁才能继续操作。这种原子多注册防止了丢失唤醒，并确保即使多个 Channels 同时接收数据，只有一个情况会执行，尽管候选人通常错误地认为 select 是轮询或使用一个中央代理。