小白debug

一起在知识的海洋里呛水

0%

动图图解!怎么让goroutine跑一半就退出?

光看标题,大家可能不太理解我说的是啥。

我们平时创建一个协程,跑一段逻辑,代码大概长这样。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package main

import (
"fmt"
"time"
)
func Foo() {
fmt.Println("打印1")
defer fmt.Println("打印2")
fmt.Println("打印3")
}

func main() {
go Foo()
fmt.Println("打印4")
time.Sleep(1000*time.Second)
}

// 这段代码,正常运行会有下面的结果
打印4
打印1
打印3
打印2

注意这上面”打印 2“是在defer中的,所以会在函数结束前打印。因此后置于”打印 3“。

那么今天的问题是,如何让Foo()函数跑一半就结束,比如说跑到打印 2,就退出协程。输出如下结果

1
2
3
打印4
打印1
打印2

也不卖关子了,我这边直接说答案。

在”打印 2”后面插入一个 runtime.Goexit(), 协程就会直接结束。并且结束前还能执行到defer里的打印 2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
package main

import (
"fmt"
"runtime"
"time"
)
func Foo() {
fmt.Println("打印1")
defer fmt.Println("打印2")
runtime.Goexit() // 加入这行
fmt.Println("打印3")
}

func main() {
go Foo()
fmt.Println("打印4")
time.Sleep(1000*time.Second)
}


// 输出结果
打印4
打印1
打印2

可以看到打印 3这一行没出现了,协程确实提前结束了。

其实面试题到这里就讲完了,这一波自问自答可还行?

但这不是今天的重点,我们需要搞搞清楚内部的逻辑。

runtime.Goexit()是什么?

看一下内部实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
func Goexit() {
// 以下函数省略一些逻辑...
gp := getg()
for {
// 获取defer并执行
d := gp._defer
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
}
goexit1()
}

func goexit1() {
mcall(goexit0)
}

从代码上看,runtime.Goexit()会先执行一下defer里的方法,这里就解释了开头的代码里为什么在 defer 里的打印 2能正常输出。

然后代码再执行goexit1。本质就是对goexit0的简单封装。

我们可以把代码继续跟下去,看看goexit0做了什么。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// goexit continuation on g0.
func goexit0(gp *g) {
// 获取当前的 goroutine
_g_ := getg()
// 将当前goroutine的状态置为 _Gdead
casgstatus(gp, _Grunning, _Gdead)
// 全局协程数减一
if isSystemGoroutine(gp, false) {
atomic.Xadd(&sched.ngsys, -1)
}

// 省略各种清空逻辑...

// 把g从m上摘下来。
dropg()


// 把这个g放回到p的本地协程队列里,放不下放全局协程队列。
gfput(_g_.m.p.ptr(), gp)

// 重新调度,拿下一个可运行的协程出来跑
schedule()
}

这段代码,信息密度比较大。

很多名词可能让人一脸懵。

简单描述下,Go 语言里有个GMP 模型的说法,M是内核线程,G也就是我们平时用的协程goroutineP会在G和M之间做工具人,负责调度GM上运行。

GMP图

既然是调度,也就是说不是每个G都能一直处于运行状态,等 G 不能运行时,就把它存起来,再调度下一个能运行的 G 过来运行。

暂时不能运行的 G,P 上会有个本地队列去存放这些这些 G,P 的本地队列存不下的话,还有个全局队列,干的事情也类似。

了解这个背景后,再回到 goexit0 方法看看,做的事情就是将当前的协程 G 置为_Gdead状态,然后把它从 M 上摘下来,尝试放回到 P 的本地队列中。然后重新调度一波,获取另一个能跑的 G,拿出来跑。

goexit

所以简单总结一下,只要执行 goexit 这个函数,当前协程就会退出,同时还能调度下一个可执行的协程出来跑。

看到这里,大家应该就能理解,开头的代码里,为什么runtime.Goexit()能让协程只执行一半就结束了。

goexit 的用途

看是看懂了,但是会忍不住疑惑。面试这么问问,那只能说明你遇到了一个喜欢为难年轻人的面试官,但正经人谁会没事跑一半协程就结束呢?所以goexit真实用途是啥?

有个小细节,不知道大家平时 debug 的时候有没有关注过。

为了说明问题,这里先给出一段代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package main

import (
"fmt"
"time"
)
func Foo() {
fmt.Println("打印1")
}

func main() {
go Foo()
fmt.Println("打印3")
time.Sleep(1000*time.Second)
}

这是一段非常简单的代码,输出什么完全不重要。通过go关键字启动了一个goroutine执行Foo(),里面打印一下就结束,主协程sleep很长时间,只为死等

这里我们新启动的协程里,在Foo()函数内随便打个断点。然后debug一下。

会发现,这个协程的堆栈底部是从runtime.goexit()里开始启动的。

如果大家平时有注意观察,会发现,其实所有的堆栈底部,都是从这个函数开始的。我们继续跟跟代码。

goexit 是什么?

从上面的debug堆栈里点进去会发现,这是个汇编函数,可以看出调用的是runtime包内的 goexit1() 函数。

1
2
3
4
5
6
7
// The top-most function running on a goroutine
// returns to goexit+PCQuantum.
TEXT runtime·goexit(SB),NOSPLIT,$0-0
BYTE $0x90 // NOP
CALL runtime·goexit1(SB) // does not return
// traceback from goexit1 must hit code range of goexit
BYTE $0x90 // NOP

