非main goroutine的退出及调度循环(15)

原创 爱写程序的阿波张 源码游记 2019-05-12

本文是《Go语言调度器源代码情景分析》系列的第15篇,也是第二章的第5小节。

上一节我们说过main goroutine退出时会直接执行exit系统调用退出整个进程,而非main goroutine退出时则会进入goexit函数完成最后的清理工作,本小节我们首先就来验证一下非main goroutine执行完成后是否真的会去执行goexit,然后再对非main goroutine的退出流程做个梳理。这一节我们需要重点理解以下内容:

非main goroutine是如何返回到goexit函数的;

mcall函数如何从用户goroutine切换到g0继续执行;

调度循环。

非main goroutine会返回到goexit吗

首先来看一段代码:

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

import (
"fmt"
)

func g2(n int, ch chan int) {
ch <- n * n
}
func main() {
ch := make(chan int)
go g2(100, ch)
fmt.Println(<-ch)
}

这个程序比较简单,main goroutine启动后在main函数中创建了一个goroutine执行g2函数,我们称它为g2 goroutine,下面我们就用这个g2的退出来验证一下非main goroutine退出时是否真的会返回到goexit继续执行。

怎么验证呢?比较简单的办法就是用gdb来调试,在gdb中首先使用backtrace命令查看g2函数是被谁调用的,然后单步执行看它能否返回到goexit继续执行。下面是gdb调试过程:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
(gdb) b main.g2       // 在main.g2函数入口处下断点
Breakpoint 1 at 0x4869c0: file /home/bobo/study/go/goexit.go, line 7.
(gdb) r
Starting program: /home/bobo/study/go/goexit
Thread 1 "goexit" hit Breakpoint 1 at /home/bobo/study/go/goexit.go:7
(gdb) bt //查看函数调用链,看起来g2真的是被runtime.goexit调用的
#0 main.g2 (n=100, ch=0xc000052060) at /home/bobo/study/go/goexit.go:7
#1 0x0000000000450ad1 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1337
(gdb) disass //反汇编找ret的地址,这是为了在ret处下断点
Dump of assembler code for function main.g2:
=> 0x00000000004869c0 <+0>:mov %fs:0xfffffffffffffff8,%rcx
0x00000000004869c9 <+9>:cmp 0x10(%rcx),%rsp
0x00000000004869cd <+13>:jbe 0x486a0d <main.g2+77>
0x00000000004869cf <+15>:sub $0x20,%rsp
0x00000000004869d3 <+19>:mov %rbp,0x18(%rsp)
0x00000000004869d8 <+24>:lea 0x18(%rsp),%rbp
0x00000000004869dd <+29>:mov 0x28(%rsp),%rax
0x00000000004869e2 <+34>:imul %rax,%rax
0x00000000004869e6 <+38>:mov %rax,0x10(%rsp)
0x00000000004869eb <+43>:mov 0x30(%rsp),%rax
0x00000000004869f0 <+48>:mov %rax,(%rsp)
0x00000000004869f4 <+52>:lea 0x10(%rsp),%rax
0x00000000004869f9 <+57>:mov %rax,0x8(%rsp)
0x00000000004869fe <+62>:callq 0x4046a0 <runtime.chansend1>
0x0000000000486a03 <+67>:mov 0x18(%rsp),%rbp
0x0000000000486a08 <+72>:add $0x20,%rsp
0x0000000000486a0c <+76>:retq
0x0000000000486a0d <+77>:callq 0x44ece0 <runtime.morestack_noctxt>
0x0000000000486a12 <+82>:jmp 0x4869c0 <main.g2>
End of assembler dump.
(gdb) b *0x0000000000486a0c //在retq指令位置下断点
Breakpoint 2 at 0x486a0c: file /home/bobo/study/go/goexit.go, line 9.
(gdb) c
Continuing.

