为何双Channel的Select操作耗时远高于单Channel操作耗时的两倍？

先看两个基准测试的结果与代码：

• 单Channel的Select基准测试耗时仅为2.545 ns/op：

func BenchmarkSingleSelect(b *testing.B) {
    ch := make(chan interface{}, 1)
    for i := 0; i < b.N; i++ {
        select {
        case <-ch:
        default:
        }
    }
}

• 双Channel的Select基准测试耗时为35.85 ns/op：

func BenchmarkMultiSelect(b *testing.B) {
    ch := make(chan interface{}, 1)
    ch2 := make(chan interface{}, 1)
    for i := 0; i < b.N; i++ {
        select {
        case <-ch:
        case <-ch2:
        default:
        }
    }
}

两者耗时的非线性差异，核心原因是Go编译器对单case+default的Select做了特殊编译优化，而多case的Select只能走通用的runtime调度逻辑：

• 单case+Select的优化路径：
  编译器会识别这种只有一个接收/发送case加default的场景，直接将其转换为非阻塞的channel操作，完全跳过Select的通用处理流程。比如上面的代码会被优化成类似if len(ch) > 0 { <-ch }的逻辑，本质就是简单的长度检查和可选的接收操作，没有额外的runtime调用，所以耗时极低。

• 多case Select的通用路径：
  当存在多个case时，Go必须执行一套复杂的逻辑来保证公平性和正确性，这些步骤都会带来显著开销：

  • 首先会随机打乱所有case的顺序（避免固定顺序导致的饥饿问题）
  • 遍历每个case，检查对应的channel是否处于就绪状态
  • 如果所有channel都未就绪，才会执行default分支
    这些步骤涉及runtime内部的函数调用、循环遍历、随机数生成等操作，每一步都有额外的性能开销，所以耗时不是线性增加，而是出现了数量级的跳变。

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