关于go:22-GolangGo并发编程协程管理

  上一篇文章咱们介绍了 GMP 并发模型的基本概念，晓得了 M 是线程，P 是逻辑处理器，G 是协程。也理解到每一个 M 线程都有一个调度协程 g0，调度主逻辑由函数 schedule 实现；协程都有本人的协程栈，协程的切换其实就是协程栈的切换，其实就是若干寄存器的保留与复原。本篇文章重点介绍协程的治理，包含协程创立，协程切换；然而，波及到寄存器的更改，只能深刻到汇编去了解，可能会比拟干燥难以了解，能够依据本人趣味学习钻研。

根底补充 - 栈桢构造

  咱们始终说每一个线程都有一个线程栈，每一个协程也须要一个协程栈，这里说的栈其实就是函数调用栈桢，通常咱们函数内申明的局部变量，函数的传参等，其实都在线程栈 / 协程栈上。为什么这里称之为栈呢？因为函数的调用与返回，刚好是先入后出，函数的调用随同着函数栈桢的入栈，函数的返回随同着函数栈桢的出栈。多个函数栈桢之间是通过 BP 以及 SP 寄存器保护的。

  另外，咱们还须要晓得，所有的高级语言，不论是 PHP 还是 Java 还是 Go，最终机器上执行的都是一条一条汇编指令（应该说是二进制指令，汇编只是不便人们辨认的助记符）；函数调用指令是 CALL，函数返回指令是 RET。CALL 以及 RET 与其余指令如 MOVE 有一些不同，背地还有一些略微简单的逻辑：

//PC 寄存器指向的是下一条指令地址；CPU 加载指令时，会主动 PC + 1；所以能够通过批改 PC 寄存器的内容，实现程序跳转

//CALL fn
PUSH PC    //PUSH 将 PC 内容入栈（其实也就是 SP = PC；SP = SP - 8）JMP fn     // 程序跳转到函数 fn 入口地址

//RET
POP PC     //POP 弹出栈顶内容，也就是之前 PUSH 的 PC 寄存器内容
JMP        // 程序跳转到 PC 执行的地址 

  最初，寄存器 BP 以及 SP 的保护，查看编译后的汇编程序就能看到，比方：

"".fn STEXT
    //SP 栈顶向下挪动（函数栈桢入栈），以后函数可能会定义一些局部变量等，所以预留一些内存
    SUBQ    $96, SP
    // 下一步须要更高 BP 寄存器内容，所以将 BP 寄存器保留在 SP+88 字节地位处
    MOVQ    BP, 88(SP)
    // 更改 BP 寄存器内容
    LEAQ    88(SP), BP

    // 业务逻辑
    // 局部变量通常以 XX(SP) 模式拜访，也就是在 SP+XX 字节地位处

    // 复原原始 BP 寄存器内容
    MOVQ    88(SP), BP
    //SP 栈顶向上挪动（函数栈桢出栈）ADDQ    $96, SP
    // 函数返回
    RET

  调用 fn 函数前后的栈桢构造如下图所示：

  这里须要咱们重点了解 CALL & RET 指令的含意，以及调用 fn 函数前后的栈桢变动。因为 Go 语言在协程创立的时候，须要结构协程栈，也就是上图中的栈桢构造。

根底补充 - 线程本地存储

  线程本地存储 (Thread Local Storage，简称 TLS)，其实就是线程公有全局变量。一般的全局变量，一个线程对其进行了批改，所有线程都能够看到这个批改；线程公有全局变量不同，每个线程都有本人的一份正本，某个线程对其所做的批改不会影响到其它线程的正本。

  Golang 是多线程程序，以后线程正在执行的协程，显然每个线程都是不同的，这就保护在线程本地存储。所以在 Go 协程切换逻辑中，随处可见 get_tls(CX)，用于获取以后线程本地存储首地址。

  不同的架构以及操作系统，能够通过 FS 或者 GS 寄存器拜访线程本地存储，如 Go 程序，386 架构 Linux 操作系统时，通过如下形式拜访：

//"386", "linux"
"#define    get_tls(r)    MOVL 8(GS), r\n"

// 获取线程本地存储首地址
get_tls(CX)
// 构造体 G 封装协程相干数据，DX 存储着以后正在执行协程 G 的首地址
// 协程调度时，保留以后协程 G 到线程本地存储
MOVQ    DX, g(CX)