Thread 1 "goexit" hit Breakpoint 2 at /home/bobo/study/go/goexit.go:9
(gdb) disass //程序停在了ret指令处
Dump of assembler code for function main.g2:
0x00000000004869c0 <+0>:mov %fs:0xfffffffffffffff8,%rcx
0x00000000004869c9 <+9>:cmp 0x10(%rcx),%rsp
0x00000000004869cd <+13>:jbe 0x486a0d <main.g2+77>
0x00000000004869cf <+15>:sub $0x20,%rsp
0x00000000004869d3 <+19>:mov %rbp,0x18(%rsp)
0x00000000004869d8 <+24>:lea 0x18(%rsp),%rbp
0x00000000004869dd <+29>:mov 0x28(%rsp),%rax
0x00000000004869e2 <+34>:imul %rax,%rax
0x00000000004869e6 <+38>:mov %rax,0x10(%rsp)
0x00000000004869eb <+43>:mov 0x30(%rsp),%rax
0x00000000004869f0 <+48>:mov %rax,(%rsp)
0x00000000004869f4 <+52>:lea 0x10(%rsp),%rax
0x00000000004869f9 <+57>:mov %rax,0x8(%rsp)
0x00000000004869fe <+62>:callq 0x4046a0 <runtime.chansend1>
0x0000000000486a03 <+67>:mov 0x18(%rsp),%rbp
0x0000000000486a08 <+72>:add $0x20,%rsp
=> 0x0000000000486a0c <+76>:retq
0x0000000000486a0d <+77>:callq 0x44ece0 <runtime.morestack_noctxt>
0x0000000000486a12 <+82>:jmp 0x4869c0 <main.g2>
End of assembler dump.
(gdb) si //单步执行一条指令
runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1338
1338CALLruntime·goexit1(SB)// does not return
(gdb) disass //可以看出来g2已经返回到了goexit函数中
Dump of assembler code for function runtime.goexit:
0x0000000000450ad0 <+0>:nop
=> 0x0000000000450ad1 <+1>:callq 0x42faf0 <runtime.goexit1>
0x0000000000450ad6 <+6>:nop

使用gdb调试时,首先我们在g2函数入口处下了一个断点,程序暂停后通过查看函数调用栈发现g2函数确实是被goexit调用的,然后再一次使用断点让程序暂停在g2返回之前的最后一条指令retq处,最后单步执行这条指令,可以看到程序从g2函数返回到了goexit函数的第二条指令的位置,这个位置正是当初在创建goroutine时设置好的返回地址。可以看到,虽然g2函数并不是被goexit函数直接调用的,但它执行完成之后却返回到了goexit函数中!

至此,我们已经证实非main goroutine退出时确实会返回到goexit函数继续执行,下面我们就沿着这条线继续分析非main goroutine的退出流程。

非main goroutine的退出流程

首先来看goexit函数

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
runtime/asm_amd64.s : 1334

// 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
从前面的分析我们已经看到,非main goroutine返回时直接返回到了goexit的第二条指令:CALL runtime·goexit1(SB),该指令继续调用goexit1函数。

runtime/proc.go : 2652

// Finishes execution of the current goroutine.
func goexit1() {
if raceenabled { //与竞态检查有关,不关注
racegoend()
}
if trace.enabled { //与backtrace有关,不关注
traceGoEnd()
}
mcall(goexit0)
}
goexit1函数通过调用mcall从当前运行的g2 goroutine切换到g0,然后在g0栈上调用和执行goexit0这个函数。

runtime/asm_amd64.s : 270

# func mcall(fn func(*g))
# Switch to m->g0's stack, call fn(g).
# Fn must never return. It should gogo(&g->sched)
# to keep running g.
# mcall的参数是一个指向funcval对象的指针
TEXT runtime·mcall(SB), NOSPLIT, $0-8
#取出参数的值放入DI寄存器,它是funcval对象的指针,此场景中fn.fn是goexit0的地址
MOVQ fn+0(FP), DI

get_tls(CX)
MOVQ g(CX), AX # AX = g,本场景g 是 g2

#mcall返回地址放入BX
MOVQ 0(SP), BX# caller's PC

