今天呢，咱们来聊聊 Go 语言的那点事儿，尤其是咱们在并发处理中常用的 select 语句，它可是处理并发时的一把利剑！

Go 语言的 select 语句，仿佛是编程世界中的一位冷静的裁判，当多个通道（channel）全都争着抢话语权的时候，它就会站出来，公平地判决谁应当先发声。

换句话说，select 可以在多个通道之间等待并选择可用的通道执行操作。

你得这么看select语句——它是并发编程领域里的一块重要的拼图，没有这块，你画出的并发图景就不完整。

首先，我们来看一个简单的示例：

select {
case <-chan1:
 // 操作1
case data := <-chan2:
 // 操作2
case chan3 <- data:
 // 操作3
default:
 // 默认操作
}

还别说，这几行代码，简单明了，但它背后可是隐藏着深邃的并发处理智慧：

• select 可以在 channel 上进行非阻塞的收发操作；
• 当存在可以收发的 channel 时，会直接处理该 channel 对应的 case；
• 如果没有任何通道准备好，它就会执行 default 子句（如果有的话）；
• 如果连 default 都没得，那它就会那么静静站着，不厌其烦地等待，直到有一个通道准备好。

优雅！这是使用过 select 语句后，我心中的感叹。就像你有了一块功能强大的瑞士军刀，可以灵活地应对各种野外求生的情况。

在代码中，select 语句也可以灵活地处理多个通道的并发操作，避免使用复杂的同步工具实现并发操作。

二、select 机制

讲科技，不能光有干巴巴的代码堆砌，还得有历史沉淀（反正以前历史老师是这么教的 :）。

而我们现在探讨的是 Go 语言里的 select 思想，它最初源自于网络 IO 模型中的 select，其精华在于 IO 多路复用。

想象一下，有那么一刻，你需要同时倾听来自世界各地的广播，这可不是一件简单的事儿。然而，这正是 go 中的 channel 和 select 的日常所在：致力于协调多个渠道的信息流，也只有在这里，才有 “通道争鸣” 的景象。

1. Go select 特性

让我们像切洋葱一样，一层层地剥开 select 神秘的外衣：

• 每个案例必须是个通道：这是规定，没得商量，像是一场形式各异的对话，总得有人发声，对吧？
• 所有被发送的通道表达式先被求值：这就像是通道们排着队，等待裁判 select 逐一审视。
• 如果有多个符合条件，select 公平地随机挑一个执行：这也是 select 魅力之一所在，我们下文会从代码层面探讨这个特性。
• 如果没有通道准备好，执行 default 子句（如果有的话）：和网络选择一样，咱不能干等着，得找点事做。
• 没有 default，select 就等着，也许数秒，也许是永恒：如果没有 default，那也只能干等着了，考验裁判耐心的时刻。
• 通道关闭时，读取会导致死循环：这像是一个已经倒闭的电台，但你的收音机还在不断尝试调频接收信号。
• 空的 select 会造成死锁：这就是没有对话的对话框，静默的无声世界。

2. 特性验证

接下来，咱们通过一系列实验来检验真实世界中 select 的行为。

(1) select 已关闭通道和空通道场景

再来看以下代码：

func main() {
    c1, c2, c3 := make(chan bool), make(chan bool), make(chan bool)
    go func() {
        for {
            select {
                // 保证c1一定不会关闭，否则会死循环此case
                case <-c1:
                    fmt.Println("case c1")
                // c2可以防止出现c1死循环的情况
                // 如果c2关闭了(ok==false)，将其置为nil，下次就会忽略此case
                case _, ok := <-c2:
                if !ok {
                    fmt.Println("c2 is closed")
                    c2 = nil
                }
                // 如果c3已关闭，则panic(不能往已关闭的channel里写数据)
                // 如果c3为nil，则ignore该case
                case c3 <- true:
                    fmt.Println("case c3")
               case v <- c4:
                   fmt.Println(v)
            }
        }
    }()
    time.Sleep(10 * time.Second)
}

当 channel 关闭以后，case <- chan 会接收该通信对应数据类型的零值，所以会出现死循环。

(2) 带 default 语句实现非阻塞读写

select {
   case <- c1:
   fmt.Println(":case c3")
   // 当c1没有消息时，不会一直阻塞，而是进入default
   default:
   fmt.Println(":select default")
}

注意，Go 语言的 select 和 Java 或者 C 语言的 switch 还不太一样：switch 中一般会带有 default 判断分支，但 select 使用时，外层的 for 循环和 default 不会同时出现，否则会发生死锁。

(3) select 实现定时任务

func main() {
   done := make(chan bool)
   var selectTest = func() {
      for {
         select {
            case <-time.After(1 * time.Second):
            fmt.Println("Working...")
            case <-done:
            fmt.Println("Job done!")
        }
    }
  }
   go selectTest()

   time.Sleep(3 * time.Second)
   done <- true
   time.Sleep(500 * time.Microsecond)
}

这个例子模拟的是一个简易的定时器，每隔一秒钟它都会打印 "Working..." 直到我们通过关闭 done 通道告诉它 "任务完成"。