根底补充 - 汇编简介

  任何架构的计算机都会提供一组指令汇合，汇编是二进制指令的文本模式。指令由操作码和操作数组成；操作码即操作类型，操作数能够是一个立刻数或者一个存储地址（内存，寄存器）。寄存器是集成在 CPU 外部，拜访十分快，然而数量无限的存储单元。Golang 应用 plan9 汇编语法，汇编指令的写法以及寄存器的命名略有不同

  上面简略介绍一些罕用的指令以及寄存器：

• MOVQ $10, AX：数据挪动指令，该指令示意将立刻数 10 存储在寄存器 AX；AX 即通用寄存器，罕用的通用寄存器还有 BX，CX，DX 等等；留神指令后缀『Q』示意数据长度为 8 字节；
• ADDQ AX, BX：加法指令，等价于 BX += AX；
• SUBQ AX, BX：减法指令，等价于 BX -= AX；
• JMP addr：跳转道 addr 地址处继续执行；
• JMP 2(PC)：CPU 如何加载指令并执行呢？其实有个专用寄存器 PC（等价于 %rip），他指向下一条待执行的指令。该语句含意是，以以后指令为根底，向后跳转 2 行；
• FP：伪寄存器，通过 symbol+offset(FP) 模式，援用函数的输出参数，例如 arg0+0(FP)，arg1+8(FP)；
• 硬件寄存器 SP：等价于下面呈现过的 %rsp，执行函数栈帧顶部地位）；
• CALL func：函数调用，蕴含两个步骤，1）将下一条指令的所在地址入栈（还须要复原到这执行）；2）将 func 地址，存储在指令寄存器 PC；
• RET：函数返回，性能为，从栈上弹出指令到指令寄存器 PC，复原调用方函数的执行（CALL 指令入栈）；

  更多 plan9 常识参考：https://xargin.com/plan9-asse…

  上面写一个 go 程序，看看编译后的汇编代码：

package main

func addSub(a, b int) (int, int){return a + b , a - b}

func main() {addSub(333, 222)
}

  汇编代码查看：go tool compile -S -N -l test.go

"".addSub STEXT nosplit size=49 args=0x20 locals=0x0
    0x0000 00000 (test.go:3)    MOVQ    $0, "".~r2+24(SP)
    0x0009 00009 (test.go:3)    MOVQ    $0, "".~r3+32(SP)
    0x0012 00018 (test.go:4)    MOVQ    "".a+8(SP), AX
    0x0017 00023 (test.go:4)    ADDQ    "".b+16(SP), AX
    0x001c 00028 (test.go:4)    MOVQ    AX, "".~r2+24(SP)
    0x0021 00033 (test.go:4)    MOVQ    "".a+8(SP), AX
    0x0026 00038 (test.go:4)    SUBQ    "".b+16(SP), AX
    0x002b 00043 (test.go:4)    MOVQ    AX, "".~r3+32(SP)
    0x0030 00048 (test.go:4)    RET
    
"".main STEXT size=68 args=0x0 locals=0x28
    0x000f 00015 (test.go:7)      SUBQ    $40, SP
    0x0013 00019 (test.go:7)      MOVQ    BP, 32(SP)
    0x0018 00024 (test.go:7)      LEAQ    32(SP), BP
    0x001d 00029 (test.go:8)      MOVQ    $333, (SP)
    0x0025 00037 (test.go:8)      MOVQ    $222, 8(SP)
    0x002e 00046 (test.go:8)      CALL    "".addSub(SB)
    0x0033 00051 (test.go:9)      MOVQ    32(SP), BP
    0x0038 00056 (test.go:9)      ADDQ    $40, SP
    0x003c 00060 (test.go:9)      RET

  剖析 main 函数汇编代码：SUBQ $40, SP 为本人调配栈帧区域，LEAQ 32(SP), BP，挪动 BP 寄存器到本人栈帧构造的底部。MOVQ $333, (SP) 以及 MOVQ $222, 8(SP) 在筹备输出参数。

  剖析 addSub 函数汇编代码：””.a+8(SP) 即输出参数 a，””.b+16(SP) 即输出参数 b。两个返回值别离在 24(SP) 以及 32(SP)。

  留神：addSub 函数，并没有通过 SUBQ $xx, SP 以，来为本人调配栈帧区域。因为 addSub 函数没有再调用其余函数，也就没有必要在为本人调配函数栈帧区域了。

  另外，留神 main 函数，addSub 函数，是如何传递与援用输出参数以及返回值的。

协程创立

  go 关键字在编译阶段会替换为函数 runtime.newproc(fn * funcval)，其中 fn 就是待创立协程的入口函数。协程创立必定是须要调配协程栈内存的，执行过程略微简单，不适宜在协程栈执行（协程栈比拟小，Go 语言默认 2K 字节，执行过于简单的逻辑可能导致栈溢出），所以协程创立的逻辑都会切换到线程栈（即零碎栈），协程创立结束后，再切换到原来的栈。函数 runtime.systemstack(fn func()) 切换到零碎栈执行函数 fn，结束后再切换到原来的栈，应用形式如下：

