詳解Go語言排程迴圈原始碼實現
阿新 • • 發佈：2021-02-21
> 轉載請宣告出處哦~，本篇文章釋出於luozhiyun的部落格： https://www.luozhiyun.com/archives/448
>
> 本文使用的go的原始碼15.7
## 概述
提到"排程"，我們首先想到的就是作業系統對程序、執行緒的排程。作業系統排程器會將系統中的多個執行緒按照一定演算法排程到物理CPU上去執行。雖然執行緒比較輕量，但是在排程時也有比較大的額外開銷。每個執行緒會都佔用 1M 以上的記憶體空間，執行緒切換和恢復暫存器中的內容也需要向系統申請資源。
Go 語言的 Goroutine 可以看作對 thread 加的一層抽象，它更輕量級，不僅減少了上下文切換帶來的額外開銷，Goroutine 佔用的資源也會更少。如建立一個 Goroutine 的棧記憶體消耗為 2 KB，而 thread 佔用 1M 以上空間；thread 建立和銷毀是核心級的，所以都會有巨大的消耗，而 Goroutine 由 Go runtime 負責管理的，建立和銷燬的消耗非常小；Goroutine 的切換成本也比 thread 要小得多。
### G M P 模型
Go 的排程器使用三個結構體來實現 Goroutine 的排程：G M P。
**G**：代表一個 Goroutine，每個 Goroutine 都有自己獨立的棧存放當前的執行記憶體及狀態。可以把一個 G 當做一個任務，當 Goroutine 被調離 CPU 時，排程器程式碼負責把 CPU 暫存器的值儲存在 G 物件的成員變數之中，當 Goroutine 被排程起來執行時，排程器程式碼又負責把 G 物件的成員變數所儲存的暫存器的值恢復到 CPU 的暫存器。
**M**：表示核心執行緒，它本身就與一個核心執行緒進行繫結，每個工作執行緒都有唯一的一個 M 結構體的例項物件與之對應。M 結構體物件除了記錄著工作執行緒的諸如棧的起止位置、當前正在執行的Goroutine 以及是否空閒等等狀態資訊之外，還通過指標維持著與 P 結構體的例項物件之間的繫結關係。
**P**：代表一個虛擬的 Processor 處理器，它維護一個區域性 Goroutine 可執行 G 佇列，工作執行緒優先使用自己的區域性執行佇列，只有必要時才會去訪問全域性執行佇列，這大大減少了鎖衝突，提高了工作執行緒的併發性。每個 G 要想真正執行起來，首先需要被分配一個 P。
除了上面三個結構體以外，還有一個存放所有Runnable 可執行 Goroutine 的容器 schedt。每個Go程式中schedt結構體只有一個例項物件，在程式碼中是一個共享的全域性變數，每個工作執行緒都可以訪問它以及它所擁有的 Goroutine 執行佇列。
下面是G、P、M以及schedt中的全域性佇列的關係：
從上圖可以看出，每個 m 都綁定了一個 P，每個 P 都有一個私有的本地 Goroutine 佇列，m對應的執行緒從本地和全域性 Goroutine 佇列中獲取 Goroutine 並執行，綠色的 G 代表正在執行的 G。
在預設情況下，執行時會將 `GOMAXPROCS` 設定成當前機器的核數，假設一個四核機器會建立四個活躍的作業系統執行緒，每一個執行緒都對應一個執行時中的 M。
## 詳解
### 結構體
G M P 結構體定義於src/runtime/runtime2.go
#### G
```go
type g struct {
// 當前 Goroutine 的棧記憶體範圍 [stack.lo, stack.hi)
stack stack
// 用於排程器搶佔式排程
stackguard0 uintptr
_panic *_panic
_defer *_defer
// 當前 Goroutine 佔用的執行緒
m *m
// 儲存 Goroutine 的排程相關的資料
sched gobuf
// Goroutine 的狀態
atomicstatus uint32
// 搶佔訊號
preempt bool // preemption signal, duplicates stackguard0 = stackpreempt
// 搶佔時將狀態修改成 `_Gpreempted`
preemptStop bool // transition to _Gpreempted on preemption; otherwise, just deschedule
// 在同步安全點收縮棧
preemptShrink bool // shrink stack at synchronous safe point
...
}
```
下面看看gobuf結構體，主要在排程器儲存或者恢復上下文的時候用到：
```go
type gobuf struct {
// 棧指標
sp uintptr
// 程式計數器
pc uintptr
// gobuf對應的Goroutine
g guintptr
// 系統呼叫的返回值
ret sys.Uintreg
...
}
```
在執行過程中，G可能處於以下幾種狀態：
```go
const (
// 剛剛被分配並且還沒有被初始化
_Gidle = iota // 0
// 沒有執行程式碼，沒有棧的所有權，儲存在執行佇列中
_Grunnable // 1
// 可以執行程式碼，擁有棧的所有權，被賦予了核心執行緒 M 和處理器 P
_Grunning // 2
// 正在執行系統呼叫，擁有棧的所有權，沒有執行使用者程式碼，
// 被賦予了核心執行緒 M 但是不在執行佇列上
_Gsyscall // 3
// 由於執行時而被阻塞，沒有執行使用者程式碼並且不在執行佇列上，
// 但是可能存在於 Channel 的等待佇列上
_Gwaiting // 4
// 表示當前goroutine沒有被使用，沒有執行程式碼，可能有分配的棧
_Gdead // 6
// 棧正在被拷貝，沒有執行程式碼，不在執行佇列上
_Gcopystack // 8
// 由於搶佔而被阻塞，沒有執行使用者程式碼並且不在執行佇列上，等待喚醒
_Gpreempted // 9
// GC 正在掃描棧空間，沒有執行程式碼，可以與其他狀態同時存在
_Gscan = 0x1000
...
)
```
上面的狀態看起來很多，但是實際上只需要關注下面幾種就好了：
* 等待中：_ Gwaiting、_Gsyscall 和 _Gpreempted，這幾個狀態表示G沒有在執行；
* 可執行：_Grunnable，表示G已經準備就緒，可以線上程執行;
* 執行中：_Grunning，表示G正在執行；
#### M
Go 語言併發模型中的 M 是作業系統執行緒，最多隻會有 `GOMAXPROCS` 個活躍執行緒能夠正常執行。
```go
type m struct {
// 持有排程棧的 Goroutine
g0 *g
// 處理 signal 的 G
gsignal *g
// 執行緒本地儲存 thread-local
tls [6]uintptr // thread-local storage (for x86 extern register)
// 當前執行的G
curg *g // current running goroutine
caughtsig guintptr // goroutine running during fatal signal
// 正在執行程式碼的P
p puintptr // attached p for executing go code (nil if not executing go code)
nextp puintptr
// 之前使用的P
oldp puintptr
...
}
```
#### P
排程器中的處理器 P 是執行緒 M 和 G 的中間層，用於排程 G 在 M 上執行。
```go
type p struct {
id int32
// p 的狀態
status uint32
// 排程器呼叫會+1
schedtick uint32 // incremented on every scheduler call
// 系統呼叫會+1
syscalltick uint32 // incremented on every system call
// 對應關聯的 M
m muintptr
mcache *mcache
pcache pageCache
// defer 結構池
deferpool [5][]*_defer
deferpoolbuf [5][32]*_defer
// 可執行的 Goroutine 佇列，可無鎖訪問
runqhead uint32
runqtail uint32
runq [256]guintptr
// 快取可立即執行的 G
runnext guintptr
// 可用的 G 列表，G 狀態等於 Gdead
gFree struct {
gList
n int32
}
...
}
```
下面看看P的幾個狀態：
```go
const (
// 表示P沒有執行使用者程式碼或者排程器
_Pidle = iota
// 被執行緒 M 持有，並且正在執行使用者程式碼或者排程器
_Prunning
// 沒有執行使用者程式碼，當前執行緒陷入系統呼叫
_Psyscall
// 被執行緒 M 持有，當前處理器由於垃圾回收 STW 被停止
_Pgcstop
// 當前處理器已經不被使用
_Pdead
)
```
#### sched
sched 我們在上面也提到了，主要存放了排程器持有的全域性資源，如空閒的 P 連結串列、 G 的全域性佇列等。
```go
type schedt struct {
...
lock mutex
// 空閒的 M 列表
midle muintptr
// 空閒的 M 列表數量
nmidle int32
// 下一個被建立的 M 的 id
mnext int64
// 能擁有的最大數量的 M
maxmcount int32
// 空閒 p 連結串列
pidle puintptr // idle p's
// 空閒 p 數量
npidle uint32
// 處於 spinning 狀態的 M 的數量
nmspinning uint32
// 全域性 runnable G 佇列
runq gQueue
runqsize int32
// 有效 dead G 的全域性快取.
gFree struct {
lock mutex
stack gList // Gs with stacks
noStack gList // Gs without stacks
n int32
}
// sudog 結構的集中快取
sudoglock mutex
sudogcache *sudog
// defer 結構的池
deferlock mutex
deferpool [5]*_defer
...
}
```
### 從Go程式啟動講起
這裡還是藉助dlv來進行除錯。有關 dlv 如何斷點彙編的內容我在這一篇：https://www.luozhiyun.com/archives/434 《詳解Go中記憶體分配原始碼實現》已經有很詳細的介紹了，感興趣的可以去看看。需要注意的是這裡有個坑，下面的例子是在Linux中進行的。
首先我們寫一個非常簡單的例子：
```go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
```
然後進行構建：
```
go build main.go
dlv exec ./main
```
開打程式後按步驟輸入下面的命令：
```
(dlv) r
Process restarted with PID 33191
(dlv) list
> _rt0_amd64_linux() /usr/local/go/src/runtime/rt0_linux_amd64.s:8 (PC: 0x4648c0)
Warning: debugging optimized function
Warning: listing may not match stale executable
3: // license that can be found in the LICENSE file.
4:
5: #include "textflag.h"
6:
7: TEXT _rt0_amd64_linux(SB),NOSPLIT,$-8
=> 8: JMP _rt0_amd64(SB)
9:
10: TEXT _rt0_amd64_linux_lib(SB),NOSPLIT,$0
11: JMP _rt0_amd64_lib(SB)
(dlv) si
> _rt0_amd64() /usr/local/go/src/runtime/asm_amd64.s:15 (PC: 0x4613e0)
Warning: debugging optimized function
Warning: listing may not match stale executable
10: // _rt0_amd64 is common startup code for most amd64 systems when using
11: // internal linking. This is the entry point for the program from the
12: // kernel for an ordinary -buildmode=exe program. The stack holds the
13: // number of arguments and the C-style argv.
14: TEXT _rt0_amd64(SB),NOSPLIT,$-8
=> 15: MOVQ 0(SP), DI // argc
16: LEAQ 8(SP), SI // argv
17: JMP runtime·rt0_go(SB)
18:
19: // main is common startup code for most amd64 systems when using
20: // external linking. The C startup code will call the symbol "main"
(dlv)
```
通過上面的斷點可以知道在linux amd64系統的啟動函式是在asm_amd64.s的runtime·rt0_go函式中。當然，不同的平臺有不同的程式入口，感興趣的同學可以自行去了解。
下面我們看看`runtime·rt0_go`：
```
TEXT runtime·rt0_go(SB),NOSPLIT,$0
...
// 初始化執行檔案的絕對路徑
CALL runtime·args(SB)
// 初始化 CPU 個數和記憶體頁大小
CALL runtime·osinit(SB)
// 排程器初始化
CALL runtime·schedinit(SB)
// 建立一個新的 goroutine 來啟動程式
MOVQ $runtime·mainPC(SB), AX // entry
// 新建一個 goroutine，該 goroutine 繫結 runtime.main
CALL runtime·newproc(SB)
// 啟動M，開始排程goroutine
CALL runtime·mstart(SB)
...
```
上面的CALL方法中：
schedinit進行各種執行時元件初始化工作，這包括我們的排程器與記憶體分配器、回收器的初始化；
newproc負責根據主 G 入口地址建立可被執行時排程的執行單元；
mstart開始啟動排程器的排程迴圈；
#### 排程初始化 runtime.schedinit
```go
func schedinit() {
...
_g_ := getg()
...
// 最大執行緒數10000
sched.maxmcount = 10000
// M0 初始化
mcommoninit(_g_.m, -1)
...
// 垃圾回收器初始化
gcinit()
sched.lastpoll = uint64(nanotime())
// 通過 CPU 核心數和 GOMAXPROCS 環境變數確定 P 的數量
procs := ncpu
if n, ok := atoi32(gogetenv("GOMAXPROCS")); ok && n > 0 {
procs = n
}
// P 初始化
if procresize(procs) != nil {
throw("unknown runnable goroutine during bootstrap")
}
...
}
```
schedinit函式會將 maxmcount 設定成10000，這也就是一個 Go 語言程式能夠建立的最大執行緒數。然後呼叫 mcommoninit 對 M0 進行初始化，通過 CPU 核心數和 GOMAXPROCS 環境變數確定 P 的數量之後就會呼叫 procresize 函式對 P 進行初始化。
#### M0 初始化
```go
func mcommoninit(mp *m, id int64) {
_g_ := getg()
...
lock(&sched.lock)
// 如果傳入id小於0，那麼id則從mReserveID獲取，初次從mReserveID獲取id為0
if id >= 0 {
mp.id = id
} else {
mp.id = mReserveID()
}
//random初始化，用於竊取 G
mp.fastrand[0] = uint32(int64Hash(uint64(mp.id), fastrandseed))
mp.fastrand[1] = uint32(int64Hash(uint64(cputicks()), ^fastrandseed))
if mp.fastrand[0]|mp.fastrand[1] == 0 {
mp.fastrand[1] = 1
}
// 建立用於訊號處理的gsignal，只是簡單的從堆上分配一個g結構體物件,然後把棧設定好就返回了
mpreinit(mp)
if mp.gsignal != nil {
mp.gsignal.stackguard1 = mp.gsignal.stack.lo + _StackGuard
}
// 把 M 掛入全域性連結串列allm之中
mp.alllink = allm
...
}
```
這裡傳入的 id 是-1，初次呼叫會將 id 設定為 0，這裡並未對m0做什麼關於排程相關的初始化，所以可以簡單的認為這個函式只是把m0放入全域性連結串列allm之中就返回了。
#### P 初始化
**runtime.procresize**
```go
var allp []*p
func procresize(nprocs int32) *p {
// 獲取先前的 P 個數
old := gomaxprocs
// 更新統計資訊
now := nanotime()
if sched.procresizetime != 0 {
sched.totaltime += int64(old) * (now - sched.procresizetime)
}
sched.procresizetime = now
// 根據 runtime.MAXGOPROCS 調整 p 的數量,因為 runtime.MAXGOPROCS 使用者可以自行設定
if nprocs > int32(len(allp)) {
lock(&allpLock)
if nprocs <= int32(cap(allp)) {
allp = allp[:nprocs]
} else {
nallp := make([]*p, nprocs)
copy(nallp, allp[:cap(allp)])
allp = nallp
}
unlock(&allpLock)
}
// 初始化新的 P
for i := old; i < nprocs; i++ {
pp := allp[i]
// 為空,則申請新的 P 物件
if pp == nil {
pp = new(p)
}
pp.init(i)
atomicstorep(unsafe.Pointer(&allp[i]), unsafe.Pointer(pp))
}
_g_ := getg()
// P 不為空,並且 id 小於 nprocs ,那麼可以繼續使用當前 P
if _g_.m.p != 0 && _g_.m.p.ptr().id < nprocs {
// continue to use the current P
_g_.m.p.ptr().status = _Prunning
_g_.m.p.ptr().mcache.prepareForSweep()
} else {
// 釋放當前 P，因為已失效
if _g_.m.p != 0 {
_g_.m.p.ptr().m = 0
}
_g_.m.p = 0
p := allp[0]
p.m = 0
p.status = _Pidle
// P0 繫結到當前的 M0
acquirep(p)
}
// 從未使用的 P 釋放資源
for i := nprocs; i < old; i++ {
p := allp[i]
p.destroy()
// 不能釋放 p 本身，因為他可能在 m 進入系統呼叫時被引用
}
// 釋放完 P 之後重置allp的長度
if int32(len(allp)) != nprocs {
lock(&allpLock)
allp = allp[:nprocs]
unlock(&allpLock)
}
var runnablePs *p
// 將沒有本地任務的 P 放到空閒連結串列中
for i := nprocs - 1; i >