这样的模式在你需要定时检查或者定时执行一些任务时非常有用！

代码运行结果：

Working...

Working...

Job done!

注意，如果定时器的另外 case 分支是上面已关闭 channel 场景，可能会出现异常，如下所示：

func main() {
    done := make(chan bool)
    t := time.Now()
    var selectTest = func() {
        for {
            select {
                case <-time.After(100 * time.Microsecond):
                    fmt.Println(time.Since(t), " time.After exec, return!")
                    return
                case <-done:
                    fmt.Println("over")
            }
    }
}
    // 关闭 chan
    close(done)
    go selectTest()
    time.Sleep(2 * time.Second)
}

我们在并发执行之前就 close(done) 关闭了 Channel，不妨猜一下这段代码会输出什么，答案是：

601.3938ms  time.After exec, return!

这是因为：done 已经被关闭了，所以当执行 case <-done 语句时会死循环此 case 分支。

但是，为什么还会执行退出 case，而且 return 时，时间来到了 601.3938ms 呢？

从上面代码中定时器 case 100 ms 执行一次，我们不难得知，程序退出时是第 6 次执行 select 语句，这里面究竟有什么魔法呢？

让我们接着往下看！

3.多个 case 满足读写条件

上文已经描述过，如果多个 case 满足读取条件时，select 会随机选择一个语句执行。

让我们用代码来详细描述一下：

func main() {
   done := make(chan int, 1024)
   tick := time.NewTicker(time.Second)
   var selectTest = func() {
      for i := 0; i < 10; i++ {
         select {
            case done <- i:
            fmt.Println(i, ", done exec")
            case <- tick.C:
            fmt.Println(i, ", time.After exec")
        }
         time.Sleep(500 * time.Millisecond)
    }
  }
   go selectTest()

   time.Sleep(5 * time.Second)
}

这个例子开启了一个 goroutine 协程来运行 selectTest 函数，在函数里面 for 循环 10 次执行 select 语句。并且，select 的两个分支 case done <- i 和 case <- tick.C 都是可以执行的。

这时候，我们看一下执行结果：

0 , done exec

1 , done exec

2 , time.After exec

3 , done exec

4 , time.After exec

5 , done exec

6 , done exec

7 , done exec

8 , time.After exec

9 , done exec

注意，以上结果多次运行的打印顺序可能不一致，是正常现象！

我们可以发现，原本写入 done 通道的 2、4 和 8 不见了，说明在循环的过程中，select 的两个分支 case done <- i 和 case <- tick.C 都是执行了的。

因此，这就验证了当多个 case 同时满足时，select 会随机选择一个执行。这个设计是为了避免某个 case 出现饥饿问题，保证公平竞争而引入的。

试想一下，如果某个 case 一直执行，而某些 case 一直得不到执行，这和 select 公平选择的初衷就冲突了。

所以，Go 在十多年前新增 select 提交时就用了这种随机策略并保留至今，虽然中途有过细微的变更，但整体语义一直没有变化。

三、底层原理

Go语言中 select用于处理多个通道（channel）的发送和接收操作，但在 Go 语言的源代码中没有直接对应的结构体。

因此，select通过runtime.scase结构体表示其中的每个 case，该结构体包含指向通道和数据元素的指针：

type scase struct {
c    *hchan         // chan
elem unsafe.Pointer // data element
}

1.编译器

编译时，select 语句被转换成 OSELECT 节点，持有 OCASE 节点集合，每个 OCASE 代表一个可能的操作，包括空（对应 default）。

根据情况不同，编译器会优化select的处理过程。优化处理的情况分为：

• 不存在任何 case 的 select：直接阻塞，使用 runtime.block 函数使当前协程（goroutine）进入永久休眠状态。
• 只有一个 case 的 select：改写成单个 if 条件语句。
• 有一个 case 是 default 的两个 case 的 select：被视为非阻塞操作，分别优化为非阻塞发送或接收。
• 多个 case：通过运行时函数 runtime.selectgo 处理，从几个待执行的 case 中选择一个。

非阻塞操作进行相应的编译器重写，发送使用 runtime.selectnbsend 函数进行非阻塞发送，接收方面有两种函数处理单值和双值接收。

2.运行时

运行时，runtime.selectgo函数通过以下几个步骤处理 select：

• 初始化阶段，决定 case 的处理顺序。
• 遍历 case，查找立即就绪的 Channel，如果有则立即处理。
• 如果没有立即就绪的 Channel，将当前 Goroutine 加入到所有相关 Channel 的收发队列中，并挂起。
• 当某个 case 就绪时（Channel 收到数据或有空间发送数据），调度器唤醒挂起的 Goroutine，查找并处理对应的 case。

本文中，我们谈到了 Go 语言里 select 的基本特性和实现，提到了select与直接 Channel 操作的相似性，以及通过 default 支持非阻塞收发操作。

我们还揭示了select 底层实现的复杂性——需要编译器和运行时支持。

通过以上不难得知，Go 的 select 语句在不同场景下的行为和实现是比较奇妙的，这也是 Go 独特的数据结构，其背后的设计与优化策略都需要我们对 Go 底层有着比较完善的认知。