func newproc(fn *funcval) {systemstack(func() {newg := newproc1(fn, gp, pc)

        // 将 g 增加到 P 的协程队列
        _p_ := getg().m.p.ptr()
        runqput(_p_, newg, true)
    })
}

  能够看到，协程创立的次要逻辑，其实是由 runtime.newproc1 实现的，而通过函数 runqput 能够将以后协程 g 增加到以后 M 绑定 P 的协程队列。函数 runtime.newproc1 不仅仅要申请协程栈内存，还须要结构初始的栈桢构造，包含设置 BP & SP 栈寄存器，以及 PC 指令寄存器。

func newproc1(fn *funcval, callergp *g, callerpc uintptr) *g {
    //_StackMin = 2048
    newg = malg(_StackMin)

    //sp 指向栈顶（stack.hi 为栈最高地址，预留 totalSize）sp := newg.stack.hi - totalSize
    newg.sched.sp = sp

    //goexit 为协程退出函数
    newg.sched.pc = goexit

    // 结构栈桢构造，fn 为协程入口函数（省略了一层调用）gostartcall(&newg.sched, fn)

    // 设置协程状态：可运行
    casgstatus(newg, xxx, _Grunnable)

    // 协程 ID
    newg.goid = int64(_p_.goidcache)
    _p_.goidcache++

    return newg
}

// 申请栈内存，初始化 g 构造
func malg(stacksize int32) *g {newg := new(g)
    // 申请内存
    newg.stack = stackalloc(uint32(stacksize))
    //stackguard0 用于爱护栈，防止栈溢出；函数调用过程中，sp 不能小于 stackguard0 地位
    newg.stackguard0 = newg.stack.lo + _StackGuard
    *(*uintptr)(unsafe.Pointer(newg.stack.lo)) = 0
    return newg
}

// 结构栈桢构造
func gostartcall(buf *gobuf, fn) {
    //buf.pc 即 goexit，保留到栈顶
    sp := buf.sp
    sp -= goarch.PtrSize
    *(*uintptr)(unsafe.Pointer(sp)) = buf.pc

    // 设置上下文 sp pc
    buf.sp = sp
    buf.pc = uintptr(fn)
}

  能够看到，申请栈内存时最小 2048=2K 字节，目前 linux 零碎线程栈默认大小个别为 8M，也就是说协程占用的资源远小于线程，所以才会说协程是轻量级的线程。stackguard0 是为了避免栈溢出的，编译阶段 Go 语言在函数入口会增加一些逻辑：判断 SP 寄存器是否小于 stackguard0，如果小于阐明栈行将溢出，此时能够间接抛异样，也能够触发栈扩容等。最初留神到，整个过程只是创立了协程，并没有立刻运行该协程，而是将协程状态赋值为可运行 Grunnable，随后增加将其增加到 P 的协程队列，期待 M 调度。

  协程能够在队列中期待调度，或者被 M 调度执行，或者因为获取锁等起因阻塞，或者执行结束。协程与线程相似，有多个状态，能够在不同状态之间转移，Go 语言定义的协程状态如下：

// _Gidle means this goroutine was just allocated and has not yet been initialized.
_Gidle = iota // 0

// _Grunnable means this goroutine is on a run queue
_Grunnable // 1

// _Grunning means this goroutine may execute user code
_Grunning // 2

// _Gsyscall means this goroutine is executing a system call.
_Gsyscall // 3

// _Gwaiting means this goroutine is blocked in the runtime.
_Gwaiting // 4

// _Gdead means this goroutine is currently unused. It may be just exited, on a free list
_Gdead // 6

// _Gcopystack means this goroutine's stack is being moved.
_Gcopystack // 8

  各状态转移图如下：

协程（栈）切换

  协程调度主函数为 runtime.schedule，查找到可运行协程之后，通过 runtime.gogo 函数切换到协程栈，这个函数就只能看到汇编代码了，因为要操作寄存器：

// func gogo(buf *gobuf)
TEXT runtime·gogo(SB), NOSPLIT, $0-8
    MOVQ    buf+0(FP), BX        // gobuf 蕴含协程上下文：栈寄存器 BP、SP，指令寄存器 PC
    MOVQ    gobuf_g(BX), DX
    MOVQ    0(DX), CX            // make sure g != nil
    JMP    gogo<>(SB)