于是跟到了pruntime/proc.go里的代码中。

1
2
3
4
// 省略部分代码
func goexit1() {
mcall(goexit0)
}

是不是很熟悉,这不就是我们开头讲runtime.Goexit()里内部执行的goexit0吗。

为什么每个堆栈底部都是这个方法?

我们首先需要知道的是,函数栈的执行过程,是先进后出。

假设我们有以下代码

1
2
3
4
5
6
7
8
9
10
11
func main() {
B()
}

func B() {
A()
}

func A() {

}

上面的代码是 main 运行 B 函数,B 函数再运行 A 函数,代码执行时就跟下面的动图那样。

函数堆栈执行顺序

这个是先进后出的过程,也就是我们常说的函数栈,执行完子函数 A()后,就会回到父函数 B()中,执行完B()后,最后就会回到main()。这里的栈底是main(),如果在栈底插入的是 goexit 的话,那么当程序执行结束的时候就都能跑到goexit里去。

结合前面讲过的内容,我们就能知道,此时栈底的goexit,会在协程内的业务代码跑完后被执行到,从而实现协程退出,并调度下一个可执行的 G来运行。


那么问题又来了,栈底插入goexit这件事是谁做的,什么时候做的?

直接说答案,这个在runtime/proc.go里有个newproc1方法,只要是创建协程都会用到这个方法。里面有个地方是这么写的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func newproc1(fn *funcval, argp unsafe.Pointer, narg int32, callergp *g, callerpc uintptr) {
// 获取当前g
_g_ := getg()
// 获取当前g所在的p
_p_ := _g_.m.p.ptr()
// 创建一个新 goroutine
newg := gfget(_p_)

// 底部插入goexit
newg.sched.pc = funcPC(goexit) + sys.PCQuantum
newg.sched.g = guintptr(unsafe.Pointer(newg))
// 把新创建的g放到p中
runqput(_p_, newg, true)

// ...
}

主要的逻辑是获取当前协程 G 所在的调度器 P,然后创建一个新 G,并在栈底插入一个 goexit。

所以我们每次 debug 的时候,就都能看到函数栈底部有个 goexit 函数。

main 函数也是个协程,栈底也是 goexit?

关于 main 函数栈底是不是也有个goexit,我们对下面代码断点看下。直接得出结果。

main 函数栈底也是goexit()

asm_amd64.s可以看到 Go 程序启动的流程,这里提到的 runtime·mainPC 其实就是 runtime.main.

1
2
3
4
5
// create a new goroutine to start program
MOVQ $runtime·mainPC(SB), AX // 也就是runtime.main
PUSHQ AX
PUSHQ $0 // arg size
CALL runtime·newproc(SB)

通过runtime·newproc创建runtime.main协程,然后在runtime.main里会启动main.main函数,这个就是我们平时写的那个 main 函数了。

1
2
3
4
5
6
7
8
9
// runtime/proc.go
func main() {
// 省略大量代码
fn := main_main // 其实就是我们的main函数入口
fn()
}

//go:linkname main_main main.main
func main_main()

结论是,其实 main 函数也是由 newproc 创建的,只要通过 newproc 创建的 goroutine,栈底就会有一个 goexit。

os.Exit()和 runtime.Goexit()有什么区别

最后再回到开头的问题,实现一下首尾呼应。

开头的面试题,除了runtime.Goexit(),是不是还可以改为用os.Exit()

同样都是带有”退出”的含义,两者退出的对象不同。os.Exit() 指的是整个进程退出;而runtime.Goexit()指的是协程退出。

可想而知,改用os.Exit() 这种情况下,defer 里的内容就不会被执行到了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package main

import (
"fmt"
"os"
"time"
)
func Foo() {
fmt.Println("打印1")
defer fmt.Println("打印2")
os.Exit(0)
fmt.Println("打印3")
}

func main() {
go Foo()
fmt.Println("打印4")
time.Sleep(1000*time.Second)
}

// 输出结果
打印4
打印1

总结

  • 通过 runtime.Goexit()可以做到提前结束协程,且结束前还能执行到 defer 的内容
  • runtime.Goexit()其实是对 goexit0 的封装,只要执行 goexit0 这个函数,当前协程就会退出,同时还能调度下一个可执行的协程出来跑。
  • 通过newproc可以创建出新的goroutine,它会在函数栈底部插入一个 goexit。
  • os.Exit() 指的是整个进程退出;而runtime.Goexit()指的是协程退出。两者含义有区别。

最后

无用的知识又增加了。

一般情况下,业务开发中,谁会没事执行这个函数呢?

但是开发中不关心,不代表面试官不关心!

下次面试官问你,如果想在 goroutine 执行一半就退出协程,该怎么办?你知道该怎么回答了吧?


好了,兄弟们,有没有发现这篇文章写的又水又短,真的是因为我变懒了吗?

不!

当然不!

我是为了兄弟们的身体健康考虑,保持蹲姿太久对身体不好,懂?


如果文章对你有帮助,欢迎…..

算了。

一起在知识的海洋里呛水吧

我是小白,我们下期见!


点击下方名片,关注公众号:【小白 debug】


不满足于在留言区说骚话?

加我,我们建了个划水吹牛皮群,在群里,你可以跟你下次跳槽可能遇到的同事或面试官聊点有趣的话题。就超!开!心!

文章推荐:

参考资料

饶大的《哪来里的 goexit?》- https://qcrao.com/2021/06/07/where-is-goexit-from/

欢迎关注我的其它发布渠道