本文是《Go語言調度器源代碼情景分析》系列的第13篇，也是第二章的第3小節。
上一節我們分析了調度器的初始化，這一節我們來看程序中的第一個goroutine是如何創建的。
創建main goroutine
接上一節，schedinit完成調度系統初始化后，返回到rt0_go函數中開始調用newproc() 創建一個新的goroutine用於執行mainPC所對應的runtime·main函數，看下面的代碼：
runtime/asm_amd64.s : 197
# create a new goroutine to start program MOVQ $runtime·mainPC(SB), AX# entry，mainPC是runtime.main # newproc的第二個參數入棧，也就是新的goroutine需要執行的函數 PUSHQ AX # AX = &funcval{runtime·main}, # newproc的第一個參數入棧，該參數表示runtime.main函數需要的參數大小，因為runtime.main沒有參數，所以這里是0 PUSHQ $0 CALL runtime·newproc(SB) # 創建main goroutine POPQ AX POPQ AX # start this M CALL runtime·mstart(SB) # 主線程進入調度循環，運行剛剛創建的goroutine # 上面的mstart永遠不應該返回的，如果返回了，一定是代碼邏輯有問題，直接abort CALL runtime·abort(SB)// mstart should never return RET DATA runtime·mainPC+0(SB)/8,$runtime·main(SB) GLOB Lruntime·mainPC(SB),RODATA,$8
在后面的分析過程中我們會看到這個runtime.main最終會調用我們寫的main.main函數，在分析runtime·main之前我們先把重點放在newproc這個函數上。
newproc函數用於創建新的goroutine，它有兩個參數，先說第二個參數fn，新創建出來的goroutine將從fn這個函數開始執行，而這個fn函數可能也會有參數，newproc的第一個參數正是fn函數的參數以字節為單位的大小。比如有如下go代碼片段：
func start(a, b, c int64) {
......
}
func main() {
go start(1, 2, 3)
}
編譯器在編譯上面的go語句時，就會把其替換為對newproc函數的調用，編譯后的代碼邏輯上等同於下面的偽代碼
func main() {
push 0x3
push 0x2
push 0x1
runtime.newproc(24, start)
}
編譯器編譯時首先會用幾條指令把start函數需要用到的3個參數壓棧，然后調用newproc函數。因為start函數的3個int64類型的參數共占24個字節，所以傳遞給newproc的第一個參數是24，表示start函數需要24字節大小的參數。
那為什么需要傳遞fn函數的參數大小給newproc函數呢？原因就在於newproc函數將創建一個新的goroutine來執行fn函數，而這個新創建的goroutine與當前這個goroutine會使用不同的棧，因此就需要在創建goroutine的時候把fn需要用到的參數先從當前goroutine的棧上拷貝到新的goroutine的棧上之后才能讓其開始執行，而newproc函數本身並不知道需要拷貝多少數據到新創建的goroutine的棧上去，所以需要用參數的方式指定拷貝多少數據。
了解完這些背景知識之后，下面我們開始分析newproc的代碼。newproc函數是對newproc1的一個包裝，這里最重要的准備工作有兩個，一個是獲取fn函數第一個參數的地址（代碼中的argp），另一個是使用systemstack函數切換到g0棧，當然，對於我們這個初始化場景來說現在本來就在g0棧，所以不需要切換，然而這個函數是通用的，在用戶的goroutine中也會創建goroutine，這時就需要進行棧的切換。
runtime/proc.go : 3232
// Create a new g running fn with siz bytes of arguments.
// Put it on the queue of g's waiting to run.
// The compiler turns a go statement into a call to this.
// Cannot split the stack because it assumes that the arguments
// are available sequentially after &fn; they would not be
// copied if a stack split occurred.
//go:nosplit
func newproc(siz int32, fn *funcval) {
//函數調用參數入棧順序是從右向左，而且棧是從高地址向低地址增長的
//注意：argp指向fn函數的第一個參數，而不是newproc函數的參數
//參數fn在棧上的地址+8的位置存放的是fn函數的第一個參數
argp := add(unsafe.Pointer(&fn), sys.PtrSize)
gp:= getg() //獲取正在運行的g，初始化時是m0.g0
//getcallerpc()返回一個地址，也就是調用newproc時由call指令壓棧的函數返回地址，
//對於我們現在這個場景來說，pc就是CALLruntime·newproc(SB)指令后面的POPQ AX這條指令的地址
pc := getcallerpc()
//systemstack的作用是切換到g0棧執行作為參數的函數
//我們這個場景現在本身就在g0棧，因此什么也不做，直接調用作為參數的函數
systemstack(func() {
newproc1(fn, (*uint8)(argp), siz, gp, pc)
})
}
newproc1函數的第一個參數fn是新創建的goroutine需要執行的函數，注意這個fn的類型是funcval結構體類型，其定義如下：
type funcval struct{
fn uintptr
// variable-size, fn-specific data here
}
newproc1的第二個參數argp是fn函數的第一個參數的地址，第三個參數是fn函數的參數以字節為單位的大小，后面兩個參數我們不用關心。這里需要注意的是，newproc1是在g0的棧上執行的。該函數很長也很重要，所以我們分段來看。
runtime/proc.go : 3248
// Create a new g running fn with narg bytes of arguments starting
// at argp. callerpc is the address of the go statement that created
// this. The new g is put on the queue of g's waiting to run.
func newproc1(fn *funcval, argp *uint8, narg int32, callergp *g, callerpc uintptr) {
//因為已經切換到g0棧，所以無論什么場景都有 _g_ = g0，當然這個g0是指當前工作線程的g0
//對於我們這個場景來說，當前工作線程是主線程，所以這里的g0 = m0.g0
_g_ := getg()
......
_p_ := _g_.m.p.ptr() //初始化時_p_ = g0.m.p，從前面的分析可以知道其實就是allp[0]
newg := gfget(_p_) //從p的本地緩沖里獲取一個沒有使用的g，初始化時沒有，返回nil
if newg == nil {
//new一個g結構體對象，然后從堆上為其分配棧，並設置g的stack成員和兩個stackgard成員
newg = malg(_StackMin)
casgstatus(newg, _Gidle, _Gdead) //初始化g的狀態為_Gdead
//放入全局變量allgs切片中
allgadd(newg) // publishes with a g->status of Gdead so GC scanner doesn't look at uninitialized stack.
}
......
//調整g的棧頂置針，無需關注
totalSize := 4*sys.RegSize+uintptr(siz) +sys.MinFrameSize// extra space in case of reads slightly beyond frame
totalSize += -totalSize&(sys.SpAlign-1) // align to spAlign
sp := newg.stack.hi-totalSize
spArg := sp
......
if narg > 0 {
//把參數從執行newproc函數的棧（初始化時是g0棧）拷貝到新g的棧
memmove(unsafe.Pointer(spArg), unsafe.Pointer(argp), uintptr(narg))
// ......
}
這段代碼主要從堆上分配一個g結構體對象並為這個newg分配一個大小為2048字節的棧，並設置好newg的stack成員，然后把newg需要執行的函數的參數從執行newproc函數的棧（初始化時是g0棧）拷貝到newg的棧，完成這些事情之后newg的狀態如下圖所示：
我們可以看到，經過前面的代碼之后，程序中多了一個我們稱之為newg的g結構體對象，該對象也已經獲得了從堆上分配而來的2k大小的棧空間，newg的stack.hi和stack.lo分別指向了其棧空間的起止位置。
接下來我們繼續分析newproc1函數。
runtime/proc.go : 3314
//把newg.sched結構體成員的所有成員設置為0
memclrNoHeapPointers(unsafe.Pointer(&newg.sched), unsafe.Sizeof(newg.sched))
//設置newg的sched成員，調度器需要依靠這些字段才能把goroutine調度到CPU上運行。
newg.sched.sp = sp //newg的棧頂
newg.stktopsp = sp
//newg.sched.pc表示當newg被調度起來運行時從這個地址開始執行指令
//把pc設置成了goexit這個函數偏移1（sys.PCQuantum等於1）的位置，
//至於為什么要這么做需要等到分析完gostartcallfn函數才知道
newg.sched.pc = funcPC(goexit) + sys.PCQuantum// +PCQuantum so that previous instruction is in same function
newg.sched.g = guintptr(unsafe.Pointer(newg))
gostartcallfn(&newg.sched, fn)//調整sched成員和newg的棧
這段代碼首先對newg的sched成員進行了初始化，該成員包含了調度器代碼在調度goroutine到CPU運行時所必須的一些信息，其中sched的sp成員表示newg被調度起來運行時應該使用的棧的棧頂，sched的pc成員表示當newg被調度起來運行時從這個地址開始執行指令，然而從上面的代碼可以看到，new.sched.pc被設置成了goexit函數的第二條指令的地址而不是fn.fn，這是為什么呢？要回答這個問題，必須深入到gostartcallfn函數中做進一步分析。
// adjust Gobuf as if it executed a call to fn
// and then did an immediate gosave.
func gostartcallfn(gobuf *gobuf, fv *funcval) {
var fn unsafe.Pointer
if fv != nil {
fn = unsafe.Pointer(fv.fn) //fn: gorotine的入口地址，初始化時對應的是runtime.main
} else {
fn = unsafe.Pointer(funcPC(nilfunc))
}
gostartcall(gobuf, fn, unsafe.Pointer(fv))
}
gostartcallfn首先從參數fv中提取出函數地址（初始化時是runtime.main），然后繼續調用gostartcall函數。
// adjust Gobuf as if it executed a call to fn with context ctxt
// and then did an immediate gosave.
func gostartcall(buf *gobuf, fn, ctxt unsafe.Pointer) {
sp := buf.sp//newg的棧頂，目前newg棧上只有fn函數的參數，sp指向的是fn的第一參數
if sys.RegSize > sys.PtrSize {
sp -= sys.PtrSize
*(*uintptr)(unsafe.Pointer(sp)) = 0
}
sp -= sys.PtrSize//為返回地址預留空間，
//這里在偽裝fn是被goexit函數調用的，使得fn執行完后返回到goexit繼續執行，從而完成清理工作
*(*uintptr)(unsafe.Pointer(sp)) = buf.pc//在棧上放入goexit+1的地址
buf.sp = sp//重新設置newg的棧頂寄存器
//這里才真正讓newg的ip寄存器指向fn函數，注意，這里只是在設置newg的一些信息，newg還未執行，
//等到newg被調度起來運行時，調度器會把buf.pc放入cpu的IP寄存器，
//從而使newg得以在cpu上真正的運行起來
buf.pc = uintptr(fn)
buf.ctxt = ctxt
}
gostartcall函數的主要作用有兩個：
-
調整newg的棧空間，把goexit函數的第二條指令的地址入棧，偽造成goexit函數調用了fn，從而使fn執行完成后執行ret指令時返回到goexit繼續執行完成最后的清理工作；
-
重新設置newg.buf.pc 為需要執行的函數的地址，即fn，我們這個場景為runtime.main函數的地址。
調整完成newg的棧和sched成員之后，返回到newproc1函數，我們繼續往下看，
newg.gopc = callerpc //主要用於traceback
newg.ancestors = saveAncestors(callergp)
//設置newg的startpc為fn.fn，該成員主要用於函數調用棧的traceback和棧收縮
//newg真正從哪里開始執行並不依賴於這個成員，而是sched.pc
newg.startpc = fn.fn
......
//設置g的狀態為_Grunnable，表示這個g代表的goroutine可以運行了
casgstatus(newg, _Gdead, _Grunnable)
......
//把newg放入_p_的運行隊列，初始化的時候一定是p的本地運行隊列，其它時候可能因為本地隊列滿了而放入全局隊列
runqput(_p_, newg, true)
......
}
newproc1函數最后這點代碼比較直觀，首先設置了幾個與調度無關的成員變量，然后修改newg的狀態為_Grunnable並把其放入了運行隊列，到此程序中第一個真正意義上的goroutine已經創建完成。
這時newg也就是main goroutine的狀態如下圖所示：
這個圖看起來比較復雜，因為表示指針的箭頭實在是太多了，這里對其稍作一下解釋。
-
首先，main goroutine對應的newg結構體對象的sched成員已經完成了初始化，圖中只顯示了pc和sp成員，pc成員指向了runtime.main函數的第一條指令，sp成員指向了newg的棧頂內存單元，該內存單元保存了runtime.main函數執行完成之后的返回地址，也就是runtime.goexit函數的第二條指令，預期runtime.main函數執行完返回之后就會去執行runtime.exit函數的CALL runtime.goexit1(SB)這條指令；
-
其次，newg已經放入與當前主線程綁定的p結構體對象的本地運行隊列，因為它是第一個真正意義上的goroutine，還沒有其它goroutine，所以它被放在了本地運行隊列的頭部；
-
最后，newg的m成員為nil，因為它還沒有被調度起來運行，也就沒有跟任何m進行綁定。
這一節我們分析了程序中第一個goroutine也就是main goroutine的創建，下一節我們繼續分析它是怎么被主工作線程調度到CPU上去執行的。