TEXT gogo<>(SB), NOSPLIT, $0
    get_tls(CX)                 // 线程本地存储    
    MOVQ    DX, g(CX)           // 存储待执行协程 g 到线程本地存储
    MOVQ    DX, R14                // 存储待执行协程 g 到 R14 寄存器（其余中央会用到 R14 寄存器）MOVQ    gobuf_sp(BX), SP    // 依据 gobuf 上下文，设置各寄存器
    MOVQ    gobuf_ret(BX), AX
    MOVQ    gobuf_ctxt(BX), DX
    MOVQ    gobuf_bp(BX), BP
    MOVQ    $0, gobuf_sp(BX)    // 清空 gobuf 各字段内容，以加重垃圾回收累赘（指针字段不为空时，垃圾回收须要扫描）MOVQ    $0, gobuf_ret(BX)
    MOVQ    $0, gobuf_ctxt(BX)
    MOVQ    $0, gobuf_bp(BX)
    MOVQ    gobuf_pc(BX), BX
    JMP    BX

  协程 g.gobuf 存储了协程上下文数据，包含栈桢寄存器 BP、SP，以及指令寄存器 PC，所以 runtime.gogo 只须要依据 gobuf 复原各寄存器即可。为了在各函数中能疾速获取以后执行协程，将以后执行协程 g 存储在了线程本地存储（也就是 M 的公有存储）；另外，以后执行协程还保留到了 R14 寄存器，协程因为某些起因阻塞换出的时候，就用到了 R14 寄存器。

  须要特地留神，gobuf_sp、gobuf_bp 之类的，并不是汇编语法，其实是宏定义，编译阶段主动生成这些宏定义。gobuf_sp 的含意是：sp 字段在 gobuf 构造的偏移量，即 offset(gobuf,sp)。

  协程换出是通过 runtime.gopark 函数实现的，最终是通过 runtime.mcall 函数保留以后函数上下文，同时切换到零碎栈执行调度算法。

// 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.
TEXT runtime·mcall<ABIInternal>(SB), NOSPLIT, $0-8
    MOVQ    AX, DX    // DX = fn

    // 保留协程上下文，R14 寄存器就是以后协程 g
    MOVQ    0(SP), BX    // caller's PC
    MOVQ    BX, (g_sched+gobuf_pc)(R14)
    LEAQ    fn+0(FP), BX    // caller's SP
    MOVQ    BX, (g_sched+gobuf_sp)(R14)
    MOVQ    BP, (g_sched+gobuf_bp)(R14)

    // 要求以后协程 g != m->g0
    // switch to m->g0 & its stack, call fn
    MOVQ    g_m(R14), BX
    MOVQ    m_g0(BX), SI    // SI = g.m.g0
    CMPQ    SI, R14    // if g == m->g0 call badmcall
    JNE    goodm
    JMP    runtime·badmcall(SB)

goodm:
    MOVQ    R14, AX        // AX (and arg 0) = g
    MOVQ    SI, R14        // g = g.m.g0
    get_tls(CX)        // Set G in TLS
    MOVQ    R14, g(CX)
    MOVQ    (g_sched+gobuf_sp)(R14), SP    // sp = g0.sched.sp；设置栈顶寄存器 SP
    PUSHQ    AX    // open up space for fn's arg spill slot；设置 fn 参数，也就是行将换出的协程 g
    MOVQ    0(DX), R12
    CALL    R12        // fn(g)；调用 fn
    POPQ    AX
    JMP    runtime·badmcall2(SB)
    RET

  runtime.mcall 函数用于切换到零碎栈，执行函数 fn，runtime.systemstack 函数也是切换到零碎栈，执行函数 fn。不同的是：systemstack 执行完 fn，返回；而 mcall 要求 fn 函数永远不能返回，否则抛出 panic 异样。

协程栈会溢出吗

  协程就是轻量级的线程，创立协程时申请的协程栈大小只有 2K，这挺好的。不过，你有没有想过，如果协程比较复杂，函数调用层级过深，会呈现什么状况，比方你运行上面的程序：

package main

import "fmt"

func main() {r := fn(100000)
    fmt.Println(r)
}

