一道有趣的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里写入值,死锁就在这里产生了。

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

RPC 是通信协议吗 ?→ 我们来看下它的演进过程

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

2020年度总结 | 葡萄城软件开发技术回顾

给TA买糖
共{{data.count}}人
人已赞赏
经验教程

ASP.NET Core错误处理中间件[1]: 呈现错误信息

2021-1-18 9:49:00

经验教程

漫画 | 如何向外行解释产品经理频繁更改需求会令程序员很烦恼?

2021-1-18 10:04:00

⚠️
免责声明:根据《计算机软件保护条例》第十七条规定“为了学习和研究软件内含的设计思想和原理,通过安装、显示、传输或者存储软件等方式使用软件的,可以不经软件著作权人许可,不向其支付报酬。”您需知晓本站所有内容资源均来源于网络,仅供用户交流学习与研究使用,版权归属原版权方所有,版权争议与本站无关,用户本人下载后不能用作商业或非法用途,需在24个小时之内从您的电脑中彻底删除上述内容,否则后果均由用户承担责任;如果您访问和下载此文件,表示您同意只将此文件用于参考、学习而非其他用途,否则一切后果请您自行承担,如果您喜欢该程序,请支持正版软件,购买注册,得到更好的正版服务。 本站为个人博客非盈利性站点,所有软件信息均来自网络,所有资源仅供学习参考研究目的,并不贩卖软件,不存在任何商业目的及用途,网站会员捐赠是您喜欢本站而产生的赞助支持行为,仅为维持服务器的开支与维护,全凭自愿无任何强求。本站部份代码及教程来源于互联网,仅供网友学习交流,若您喜欢本文可附上原文链接随意转载。
无意侵害您的权益,请发送邮件至 momeis6@qq.com 或点击右侧 私信:momeis 反馈,我们将尽快处理。
0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
今日签到
有新私信 私信列表
搜索