上一讲说到调度器将maingoroutine推上舞台,为它铺好了道路,开始执行runtime.main
函数。这一讲,我们探索maingoroutine以及普通goroutine从执行到退出的整个过程。
//Themaingoroutine.
funcmain(){
//g=maingoroutine,不再是g0了
g:=getg()//……………………ifsys.PtrSize==8{
maxstacksize=1000000000
}else{
maxstacksize=250000000
}//AllownewproctostartnewMs.
mainStarted=truesystemstack(func(){
//创建监控线程,该线程独立于调度器,不需要跟p关联即可运行
newm(sysmon,nil)
})lockOSThread()ifg.m!=&m0{
throw("runtime.mainnotonm0")
}//调用runtime包的初始化函数,由编译器实现
runtime_init()//mustbebeforedefer
ifnanotime()==0{
throw("nanotimereturningzero")
}//Deferunlocksothatruntime.Goexitduringinitdoestheunlocktoo.
needUnlock:=true
deferfunc(){
ifneedUnlock{
unlockOSThread()
}
}()//Recordwhentheworldstarted.Mustbeafterruntime_init
//becausenanotimeonsomeplatformsdependsonstartNano.
runtimeInitTime=nanotime()//开启垃圾回收器
gcenable()main_init_done=make(chanbool)//……………………//main包的初始化,递归的调用我们import进来的包的初始化函数
fn:=main_init
fn()
close(main_init_done)needUnlock=false
unlockOSThread()//……………………//调用main.main函数
fn=main_main
fn()
ifraceenabled{
racefini()
}//……………………//进入系统调用,退出进程,可以看出maingoroutine并未返回,而是直接进入系统调用退出进程了
exit(0)
//保护性代码,如果exit意外返回,下面的代码会让该进程crash死掉
for{
varx*int32
*x=0
}
}
main
函数执行流程如下图:
从流程图可知,maingoroutine执行完之后就直接调用exit(0)
退出了,这会导致整个进程退出,太粗暴了。
不过,maingoroutine实际上就是代表用户的main函数,它都执行完了,肯定是用户的任务都执行完了,直接退出就可以了,就算有其他的goroutine没执行完,同样会直接退出。
packagemainimport"fmt"funcmain(){
gofunc(){fmt.Println("helloqcrao.com")}()
}
在这个例子中,maingorutine退出时,还来不及执行go出去
的函数,整个进程就直接退出了,打印语句不会执行。因此,maingoroutine不会等待其他goroutine执行完再退出,知道这个有时能解释一些现象,比如上面那个例子。
这时,心中可能会跳出疑问,我们在新创建goroutine的时候,不是整出了个“偷天换日”,风风火火地设置了goroutine退出时应该跳到runtime.goexit
函数吗,怎么这会不用了,闲得慌?
回顾一下上一讲的内容,跳转到main函数的两行代码:
//把sched.pc值放入BX寄存器
MOVQ gobuf_pc(BX),BX
//JMP把BX寄存器的包含的地址值放入CPU的IP寄存器,于是,CPU跳转到该地址继续执行指令
JMP BX
直接使用了一个跳转,并没有使用CALL
指令,而runtime.main函数中确实也没有RET
返回的指令。所以,maingoroutine执行完后,直接调用exit(0)退出整个进程。
那之前整地“偷天换日”还有用吗?有的!这是针对非maingoroutine起作用。
参考资料【阿波张非goroutine的退出】中用调试工具验证了非maingoroutine的退出,感兴趣的可以去跟着实践一遍。
我们继续探索非maingoroutine(后文我们就称gp好了)的退出流程。
gp
执行完后,RET指令弹出goexit
函数地址(实际上是funcPC(goexit)+1),CPU跳转到goexit
的第二条指令继续执行:
//src/runtime/asm_amd64.s//Thetop-mostfunctionrunningonagoroutine
//returnstogoexit+PCQuantum.
TEXTruntime·goexit(SB),NOSPLIT,$0-0
BYTE $0x90 //NOP
CALL runtime·goexit1(SB) //doesnotreturn
//tracebackfromgoexit1musthitcoderangeofgoexit
BYTE $0x90 //NOP
直接调用runtime·goexit1
:
//src/runtime/proc.go
//Finishesexecutionofthecurrentgoroutine.
funcgoexit1(){
//……………………
mcall(goexit0)
}
调用mcall
函数:
//切换到g0栈,执行fn(g)
//Fn不能返回
TEXTruntime·mcall(SB),NOSPLIT,$0-8
//取出参数的值放入DI寄存器,它是funcval对象的指针,此场景中fn.fn是goexit0的地址
MOVQ fn+0(FP),DIget_tls(CX)
//AX=g
MOVQ g(CX),AX //savestateing->sched
//mcall返回地址放入BX
MOVQ 0(SP),BX //caller'sPC
//g.sched.pc=BX,保存g的PC
MOVQ BX,(g_sched+gobuf_pc)(AX)
LEAQ fn+0(FP),BX //caller'sSP
//保存g的SP
MOVQ BX,(g_sched+gobuf_sp)(AX)
MOVQ AX,(g_sched+gobuf_g)(AX)
MOVQ BP,(g_sched+gobuf_bp)(AX)//switchtom->g0&itsstack,callfn
MOVQ g(CX),BX
MOVQ g_m(BX),BX
//SI=g0
MOVQ m_g0(BX),SI
CMPQ SI,AX //ifg==m->g0callbadmcall
JNE3(PC)
MOVQ $runtime·badmcall(SB),AX
JMPAX
//把g0的地址设置到线程本地存储中
MOVQ SI,g(CX) //g=m->g0
//从g的栈切换到了g0的栈D
MOVQ (g_sched+gobuf_sp)(SI),SP //sp=m->g0->sched.sp
//AX=g,参数入栈
PUSHQ AX
MOVQ DI,DX
//DI是结构体funcval实例对象的指针,它的第一个成员才是goexit0的地址
//读取第一个成员到DI寄存器
MOVQ 0(DI),DI
//调用goexit0(g)
CALL DI
POPQ AX
MOVQ $runtime·badmcall2(SB),AX
JMPAX
RET
函数参数是:
typefuncvalstruct{
fnuintptr
//variable-size,fn-specificdatahere
}
字段fn就表示goexit0函数的地址。
L5将函数参数保存到DI寄存器,这里fn.fn就是goexit0的地址。
L7将tls保存到CX寄存器,L9将当前线程指向的goroutine(非maingoroutine,称为gp)保存到AX寄存器,L11将调用者(调用mcall函数)的栈顶,这里就是mcall完成后的返回地址,存入BX寄存器。
L13将mcall的返回地址保存到gp的g.sched.pc字段,L14将gp的栈顶,也就是SP保存到BX寄存器,L16将SP保存到gp的g.sched.sp字段,L17将g保存到gp的g.sched.g字段,L18将BP保存到gp的g.sched.bp字段。这一段主要是保存gp的调度信息。
L21将当前指向的g保存到BX寄存器,L22将g.m字段保存到BX寄存器,L23将g.m.g0字段保存到SI,g.m.g0就是当前工作线程的g0。
现在,SI=g0,AX=gp,L25判断gp是否是g0,如果gp==g0说明有问题,执行runtime·badmcall。正常情况下,PC值加3,跳过下面的两条指令,直接到达L30。
L30将g0的地址设置到线程本地存储中,L32将g0.SP设置到CPU的SP寄存器,这也就意味着我们从gp栈切换到了g0的栈,要变天了!
L34将参数gp入栈,为调用goexit0构造参数。L35将DI寄存器的内容设置到DX寄存器,DI是结构体funcval实例对象的指针,它的第一个成员才是goexit0的地址。L36读取DI第一成员,也就是goexit0函数的地址。
L40调用goexit0函数,这已经是在g0栈上执行了,函数参数就是gp。
到这里,就会去执行goexit0函数,注意,这里永远都不会返回。所以,在CALL指令后面,如果返回了,又会去调用runtime.badmcall2
函数去处理意外情况。
来继续看goexit0:
//goexitcontinuationong0.
//在g0上执行
funcgoexit0(gp*g){
//g0
_g_:=getg()casgstatus(gp,_Grunning,_Gdead)
ifisSystemGoroutine(gp){
atomic.Xadd(&sched.ngsys,-1)
}//清空gp的一些字段
gp.m=nil
gp.lockedm=nil
_g_.m.lockedg=nil
gp.paniconfault=false
gp._defer=nil//shouldbetruealreadybutjustincase.
gp._panic=nil//non-nilforGoexitduringpanic.pointsatstack-allocateddata.
gp.writebuf=nil
gp.waitreason=""
gp.param=nil
gp.labels=nil
gp.timer=nil//Notethatgp'sstackscanisnow"valid"becauseithasno
//stack.
gp.gcscanvalid=true
//解除g与m的关系
dropg()if_g_.m.locked&^_LockExternal!=0{
print("invalidm->locked=",_g_.m.locked,"\n")
throw("internallockOSThreaderror")
}
_g_.m.locked=0
//将g放入free队列缓存起来
gfput(_g_.m.p.ptr(),gp)
schedule()
}
它主要完成最后的清理工作:
1.把g的状态从
_Grunning
更新为_Gdead
;
1.清空g的一些字段;
1.调用dropg函数解除g和m之间的关系,其实就是设置g->m=nil,m->currg=nil;
1.把g放入p的freeg队列缓存起来供下次创建g时快速获取而不用从内存分配。freeg就是g的一个对象池;
1.调用schedule函数再次进行调度。
到这里,gp就完成了它的历史使命,功成身退,进入了goroutine缓存池,待下次有任务再重新启用。
而工作线程,又继续调用schedule函数进行新一轮的调度,整个过程形成了一个循环。
总结一下,maingoroutine和普通goroutine的退出过程:
对于maingoroutine,在执行完用户定义的main函数的所有代码后,直接调用exit(0)退出整个进程,非常霸道。
对于普通goroutine则没这么“舒服”,需要经历一系列的过程。先是跳转到提前设置好的goexit函数的第二条指令,然后调用runtime.goexit1,接着调用mcall(goexit0)
,而mcall函数会切换到g0栈,运行goexit0函数,清理goroutine的一些字段,并将其添加到goroutine缓存池里,然后进入schedule调度循环。到这里,普通goroutine才算完成使命。
本文节选于Go合集《Go 语言问题集》:GOLANG ROADMAP 一个专注Go语言学习、求职的社区。