func fn(n int) int {var arr [100000]int
    for i := 0; i < 10; i ++ {arr[i] = i
    }
    return fn(n-1) + 1
}

  这个程序没有任何意义，只是为了模仿深层次的函数调用。执行后，你会发现，程序异样终止了：”runtime: goroutine stack exceeds 1000000000-byte limit”。协程栈超过 1000000000-byte 大小限度了，也就是栈溢出了。初始协程栈不是只有 2K 吗，大小限度怎么能是 1000000000-byte 呢？

  想想要是协程栈大小真的最多只有 2K 大小，是不是太小了，也太容易呈现栈溢出状况了。可是创立协程时申请的协程栈大小只有 2K 啊，难道函数调用过程中，协程栈扩容了？你猜对了。协程栈只有产生函数调用时，才有可能须要扩容，所以 Go 语言编译阶段，在所有用户函数，都加了一点代码逻辑，判断栈顶指针 SP 小于某个地位时，阐明栈空间有余，须要扩容了；这个地位就是 stackguard0。咱们看看 main 函数的汇编代码：

"".main STEXT
0x0000 00000 (test.go:5)    CMPQ    SP, 16(R14)
0x0004 00004 (test.go:5)    JLS    176

0x00b0 00176 (test.go:5)    CALL    runtime.morestack_noctxt(SB)
0x00e0 00224 (test.go:10)    JMP    0

  R14 寄存器就是以后协程 g，想想构造体 g 的第一个字段 stack 占 16 字节，第二个字段就是 stackguard0，所以这里比拟栈顶 SP 寄存器与 16(R14) 地址大小；如果小于阐明栈空间有余，调用 runtime.morestack_noctxt。函数 morestack_noctxt 也是汇编写的，一系列判断之后，最终调用了函数 runtime.newstack 执行扩容等操作。待扩容之后，又跳转到该函数第一条指令执行。

  扩容个别依照 2 倍大小扩容，如果扩容后大小超过 maxstacksize 限度（64 位机器就是 1000000000-byte），则抛异样。

  栈扩容并没有咱们想的那么简略，只须要申请内存，拷贝数据就行了。想想万一某些指针变量指向了栈地址呢？栈扩容拷贝之后，指针变量还须要非凡解决（依据新的栈首地址与老的栈首地址偏移量从新计算）。另外，其实还有一些其余你想不到的 ” 数据 ” 也是须要解决的。能够参考 runtime.copystack 函数：

func copystack(gp *g, newsize uintptr) {
    // 拷贝数据
    memmove(unsafe.Pointer(new.hi-ncopy), unsafe.Pointer(old.hi-ncopy), ncopy)

    // 调整非凡数据
    adjustsudogs(gp, &adjinfo)
    adjustctxt(gp, &adjinfo)
    adjustdefers(gp, &adjinfo)
    adjustpanics(gp, &adjinfo)

    adjustframe()}

协程完结

  设想下，如果某协程的处理函数为 funcA，funcA 执行结束，相当于该协程的完结。这之后该怎么办？必定须要执行特定的回收工作。留神到下面协程创立的时候有一个函数，runtime·goexit，看名字协程完结时候应该执行这个函数。如何在 funcA 执行结束后，调用 runtime·goexit 呢？

  思考下函数调用过程，函数 funcA 执行结束时候，存在一个 RET 指令，该指令会弹出下一条待执行指令到指令寄存器 PC，从而实现指令的跳转。咱们再回顾协程创立的实现逻辑：

func newproc1(fn *funcval, callergp *g, callerpc uintptr) *g {
    //goexit 为协程退出函数
    newg.sched.pc = goexit

    // 结构栈桢构造，fn 为协程入口函数（省略了一层调用）gostartcall(&newg.sched, fn)

    return newg
}

// 结构栈桢构造
func gostartcall(buf *gobuf, fn) {
    //buf.pc 即 goexit，保留到栈顶
    sp := buf.sp
    sp -= goarch.PtrSize
    *(*uintptr)(unsafe.Pointer(sp)) = buf.pc
}

  函数 gostartcall 首先将 runtime·goexit 首地址入栈，尔后执行 fn 的时候才是 fn 函数栈桢入栈。因而协程 fn 执行完结后，RET 弹出的指令就是函数 runtime·goexit 首地址，从而开始了协程回收工作。而函数 runtime·goexit，则标记协程状态为 Gmoribund，开始新一次的协程调度（会切换到 g0 调度）

void runtime·goexit(void)
{mcall(goexit0)
}

// 曾经在零碎栈了
func goexit0(gp *g) {
    // 设置协程状态，执行回收操作
    casgstatus(gp, _Grunning, _Gdead)

    // 调度
    schedule()}

总结

  这一篇文章的确比拟难，须要相熟汇编，相熟函数调用栈桢构造，否则必定会看的云里雾里的。本篇文章重点介绍了协程创立，协程切换，协程完结，协程栈裁减等的简略实现原理，置信这下你能明确为什么说协程是轻量级的、用户态的线程了。