#保存g2的调度信息,因为我们要从当前正在运行的g2切换到g0
MOVQ BX, (g_sched+gobuf_pc)(AX) #g.sched.pc = BX,保存g2的rip
LEAQ fn+0(FP), BX # caller's SP
MOVQ BX, (g_sched+gobuf_sp)(AX) #g.sched.sp = BX,保存g2的rsp
MOVQ AX, (g_sched+gobuf_g)(AX) #g.sched.g = g
MOVQ BP, (g_sched+gobuf_bp)(AX) #g.sched.bp = BP,保存g2的rbp

# switch to m->g0 & its stack, call fn
#下面三条指令主要目的是找到g0的指针
MOVQ g(CX), BX #BX = g
MOVQ g_m(BX), BX #BX = g.m
MOVQ m_g0(BX), SI #SI = g.m.g0

#此刻,SI = g0, AX = g,所以这里在判断g 是否是 g0,如果g == g0则一定是哪里代码写错了
CMPQ SI, AX# if g == m->g0 call badmcall
JNE 3(PC)
MOVQ $runtime·badmcall(SB), AX
JMP AX

#把g0的地址设置到线程本地存储之中
MOVQ SI, g(CX)

#恢复g0的栈顶指针到CPU的rsp积存,这一条指令完成了栈的切换,从g的栈切换到了g0的栈
MOVQ (g_sched+gobuf_sp)(SI), SP# rsp = g0->sched.sp

#AX = g
PUSHQ AX #fn的参数g入栈
MOVQ DI, DX #DI是结构体funcval实例对象的指针,它的第一个成员才是goexit0的地址
MOVQ 0(DI), DI #读取第一个成员到DI寄存器
CALL DI #调用goexit0(g)
POPQ AX
MOVQ $runtime·badmcall2(SB), AX
JMP AX
RET
mcall的参数是一个函数,在Go语言的实现中,函数变量并不是一个直接指向函数代码的指针,而是一个指向funcval结构体对象的指针,funcval结构体对象的第一个成员fn才是真正指向函数代码的指针。

type funcval struct {
fn uintptr
// variable-size, fn-specific data here
}

也就是说,在我们这个场景中mcall函数的fn参数的fn成员中存放的才是goexit0函数的第一条指令的地址。

mcall函数主要有两个功能:

首先从当前运行的g(我们这个场景是g2)切换到g0,这一步包括保存当前g的调度信息,把g0设置到tls中,修改CPU的rsp寄存器使其指向g0的栈;

以当前运行的g(我们这个场景是g2)为参数调用fn函数(此处为goexit0)。

从mcall的功能我们可以看出,mcall做的事情跟gogo函数完全相反,gogo函数实现了从g0切换到某个goroutine去运行,而mcall实现了从某个goroutine切换到g0来运行,因此,mcall和gogo的代码非常相似,然而mcall和gogo在做切换时有个重要的区别:gogo函数在从g0切换到其它goroutine时首先切换了栈,然后通过跳转指令从runtime代码切换到了用户goroutine的代码,而mcall函数在从其它goroutine切换回g0时只切换了栈,并未使用跳转指令跳转到runtime代码去执行。为什么会有这个差别呢?原因在于在从g0切换到其它goroutine之前执行的是runtime的代码而且使用的是g0栈,所以切换时需要首先切换栈然后再从runtime代码跳转某个goroutine的代码去执行(切换栈和跳转指令不能颠倒,因为跳转之后执行的就是用户的goroutine代码了,没有机会切换栈了),然而从某个goroutine切换回g0时,goroutine使用的是call指令来调用mcall函数,mcall函数本身就是runtime的代码,所以call指令其实已经完成了从goroutine代码到runtime代码的跳转,因此mcall函数自身的代码就不需要再跳转了,只需要把栈切换到g0栈即可。

因为mcall跟gogo非常相似,前面我们对gogo的每一条指令已经做过详细的分析,所以这里就不再详细解释mcall的每一条指令了,但笔者在上面所展示的mcall代码中做了一些注释(注释中的g表示当前正在运行的goroutine,我们这个场景g就是g2),这里大家可以结合gogo的代码以及mcall的代码和注释来加深对g0与其它goroutine之间的切换的理解。

从g2栈切换到g0栈之后,下面开始在g0栈执行goexit0函数,该函数完成最后的清理工作:

把g的状态从_Grunning变更为_Gdead;

