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

Go 语言的 select 语句，仿佛是编程世界中的一位冷静的裁判，当多个通道（channel）全都争着抢话语权的时候，它就会站出来，公平地判决谁应当先发声。换句话说，select 可以在多个通道之间等待并选择可用的通道执行操作。你得这么看select语句——它是并发编程领域里的一块重要的拼图，没有这块，你画出的并发图景就不完整。

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

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

还别说，这几行代码，简单明了，但它背后可是隐藏着深邃的并发处理智慧：
1.select 可以在 channel 上进行非阻塞的收发操作；
2.当存在可以收发的 channel 时，会直接处理该 channel 对应的 case；
3.如果没有任何通道准备好，它就会执行 default 子句（如果有的话）；
4.如果连 default 都没得，那它就会那么静静站着，不厌其烦地等待，直到有一个通道准备好。
优雅！这是使用过 select 语句后，我心中的感叹。就像你有了一块功能强大的瑞士军刀，可以灵活地应对各种野外求生的情况。

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

二. select 机制
讲科技，不能光有干巴巴的代码堆砌，还得有历史沉淀（反正以前历史老师是这么教的 :）。而我们现在探讨的是 Go 语言里的 select 思想，它最初源自于网络 IO 模型中的 select，其精华在于 IO 多路复用。想象一下，有那么一刻，你需要同时倾听来自世界各地的广播，这可不是一件简单的事儿。然而，这正是 go 中的 channel 和 select 的日常所在：致力于协调多个渠道的信息流，也只有在这里，才有 “通道争鸣” 的景象。

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

2.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，不妨猜一下这段代码会输出什么，答案是：

...
over
over
over
601.3938ms  time.After exec, return!

这是因为：done 已经被关闭了，所以当执行 case <-done 语句时会死循环此 case 分支。但是，为什么还会执行退出 case，而且 return 时，时间来到了 601.3938ms 呢？从上面代码中定时器 case 100 ms 执行一次，我们不难得知，程序退出时是第 6 次执行 select 语句，这里面究竟有什么魔法呢？
让我们接着往下看！

多个 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()
   // 堆代码 duidaima.com
   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
}

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

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

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

运行时

运行时，runtime.selectgo函数通过以下几个步骤处理 select：
1.初始化阶段，决定 case 的处理顺序。
2.遍历 case，查找立即就绪的 Channel，如果有则立即处理。
3.如果没有立即就绪的 Channel，将当前 Goroutine 加入到所有相关 Channel 的收发队列中，并挂起。
4.当某个 case 就绪时（Channel 收到数据或有空间发送数据），调度器唤醒挂起的 Goroutine，查找并处理对应的 case。

四. 小结
本文中，我们谈到了 Go 语言里 select 的基本特性和实现，提到了select与直接 Channel 操作的相似性，以及通过 default 支持非阻塞收发操作。我们还揭示了select 底层实现的复杂性——需要编译器和运行时支持。

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