历史：Go的select语句是为了支持通信顺序进程（CSP）语义而引入的，使得goroutines能够复用通道操作。编译器将select转换为对runtime.selectgo的调用，后者负责协调在准备好的通道之间选择的复杂逻辑，或者在没有通道准备好时进行阻塞。
问题：一个普遍的误解认为，添加default分支可以消除所有的同步开销，使通道操作无锁进行。这个混淆源于将“非阻塞”（如果没有分支准备好则立即返回）与“无锁”（没有互斥锁争用）混为一谈。
解决方案：实际上，Go的通道是由一个细粒度的互斥锁（hchan.lock）保护的，该锁位于通道的头结构中。在执行select时，运行时会获取所有相关通道的锁——按照内存地址排序以防止死锁——以原子方式检查它们的缓冲状态和等待队列。如果存在default分支且没有通道准备好，运行时会释放这些锁并立即返回，避免了goroutine的停车。然而，互斥锁的获取仍然会发生，这意味着该操作并不是无锁的。相反，当所有分支都阻塞时，运行时会停车该goroutine，将sudog结构排队到每个通道的等待队列中，然后原子释放所有锁并让出处理器。
一家高频交易公司建立了一个市场数据聚合器，中央调度器使用select与default来轮询多个价格供给通道，假设这种模式提供了零成本的同步，适合微秒级延迟要求。
问题描述：在生产负载下，聚合器表现出间歇性延迟峰值，超过毫秒。CPU分析显示，调度器goroutine在检查状态时，35%的周期花费在runtime.lock和runtime.unlock上争用通道互斥锁。开发团队错误地将“非阻塞”等同于“无锁”，导致他们将通道用于高频轮询而不是同步。
考虑的不同解决方案：
一种方法保留了select结构，但将通道缓冲区大小增加到1024个元素，以减少争用。虽然这减少了生产者的阻塞，但并没有消除检查default分支所需的互斥锁获取，导致热路径调度器仍然受到锁的缓存一致性流量影响。
另一种解决方案完全用无锁环形缓冲区实现替代了通道轮询，采用atomic.CompareAndSwapPointer。这消除了互斥锁开销，并为读者提供了无等待的进展保证。然而，这显著增加了代码的复杂性，需要手动内存管理，并引入了生产者更新共享指针时的潜在ABA问题。
所选解决方案利用sync/atomic的Value存储市场数据的不可变快照结构。生产者原子地交换指向新结构的指针，而调度器在其紧密循环中执行原子加载。这提供了真正的无锁读取，具有单字原子性，完美符合金融价格数据的“最后价值胜出”语义。
结果：该修改将调度器的p99延迟从800微秒减少到12纳秒，消除了互斥锁导致的调度程序冲突，并将整体CPU利用率降低了42%，使系统能够在相同硬件上处理两倍的吞吐量。
“为什么运行时在select中同时锁定所有通道，什么特定的防死锁协议决定锁获取的顺序？”
Go的运行时通过其底层hchan结构的内存地址对select分支进行排序，并严格按地址升序获取锁。这种全局总排序防止了当两个goroutines在重叠通道集上执行选择时的循环等待死锁。如果goroutine A锁定通道X然后Y，而goroutine B锁定Y然后X，则会发生死锁；基于地址的排序确保了两个goroutines总是尝试在锁定Y之前锁定X，从而消除了循环依赖。
“default分支的存在如何改变运行时的内存屏障行为，与阻塞选择相比有什么不同？”
在没有default的阻塞选择中，goroutine必须在停车前将其等待节点（sudog）发布到每个通道的等待队列中。这需要一个写屏障和一个内存屏障，以确保调度器在goroutine挂起之前观察到入队状态。有了default分支，goroutine从不停车；它只是锁下检查状态并立即返回。因此，它避免了与发布等待节点相关的内存屏障成本，以及恢复时的缓存失效，但仍然承担通道锁本身的同步成本。
“在什么特定情况下，即使缓冲通道有可用容量，选择语句中的发送操作仍然可能无法继续？”
这发生在选择语句包含多个引用同一通道的发送案例，或通道正在被并发关闭时。具体而言，如果选择评估多个对相同通道的发送案例，运行时的伪随机选择可能选择不同的案例，导致准备好的发送未执行。更关键的是，如果另一个goroutine在选择的锁获取阶段关闭通道，则待处理的发送将在持有锁时检测到关闭，并以“在关闭通道上发送”的恐慌结束，尽管之前有可用容量，阻止了操作的正常完成。