一道有趣的golang排错题

很久没写博客了，不得不说go语言爱好者周刊是个宝贝，本来想随便看看打发时间的，没想到一下子给了我久违的灵感。

go语言爱好者周刊78期出了一道非常有意思的题目。

我们来看看题目。先给出如下的代码：

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan int)
    go fmt.Println(<-ch1)
    ch1 <- 5
    time.Sleep(1 * time.Second)
}

请问这串代码的输出是什么。

我最先想到的是5，毕竟代码很简单，反应比较快的话代码看完结果也就推断出来了。

然而题目给出的其中一个选项是输出死锁报错，这个选项引起了我的好奇，于是我运行了一下：

$ go run a.go

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
main.main()
        /tmp/a.go:10 +0x65
exit status 2

啊这。真的死锁了。那么我猜会不会和执行顺序有关呢？于是我写了个脚本运行1000次看看：

#!/bin/bash

for i in {0..1000}
do
    go run a.go &> /dev/null
    if [ $? -eq 0 ]
    then
        echo 'success!'
        break
    fi
done

结果自然是一次也没成功，即使你改成10000哪怕是1000000也是一样的。执行顺序带来的影响我们可以排除了。

如果你仔细观察的话，所有的报错也都是一样的：goroutine 1 [chan receive]:，在这里死锁了。

那么会不会是因为使用了无缓冲chan的原因呢？golang的内存模型规定了无缓冲chan的接受happens before发送操作，这会不会带来影响呢（其实仔细想想就很快排除了，happens before确定的是内存的可见性，而不是指令执行的时间顺序），所以我改了下代码：

func main() {
    ch1 := make(chan int, 100)
    go fmt.Println(<-ch1)
    ch1 <- 5
    time.Sleep(1 * time.Second)
}

这次我们使用了一个有容纳100个元素的buff的channel，然而结果还是没有一点改变。

到这里我的思路中断了。

不过我还有google啊，所以我用“golang channel deadlock”为关键词搜索了一下，然后发现了一些有意思的结果。

那就是所有的chan的死锁的代码基本都能抽象成下面的形式：

func main() {
    ch1 := make(chan int) // 是否有buff无影响
    _ = <-chan
    ch1 <- 5
}

这个代码毫无疑问是会死锁的，因为从chan接收值而chan里是空的会导致当前goroutine进入等待，而当前goroutine不能继续运行的话就永远没办法向chan里写入值，死锁就在这里产生了。

在仔细观察一下，你就会发现题目的代码和这很像：

func main() {
    ch1 := make(chan int)
    go fmt.Println(<-ch1)
    ch1 <- 5
    // sleep是为了main routine不会过早退出
}

答案只有一个，<-ch1发生在main goroutine里了。

为了佐证这一观点，我有查阅了golang language spec，关于go语句有如下的描述：

The function value and parameters are evaluated as usual in the calling goroutine, but unlike with a regular call, program execution does not wait for the invoked function to complete.

函数和它的参数会像通常那样在使用go语句的那个goroutine里被执行，但不像常规的函数调用，程序不会同步等待这个函数执行完毕。

如果在看看有关求值的部分：

calls f with arguments a1, a2, … an. Except for one special case, arguments must be single-valued expressions assignable to the parameter types of F and are evaluated before the function is called.

用参数a1, a2等调用函数f，出了一个特例之外他们都必须是单值表达式，并且在函数运行前被求值。

上面说的特例是方法调用，方法的receiver会用特定的位置传给method。

这样事情的来龙去脉就清晰明了了，我们来梳理一下。

假设我们在main goroutine里启动一个子goroutine叫b，那么实际上在main goroutine里发生的事情是这样的：

1. main goroutine执行到go语句
2. go语句发现后面的函数表达式需要传递参数
3. 于是被传递的参数在main goroutine里求值
4. 新的goroutine b被创建，刚求值的参数传递给需要执行的函数（假设叫f），f在goroutine b中开始执行
5. go语句结束，控制流程回到main goroutine

所以go fmt.Println(<-ch1)里的chan接收操作是在main goroutine里执行的，因此死锁是板上钉钉的事情。

如果改成下面这样，死锁就不会发生：

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan int)
    go func() {
        fmt.Println(<-ch1)
    }()
    ch1 <- 5
    time.Sleep(1 * time.Second)
}

这是因为<-ch1这回货真价实地发生在了不同的goroutine里，死锁自然也不存在了。

这题很坏，坏就坏在fmt.Println(...)这样的形式容易让人迷惑，以为这个调用本身在新的goroutine里执行，然而真正在新goroutine里执行的却是fmt.Println内部的函数实现代码，而不是fmt.Println(...)这句，参数会在这之前就被求值。

那么这能让我们学到什么呢？答案是永远也不要写出题目里那样的代码，对于chan的操作应该确保是在和执行go语句的goroutine不同的routine中运行的。

不过万事不绝对，带buff的chan会有些例外，当然这些以后有机会再说吧:P