然后把g的一些字段清空成0值;

调用dropg函数解除g和m之间的关系,其实就是设置g->m = nil, m->currg = nil;

把g放入p的freeg队列缓存起来供下次创建g时快速获取而不用从内存分配。freeg就是g的一个对象池;

调用schedule函数再次进行调度;

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
runtime/proc.go : 2662



// goexit continuation on g0.
func goexit0(gp *g) {
_g_ := getg() //g0

casgstatus(gp, _Grunning, _Gdead) //g马上退出,所以设置其状态为_Gdead
if isSystemGoroutine(gp, false) {
atomic.Xadd(&sched.ngsys, -1)
}

//清空g保存的一些信息
gp.m = nil
locked := gp.lockedm != 0
gp.lockedm = 0
_g_.m.lockedg = 0
gp.paniconfault = false
gp._defer = nil // should be true already but just in case.
gp._panic = nil // non-nil for Goexit during panic. points at stack-allocated data.
gp.writebuf = nil
gp.waitreason = 0
gp.param = nil
gp.labels = nil
gp.timer = nil

......

// Note that gp's stack scan is now "valid" because it has no
// stack.
gp.gcscanvalid = true

//g->m = nil, m->currg = nil 解绑g和m之关系
dropg()

......

gfput(_g_.m.p.ptr(), gp) //g放入p的freeg队列,方便下次重用,免得再去申请内存,提高效率

......

//下面再次调用schedule
schedule()
}

到此为止g2的生命周期就结束了,工作线程再次调用了schedule函数进入新一轮的调度循环。

调度循环

我们说过,任何goroutine被调度起来运行都是通过schedule()->execute()->gogo()这个函数调用链完成的,而且这个调用链中的函数一直没有返回。以我们刚刚讨论过的g2 goroutine为例,从g2开始被调度起来运行到退出是沿着下面这条路径进行的

schedule()->execute()->gogo()->g2()->goexit()->goexit1()->mcall()->goexit0()->schedule()
可以看出,一轮调度是从调用schedule函数开始的,然后经过一系列代码的执行到最后又再次通过调用schedule函数来进行新一轮的调度,从一轮调度到新一轮调度的这一过程我们称之为一个调度循环,这里说的调度循环是指某一个工作线程的调度循环,而同一个Go程序中可能存在多个工作线程,每个工作线程都有自己的调度循环,也就是说每个工作线程都在进行着自己的调度循环。

从前面的代码分析可以得知,上面调度循环中的每一个函数调用都没有返回,虽然g2()->goexit()->goexit1()->mcall()这几个函数是在g2的栈空间执行的,但剩下的函数都是在g0的栈空间执行的,那么问题就来了,在一个复杂的程序中,调度可能会进行无数次循环,也就是说会进行无数次没有返回的函数调用,大家都知道,每调用一次函数都会消耗一定的栈空间,而如果一直这样无返回的调用下去无论g0有多少栈空间终究是会耗尽的,那么这里是不是有问题?其实没有问题,关键点就在于,每次执行mcall切换到g0栈时都是切换到g0.sched.sp所指的固定位置,这之所以行得通,正是因为从schedule函数开始之后的一系列函数永远都不会返回,所以重用这些函数上一轮调度时所使用过的栈内存是没有问题的。

每个工作线程的执行流程和调度循环都一样,如下图所示:

总结

我们用上图来总结一下工作线程的执行流程:

初始化,调用mstart函数;

调用mstart1函数,在该函数中调用save函数设置g0.sched.sp和g0.sched.pc等调度信息,其中g0.sched.sp指向mstart函数栈帧的栈顶;

依次调用schedule->execute->gogo函数执行调度;

运行用户的goroutine代码;

用户goroutine代码执行过程中调用runtime中的某些函数,然后这些函数调用mcall切换到g0.sched.sp所指的栈并最终再次调用schedule函数进入新一轮调度,之后工作线程一直循环执行着3~5这一调度循环直到进程退出为止。

最后,如果你觉得本文对你有帮助的话,麻烦帮忙点一下文末右下角的 在看 或转发到朋友圈,非常感谢!

-------------本文结束 感谢阅读-------------