上一讲说到调度器将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语言学习、求职的社区。
分析笔记)
