GMP 调度器：goroutine 如何被执行

第十四章：GMP 调度器 — goroutine 如何被执行

你写下 go func(){}() 的那一刻，Go 运行时就面临一个核心问题：这个函数该由谁来执行？在哪颗 CPU 上执行？什么时候执行？ 这不是一个简单的线程创建——Go 需要在有限的操作系统线程上，高效地调度数以万计的 goroutine。解决这个问题的机制，就是 GMP 调度器。

GMP 调度器是 Go 语言并发能力的根基。理解它，你就理解了为什么 goroutine 比线程轻量、为什么 Go 能轻松处理百万并发、为什么有些 goroutine 会"饿死"、以及为什么 GOMAXPROCS 的设置如此重要。

本章从直觉层面出发，逐层深入到源码实现和设计决策，帮助你建立完整的调度器心智模型。

Level 1 · 你需要知道的

1.1 goroutine 比线程轻量的原因

每个初学 Go 的人都会听到一句话："goroutine 很轻量"。但轻量在哪里？让我们用具体数据说话。

栈大小对比：

这些数字背后有三个关键的技术差异：

第一，goroutine 使用动态增长栈。 操作系统线程的栈大小在创建时就固定了，因为内核无法在运行时安全地迁移栈帧。而 goroutine 的栈由 Go 运行时管理——初始只有 2 KB，当函数调用深度增加时，运行时检测到栈空间不足，会分配一个两倍大的新栈，把旧栈内容复制过去，然后调整所有指向旧栈的指针。这就是所谓的"栈复制"（stack copying）机制，在 Go 1.3 中取代了之前的"分段栈"（segmented stack）方案。

// 验证 goroutine 初始栈大小
package main

import (
    "fmt"
    "runtime"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    n := 100000
    wg.Add(n)
    
    var m runtime.MemStats
    runtime.ReadMemStats(&m)
    before := m.Sys
    
    for i := 0; i < n; i++ {
        go func() {
            select {} // 阻塞，保持 goroutine 存活
        }()
    }
    
    runtime.ReadMemStats(&m)
    after := m.Sys
    
    fmt.Printf("创建 %d 个 goroutine\n", n)
    fmt.Printf("内存增长: %.2f MB\n", float64(after-before)/1024/1024)
    fmt.Printf("每个 goroutine 约: %.2f KB\n", float64(after-before)/float64(n)/1024)
}

第二，goroutine 切换不需要陷入内核。 操作系统线程的上下文切换需要从用户态进入内核态（syscall 或中断），保存/恢复完整的 CPU 寄存器组（包括浮点寄存器、SSE 寄存器等），刷新 TLB 缓存。而 goroutine 的切换完全在用户态完成，只需要保存少量寄存器（SP、PC、以及少数几个 callee-saved 寄存器），总共约 40-50 字节的状态。

第三，goroutine 的创建不需要系统调用。 创建一个 OS 线程需要 clone() 系统调用（Linux）或 CreateThread()（Windows），这意味着陷入内核、分配内核数据结构、设置 TLS 等。而创建 goroutine 只需要在用户态从空闲池中取一个 g 结构体（或 malloc 一个），设置好栈和入口函数，然后放入运行队列——全程没有系统调用。

1.2 G/M/P 三个角色的直觉理解

GMP 模型可以用一个工厂类比来理解：

┌─────────────────────────────────────────────────────────┐
│                        工厂（Go 进程）                    │
│                                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐             │
│  │  工位 P0  │  │  工位 P1  │  │  工位 P2  │   ...      │
│  │          │  │          │  │          │             │
│  │ 本地任务队列│  │ 本地任务队列│  │ 本地任务队列│             │
│  │ [G][G][G]│  │ [G][G]   │  │ [G]      │             │
│  │          │  │          │  │          │             │
│  │  工人 M0  │  │  工人 M1  │  │  工人 M2  │             │
│  │  (在岗)   │  │  (在岗)   │  │  (在岗)   │             │
│  └──────────┘  └──────────┘  └──────────┘             │
│                                                         │
│  全局任务队列: [G][G][G][G][G]...                        │
│                                                         │
│  休息室（空闲工人）: M3, M4, M5 ...                      │
└─────────────────────────────────────────────────────────┘

G（Goroutine）= 任务单。 每个 G 代表一个待执行的函数，包含函数入口、参数、栈空间、当前执行状态。它是被调度的最小单位。在运行时中对应 runtime.g 结构体。

M（Machine）= 工人。 每个 M 对应一个操作系统线程。M 是真正执行代码的实体——CPU 只认线程，不认 goroutine。M 从 P 的队列中取出 G 来执行。在运行时中对应 runtime.m 结构体。

P（Processor）= 工位。 P 是一个逻辑概念，代表"执行 Go 代码所需的资源"。每个 P 有自己的本地运行队列（local run queue）、内存缓存（mcache）、以及其他调度状态。M 必须持有一个 P 才能执行 goroutine。P 的数量由 GOMAXPROCS 决定。在运行时中对应 runtime.p 结构体。

为什么需要 P？ 你可能会问：既然 M 是线程，G 是任务，为什么不让 M 直接从全局队列取 G？答案是：性能。如果所有 M 都从全局队列取 G，这个队列就需要加锁，在高并发场景下锁竞争会严重降低性能。引入 P 后，每个 M 绑定一个 P，优先从 P 的本地队列取 G（无锁操作），只有本地队列空了才去全局队列或其他 P 的队列偷。

// 查看当前 GMP 状态
package main

import (
    "fmt"
    "runtime"
)

func main() {
    fmt.Printf("GOMAXPROCS (P 的数量): %d\n", runtime.GOMAXPROCS(0))
    fmt.Printf("NumCPU (CPU 核心数): %d\n", runtime.NumCPU())
    fmt.Printf("NumGoroutine (活跃 G 数): %d\n", runtime.NumGoroutine())
}

1.3 GOMAXPROCS 的含义和设置

GOMAXPROCS 决定了同时执行 Go 代码的最大线程数，也就是 P 的数量。注意关键字"同时"——这不是 goroutine 的数量上限，也不是线程的数量上限，而是并行度的上限。

默认值： 从 Go 1.5 开始，GOMAXPROCS 默认等于 CPU 核心数。在此之前默认为 1，意味着所有 goroutine 只能并发但不能并行。

设置方式：

// 方式一：环境变量
// GOMAXPROCS=4 go run main.go

// 方式二：代码中设置
import "runtime"

func init() {
    runtime.GOMAXPROCS(4) // 返回之前的值
}

// 方式三：查询当前值
current := runtime.GOMAXPROCS(0) // 传 0 不修改，只查询

常见误区：

1. 误区：GOMAXPROCS 越大越好。 实际上，对于 CPU 密集型任务，设置为 CPU 核心数是最优的。超过核心数只会增加调度开销和缓存失效。对于 I/O 密集型任务，可以适当增大，但通常默认值就够了。

2. 误区：GOMAXPROCS 限制了线程数。 不是。M（OS 线程）的数量可以远超 P 的数量。当 goroutine 执行系统调用而阻塞时，运行时会创建新的 M 来保证 P 不闲置。默认最大线程数为 10000（可通过 runtime/debug.SetMaxThreads 修改）。

3. 误区：容器中 GOMAXPROCS 会自动适配。 Go 运行时读取的是宿主机 CPU 核心数，不是容器的 CPU 配额。在 Kubernetes 中，一个限制 2 核的 Pod 如果跑在 64 核机器上，GOMAXPROCS 会是 64，造成严重的调度开销。解决方案是使用 uber-go/automaxprocs 库。

// 容器环境推荐做法
import _ "go.uber.org/automaxprocs" // 自动根据 CFS 配额设置

func main() {
    // GOMAXPROCS 已自动设置为容器 CPU 限制
}

1.4 goroutine 的生命周期

一个 goroutine 从创建到消亡，经历以下状态：

                    ┌─────────────────────────────────────┐
                    │                                     ▼
创建(_Gidle) ──→ 就绪(_Grunnable) ──→ 运行(_Grunning) ──→ 结束(_Gdead)
                    ▲                     │
                    │                     ▼
                    └──── 唤醒 ◄──── 阻塞(_Gwaiting)
                                          │
                                          ▼
                                    系统调用(_Gsyscall)

各状态详解：

创建过程：

当你写 go f(args) 时，编译器将其转换为对 runtime.newproc 的调用：

// 编译器转换：
// go f(x, y)  →  runtime.newproc(f, x, y)

// 简化的创建流程：
// 1. 从当前 P 的 gFree 列表获取一个空闲 G（复用），或 malloc 新的
// 2. 设置 G 的栈、入口函数 (fn)、参数
// 3. 将 G 的状态设为 _Grunnable
// 4. 将 G 放入当前 P 的本地运行队列尾部
// 5. 如果有空闲的 P 且没有 spinning 的 M，唤醒一个 M

阻塞与唤醒：

goroutine 的阻塞不同于线程阻塞。当 goroutine 因为 channel 操作而阻塞时：

• G 的状态变为 _Gwaiting
• G 被从 M 上摘下，放入 channel 的等待队列
• M 不会阻塞——它立刻从 P 的队列取下一个 G 来执行
• 当 channel 另一端就绪时，阻塞的 G 被放回某个 P 的运行队列

这就是 goroutine 的核心优势：G 的阻塞不会浪费 M（线程）资源。

// 观察 goroutine 状态变化
package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    fmt.Printf("启动时 goroutine 数: %d\n", runtime.NumGoroutine())
    
    ch := make(chan struct{})
    
    go func() {
        // 状态: _Grunnable → _Grunning
        fmt.Println("goroutine 运行中")
        <-ch // 状态: _Grunning → _Gwaiting (阻塞在 channel)
        fmt.Println("goroutine 被唤醒")
        // 函数返回后状态: _Grunning → _Gdead
    }()
    
    time.Sleep(100 * time.Millisecond)
    fmt.Printf("阻塞中 goroutine 数: %d\n", runtime.NumGoroutine())
    
    ch <- struct{}{} // 唤醒: G 状态 _Gwaiting → _Grunnable → _Grunning
    time.Sleep(100 * time.Millisecond)
    fmt.Printf("完成后 goroutine 数: %d\n", runtime.NumGoroutine())
}

系统调用场景：

当 goroutine 进入系统调用（如文件 I/O）时，情况有所不同：

• G 的状态变为 _Gsyscall
• M 会被阻塞在系统调用中（这是无法避免的，内核不提供异步文件 I/O 的通用方案）
• P 会与 M 解绑（handoff），转而绑定另一个空闲 M（或创建新 M）
• 当系统调用返回时，M 尝试重新获取之前的 P；如果 P 已被占用，M 将 G 放入全局队列，自己进入休眠

这保证了：即使有 goroutine 陷入长时间系统调用，其他 goroutine 的调度不受影响。

1.5 常见错误及修复

错误 1：goroutine 泄漏

// 错误：没人往 ch 发送数据，goroutine 永远阻塞
func leak() {
    ch := make(chan int)
    go func() {
        val := <-ch // 永远阻塞，goroutine 无法被 GC
        fmt.Println(val)
    }()
    // 函数返回，ch 不可达，但 goroutine 还在等待
}

// 修复方案 1：使用 context 控制生命周期
func noLeak(ctx context.Context) {
    ch := make(chan int)
    go func() {
        select {
        case val := <-ch:
            fmt.Println(val)
        case <-ctx.Done():
            return // 超时或取消时退出
        }
    }()
}

// 修复方案 2：使用 buffered channel
func noLeak2() {
    ch := make(chan int, 1) // 即使没人读，发送方也不会阻塞
    go func() {
        ch <- 42
    }()
}

错误 2：忽略 GOMAXPROCS 对 CPU 密集任务的影响

// 在 4 核机器上运行 CPU 密集计算
// 如果 GOMAXPROCS=1，这些 goroutine 只能并发不能并行
func compute() {
    var wg sync.WaitGroup
    for i := 0; i < 4; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            // CPU 密集计算
            sum := 0
            for j := 0; j < 1_000_000_000; j++ {
                sum += j
            }
        }()
    }
    wg.Wait()
}
// GOMAXPROCS=1: ~12s
// GOMAXPROCS=4: ~3s (线性加速)

Level 2 · 它是怎么运行的

2.1 GMP 模型的完整工作流程

要理解调度器的完整工作流程，我们需要深入 runtime.schedule() 函数。这是调度器的核心循环，每个 M 在需要新 G 执行时都会进入这个函数。

schedule() 的执行流程：
┌────────────────────────────────────────────────────────┐
│  schedule()                                            │
│  │                                                    │
│  ├─ 1. 如果当前 G 被标记为要锁定到 M，处理 LockOSThread │
│  │                                                    │
│  ├─ 2. 尝试获取可运行的 G (findRunnable)              │
│  │     ├─ 检查本地运行队列                            │
│  │     ├─ 检查全局运行队列                            │
│  │     ├─ 检查 netpoller                              │
│  │     ├─ 尝试 work stealing                          │
│  │     └─ 都没有？阻塞等待                            │
│  │                                                    │
│  ├─ 3. execute(gp) — 切换到目标 G 的上下文执行         │
│  │                                                    │
│  └─ 4. G 执行完毕 / 阻塞 / 被抢占 → 回到 schedule()   │
└────────────────────────────────────────────────────────┘

让我们看看 findRunnable 的具体查找顺序（来源于 runtime/proc.go）：

// 简化的 findRunnable 逻辑 (Go 1.22)
func findRunnable() (gp *g, inheritTime, tryWakeP bool) {
    pp := getg().m.p.ptr()
    
    // 1. 每隔 61 次调度，检查全局队列（防止全局队列饿死）
    if pp.schedtick%61 == 0 && sched.runqsize > 0 {
        lock(&sched.lock)
        gp := globrunqget(pp, 1) // 从全局队列取 1 个
        unlock(&sched.lock)
        if gp != nil {
            return gp, false, false
        }
    }
    
    // 2. 从本地运行队列获取
    if gp, inheritTime := runqget(pp); gp != nil {
        return gp, inheritTime, false
    }
    
    // 3. 从全局运行队列获取
    if sched.runqsize != 0 {
        lock(&sched.lock)
        gp := globrunqget(pp, 0) // 取 min(全局队列长度/P数+1, 本地队列容量/2)
        unlock(&sched.lock)
        if gp != nil {
            return gp, false, false
        }
    }
    
    // 4. 从 netpoller 获取就绪的网络 I/O goroutine
    if netpollinited() && netpollAnyWaiters() && sched.lastpoll.Load() != 0 {
        if list, delta := netpoll(0); !list.empty() {
            gp := list.pop()
            // 剩余的放入本地/全局队列
            injectglist(&list)
            return gp, false, false
        }
    }
    
    // 5. 尝试从其他 P 偷 (Work Stealing)
    // 随机选一个 P 开始，遍历所有 P
    for i := 0; i < 4; i++ { // 最多尝试 4 轮
        for enum := stealOrder.start(fastrand()); !enum.done(); enum.next() {
            p2 := allp[enum.position()]
            if gp := runqsteal(pp, p2, stealRunNextG); gp != nil {
                return gp, false, false
            }
        }
    }
    
    // 6. 都没有，进入休眠等待
    stopm() // 将 M 放入空闲列表，解绑 P
}

调度器的时机： 不是所有代码都在无中断地运行。Go 调度器在以下时机获得执行机会：

1. goroutine 主动让出：channel 操作、mutex 锁、time.Sleep、runtime.Gosched()
2. 函数调用时的栈检查：编译器在函数入口插入 morestack 检查，这也是抢占检查点
3. 系统调用前后：进入/退出系统调用时，调度器有机会调整 M/P 的绑定关系
4. 异步抢占信号：Go 1.14+ 通过信号机制强制中断长时间运行的 G

2.2 Work Stealing：当 P 的本地队列空了

Work Stealing 是 GMP 调度器保持负载均衡的核心机制。当一个 P 的本地队列为空时，它不会闲着——它会去其他 P 的队列"偷"工作。

Work Stealing 过程示意：
                                                      
P0 的视角：                                           
                                                      
┌──────────┐     本地队列空了！         ┌──────────┐  
│    P0    │  ──── 随机选一个 P ────→   │    P2    │  
│ 队列:[ ] │                           │队列:[G G G G]│
│          │  ◄── 偷走一半 (2个G) ──── │          │  
│ 队列:[G G]│                           │ 队列:[G G] │
└──────────┘                           └──────────┘  

Work Stealing 的具体规则：

1. 偷多少？ 偷走目标 P 本地队列的一半。如果目标有 6 个 G，偷走 3 个。这保证了双方各有工作做。

2. 从哪偷？ 随机选择起始 P，然后遍历所有 P。使用随机起点是为了避免所有空闲 P 都去偷同一个 P。

3. 偷的是队列的哪一端？ P 的本地运行队列是一个无锁环形缓冲区（大小 256），队列的头部（head）是将要执行的下一个 G，尾部（tail）是最近入队的 G。偷取从 tail 端开始——这利用了局部性原理：尾部的 G 是最近入队的，可能还没有在目标 P 的缓存中建立局部性，偷过来的代价较小。

4. 还能偷什么？ 除了运行队列中的 G，还可以偷目标 P 的 runnext——这是一个特殊的"即将运行"的 G 指针，被偷的概率通过 stealRunNextG 标志控制。

// 验证 Work Stealing 行为
package main

import (
    "fmt"
    "runtime"
    "sync"
    "sync/atomic"
)

func main() {
    runtime.GOMAXPROCS(4)
    
    var counters [4]atomic.Int64
    var wg sync.WaitGroup
    
    // 将所有 goroutine 集中在 P0 创建
    // 观察它们是否被其他 P 偷走执行
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            // 获取当前执行的 P 的 ID（需要通过 hack 获取）
            // 这里用 CPU 密集操作让 work stealing 有时间发生
            sum := 0
            for j := 0; j < 1_000_000; j++ {
                sum += j
            }
        }()
    }
    
    wg.Wait()
    // 如果没有 work stealing，所有任务都会在一个 P 上串行执行
    // 实际上你会观察到 4 核的加速比
    fmt.Println("Work stealing ensures load balance across", runtime.GOMAXPROCS(0), "Ps")
    _ = counters
}

2.3 系统调用时的 M/P 分离（handoff）

当 goroutine 执行系统调用时，整个 M（OS 线程）会被内核阻塞。如果不做任何处理，这个 M 绑定的 P 也会一起闲置，浪费一个并行执行位。

handoff 机制：

系统调用前：         系统调用期间：        系统调用返回后：
                                         
M0 ─── P0           M0 (blocked)         M0 ─── P0 (如果 P0 空闲)
 │                       ↓                或
 G1 (syscall)        P0 解绑              M0 → 全局队列放入 G1
                       ↓                      M0 进入空闲列表
                  M2 ─── P0              
                   │                     
                   G3 (running)          

具体步骤：

1. 进入系统调用前：runtime.entersyscall() 被调用，G 状态设为 _Gsyscall，P 状态设为 _Psyscall。
2. sysmon 检测：sysmon 线程定期检查所有处于 _Psyscall 状态的 P，如果系统调用超过 20μs（或一个 sysmon tick），就执行 handoff——将 P 从 M 上解绑，交给另一个空闲 M 或创建新 M。
3. 系统调用返回：M 尝试重新获取之前的 P。如果 P 已被其他 M 占用，M 尝试获取任何空闲 P。如果没有空闲 P，M 将 G 放入全局运行队列，自己进入休眠。

// 观察系统调用导致的线程增长
package main

import (
    "fmt"
    "os"
    "runtime"
    "sync"
    "time"
)

func main() {
    runtime.GOMAXPROCS(2) // 只允许 2 个 P
    
    fmt.Printf("初始线程数（估算）: GOMAXPROCS=%d\n", runtime.GOMAXPROCS(0))
    
    var wg sync.WaitGroup
    // 启动 10 个 goroutine 都做阻塞 I/O
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            // 打开文件是系统调用，会阻塞 M
            f, _ := os.Open("/dev/zero")
            buf := make([]byte, 1)
            f.Read(buf) // 阻塞系统调用
            time.Sleep(time.Second)
            f.Close()
        }(i)
    }
    
    time.Sleep(100 * time.Millisecond)
    // 此时应该有 >2 个 M 被创建（因为系统调用阻塞了原来的 M）
    var m runtime.MemStats
    runtime.ReadMemStats(&m)
    fmt.Printf("NumGoroutine: %d\n", runtime.NumGoroutine())
    
    wg.Wait()
}

网络 I/O 的特殊处理——netpoller：

Go 对网络 I/O 做了特殊优化，使用 epoll（Linux）/ kqueue（macOS）/ IOCP（Windows）实现非阻塞 I/O。当 goroutine 执行网络读写时：

• 底层 fd 被设置为非阻塞模式
• 如果 I/O 未就绪，G 被挂到 netpoller 的等待列表中（状态 _Gwaiting）
• M 不会被阻塞，立刻执行其他 G
• netpoller 在 findRunnable 时被检查，就绪的 G 被放回运行队列

这就是为什么 Go 的网络服务器能用少量线程处理大量并发连接——每个 goroutine 阻塞在网络 I/O 时不会浪费任何 OS 线程。

2.4 抢占式调度

协作式抢占（Go 1.13 及之前）：

Go 1.14 之前，调度器依赖"协作式抢占"。编译器在函数入口插入栈增长检查代码（morestack），调度器通过设置 G 的 stackguard0 字段为一个特殊值来请求抢占。当 G 下次调用函数时，会触发栈检查，发现抢占标记，主动让出 CPU。

问题： 如果一个 goroutine 执行一个没有函数调用的紧密循环（tight loop），它永远不会检查抢占标记，其他 goroutine 就会被饿死：

// Go 1.13 及之前，这个 goroutine 永远不会被抢占
go func() {
    for {
        // 纯计算，没有函数调用
        // 没有抢占检查点
        x++
    }
}()
// 其他 goroutine 可能被饿死

基于信号的异步抢占（Go 1.14+）：

Go 1.14 引入了基于信号的异步抢占机制（提案 proposal #24543，由 Austin Clements 提出）：

1. sysmon 线程 检测到某个 G 运行超过 10ms
2. sysmon 向目标 M 发送 SIGURG 信号（选择 SIGURG 是因为它不会干扰 debugger 和其他标准信号处理）
3. M 的信号处理函数 sighandler 接收信号
4. 信号处理函数检查是否在安全点（safe point），如果是，修改 G 的 PC 寄存器指向 asyncPreempt 函数
5. 信号处理返回后，G 实际跳转到 asyncPreempt，保存所有寄存器状态，然后调用 schedule() 让出 CPU

异步抢占流程：

sysmon 检测: G 运行 > 10ms
        │
        ▼
向 M 发送 SIGURG
        │
        ▼
M 的 signal handler 接管
        │
        ▼
检查是否在 safe point?
    ├── 否 → 暂不抢占，等下次
    └── 是 → 修改 G.pc = asyncPreempt
                │
                ▼
        signal return → 执行 asyncPreempt
                │
                ▼
        保存所有寄存器 → gopreempt_m() → schedule()

安全点（safe point）的概念：

不是任何时刻都能安全地抢占一个 goroutine。例如，当 G 正在执行运行时内部的非抢占区域（如 GC 标记阶段的某些操作）时，强制抢占可能导致不一致状态。Go 运行时通过检查以下条件判断是否在安全点：

• 不在 _Gsyscall 状态
• 不持有运行时内部的锁
• 栈帧信息可用（能生成正确的 stack map 供 GC 使用）

2.5 sysmon 监控线程

sysmon 是 Go 运行时中一个特殊的守护线程——它不绑定任何 P，独立运行，负责整个运行时的"看门狗"职责。

// sysmon 的主要职责（简化自 runtime/proc.go）
func sysmon() {
    idle := 0
    delay := uint32(0)
    
    for {
        // 动态调整检查间隔：空闲时最多 10ms，繁忙时最短 20μs
        if idle == 0 {
            delay = 20 // 20μs
        } else if idle > 50 {
            delay = 10000 // 10ms
        }
        usleep(delay)
        
        // 1. 网络轮询：如果距离上次 netpoll 超过 10ms，执行一次非阻塞 netpoll
        lastpoll := sched.lastpoll.Load()
        if netpollinited() && lastpoll != 0 && lastpoll+10*1000*1000 < now {
            sched.lastpoll.Store(now)
            list, _ := netpoll(0) // 非阻塞
            if !list.empty() {
                injectglist(&list) // 将就绪的 G 放入全局队列
            }
        }
        
        // 2. 抢占长时间运行的 G
        retake(now) // 检查所有 P，执行抢占或 handoff
        
        // 3. 强制 GC：如果超过 2 分钟没有 GC，强制触发
        if t := (gcTrigger{kind: gcTriggerTime, now: now}); t.test() {
            forcegc.g.schedlink = 0
            injectglist(&forcegc.g)
        }
        
        // 4. 释放长时间未使用的堆内存归还给 OS (scavenger)
    }
}

sysmon 的 retake 函数——抢占和 handoff 的具体逻辑：

func retake(now int64) uint32 {
    n := 0
    for i := 0; i < len(allp); i++ {
        pp := allp[i]
        pd := &pp.sysmontick
        s := pp.status
        
        if s == _Prunning || s == _Psyscall {
            // 对于正在运行的 P：如果 G 运行超过 forcePreemptNS (10ms)
            // 设置抢占标记
            t := int64(pp.schedtick)
            if pd.schedtick != t {
                pd.schedtick = t
                pd.schedwhen = now
            } else if pd.schedwhen+forcePreemptNS <= now {
                preemptone(pp) // 发送抢占信号
                n++
            }
        }
        
        if s == _Psyscall {
            // 对于执行系统调用的 P：如果超过一个 sysmon tick
            // 且本地队列不空或没有空闲 P，执行 handoff
            if runqempty(pp) && sched.nmspinning.Load()+sched.npidle.Load() > 0 {
                continue // 没必要 handoff
            }
            if pd.syscallwhen+10*1000*1000 > now {
                continue // 还没超时
            }
            handoffp(pp) // 将 P 从阻塞的 M 上解绑
            n++
        }
    }
    return uint32(n)
}

sysmon 的运行频率：

sysmon 不是以固定频率运行的。它使用自适应的休眠策略：

• 初始时每 20μs 检查一次
• 如果连续没有发现需要处理的事件，逐渐增大间隔
• 最大间隔为 10ms
• 一旦发现有事件需要处理，立即降低间隔

这种策略平衡了响应性和 CPU 开销——在系统繁忙时频繁检查，空闲时减少开销。

2.6 调度器的局部性优化

Go 调度器还包含多个局部性优化，以减少缓存失效和提高性能：

runnext 优化： 每个 P 有一个 runnext 字段，指向"下一个应该运行的 G"。当一个 G 创建了新的 G 时（go func()），新 G 不是放入队列尾部，而是设置为当前 P 的 runnext。这样新 G 会被立即调度执行，利用 producer-consumer 的局部性（生产者创建的数据还在缓存中，消费者立即使用）。

P 的 affinity： 当 G 从阻塞中唤醒时，运行时优先将其放回之前运行的 P 的本地队列，利用已有的缓存预热。

本地队列的无锁实现： P 的本地运行队列是一个大小为 256 的环形数组，使用原子操作实现无锁的单生产者多消费者队列（只有拥有该 P 的 M 会 push，但其他 P 可以 steal）。

Level 3 · 规范怎么定义的

3.1 GMP 模型的演进：从 GM 到 GMP

Go 1.0 的 GM 模型：

Go 最初的调度器（Go 1.0）非常简单：只有 G 和 M，没有 P 的概念。

Go 1.0 调度器：
                                 
┌──────────────────────────────┐
│        全局运行队列           │
│    [G] [G] [G] [G] [G]      │
│         (mutex 保护)          │
└──────────┬───────────────────┘
           │
    ┌──────┼──────┐
    ▼      ▼      ▼
   M0     M1     M2
   │       │      │
   G       G      G

这个模型的问题很严重：

1. 全局队列锁竞争：所有 M 每次需要新 G 时都要争夺全局队列的 mutex。在高并发场景下，这个锁成为严重瓶颈。
2. G 的传递问题：当 M0 创建了一个新 G，这个 G 被放入全局队列，可能被 M1 取走执行。如果新 G 需要访问 M0 刚处理过的数据，缓存局部性被破坏。
3. M 的频繁阻塞和唤醒：每个因系统调用阻塞的 M 醒来后，都需要争抢全局锁才能继续工作。
4. 内存分配器的竞争：Go 的内存分配器（mcache）当时绑定在 M 上。由于 M 的数量会因为系统调用而膨胀，大量 M 持有各自的 mcache 导致内存浪费。

Dmitry Vyukov 的 GMP 重设计（Go 1.1，2013年）：

2012 年 3 月，Google 的 Dmitry Vyukov 提交了著名的设计文档《Scalable Go Scheduler Design Doc》（https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw）。这份文档分析了 GM 模型的四个核心缺陷，并提出了引入 P 的解决方案。

P 解决了什么：

设计中的关键数字选择：

• P 的本地队列大小为 256（2 的幂，方便取模运算；足够大以减少全局队列交互频率）
• 抢占时间阈值为 10ms（平衡延迟和吞吐量——太短导致频繁切换，太长导致其他 G 等待太久）
• work stealing 时偷 一半（来自 Blumofe-Leiserson 定理的均衡策略）
• 每 61 次调度检查一次全局队列（61 是质数，避免与程序中可能存在的固定模式产生共振）

3.2 为什么需要 P——减少全局锁竞争

让我们用性能数据来量化 P 的价值。Dmitry Vyukov 在设计文档中给出了以下基准测试结果（在 8 核机器上）：

benchmark                    old ns/op    new ns/op    speedup
BenchmarkCreateGoroutine     2080         480          4.3x
BenchmarkCreateGoroutineIdle 1010         66           15.3x
BenchmarkOsYield             7700         5700         1.4x
BenchmarkPing                46000        27000        1.7x

创建 goroutine 的速度提升了 4-15 倍，这主要归功于消除了全局队列的锁竞争。

本地队列的无锁实现细节：

P 的本地运行队列使用了经典的单生产者多消费者无锁环形缓冲区：

type p struct {
    // ...
    runqhead uint32        // 原子读写
    runqtail uint32        // 只有拥有者写
    runq     [256]guintptr // 环形缓冲区
    runnext  guintptr      // 原子操作
}

// 入队（只有拥有此 P 的 M 调用）
func runqput(pp *p, gp *g, next bool) {
    if next {
        // 设置为 runnext（原子 CAS）
        oldnext := pp.runnext
        if !pp.runnext.cas(oldnext, guintptr(unsafe.Pointer(gp))) {
            retry...
        }
        if oldnext == 0 {
            return
        }
        gp = oldnext.ptr() // 旧的 runnext 放入队列
    }
    
    h := atomic.LoadAcq(&pp.runqhead)
    t := pp.runqtail
    if t-h < uint32(len(pp.runq)) {
        pp.runq[t%uint32(len(pp.runq))].set(gp)
        atomic.StoreRel(&pp.runqtail, t+1) // 确保 G 对窃取者可见
        return
    }
    // 本地队列满了，放一半到全局队列
    runqputslow(pp, gp, h, t)
}

关键点：

• runqtail 只有拥有者写，不需要 CAS
• runqhead 需要原子操作，因为窃取者会修改它
• 使用 atomic.LoadAcq 和 atomic.StoreRel 保证内存顺序
• 当本地队列满（256 个），将一半 G 移到全局队列——这就是"溢出"机制

3.3 Work Stealing 算法的理论基础

Work Stealing 的理论来源于 Robert D. Blumofe 和 Charles E. Leiserson 1999 年发表的论文 "Scheduling Multithreaded Computations by Work Stealing"（Journal of the ACM, Vol. 46, No. 5）。

核心定理： 对于一个包含 T₁ 总工作量和 T∞ 关键路径长度的并行计算，使用 P 个处理器的 work-stealing 调度器，期望执行时间为：

E[Tp] ≤ T₁/P + O(T∞)

其中：

• T₁ 是串行执行的总时间（所有任务之和）
• T∞ 是关键路径长度（最长依赖链）
• P 是处理器数量

这个界意味着什么？ 它证明了 work stealing 是"接近最优"的——执行时间由两部分组成：理想的并行分摊（T₁/P）加上不可避免的串行依赖（T∞）。理论上不可能比这更好了（任何调度器的下界是 max(T₁/P, T∞)）。

Work Stealing vs Work Sharing 的对比：

Go 选择 work stealing 是因为 goroutine 的创建极其频繁（每秒可能数百万次），如果每次创建都做分发，通信开销会压垮系统。

Blumofe-Leiserson 论文的另一个关键结论——窃取操作的次数：

理论证明，在整个计算过程中，窃取尝试的期望总次数为 O(P · T∞)。这意味着窃取操作（需要访问远程 P 的队列，有通信开销）的频率随处理器数量线性增长，但与总工作量无关。对于 Go 程序来说，如果 goroutine 之间的依赖链不太长（T∞ 小），则窃取次数相对较少，大部分时间各 P 都在本地执行。

3.4 与其他运行时调度器的对比

Erlang BEAM 调度器：

Erlang 的 BEAM 虚拟机使用与 Go 类似但更早的调度模型：

• 每个 CPU 核心一个调度器线程（相当于 P）
• 每个调度器有自己的运行队列
• 使用 work stealing 和 work sharing 的混合策略
• 与 Go 的关键差异：Erlang 进程（process）完全不共享内存，消息传递是唯一通信方式，因此调度器迁移进程时无需考虑缓存一致性代价

Erlang BEAM:                        Go GMP:
                                    
Scheduler 1 ─── RunQueue            P0 ─── LocalRunQueue
Scheduler 2 ─── RunQueue            P1 ─── LocalRunQueue
Scheduler 3 ─── RunQueue            P2 ─── LocalRunQueue
                                    GlobalRunQueue
迁移队列 (migration queue)           Work Stealing
减少/compaction (如果负载下降)         Spinning M 等待

Erlang 的独特之处在于"规约计数"（reduction counting）的抢占方式：每个进程执行约 4000 次规约（大约对应函数调用和 BIF 调用）后被强制切换。这比 Go 的 10ms 时间片更精确，因为它不依赖时钟中断。

Java 虚拟线程（Project Loom，JDK 19+）：

Java 的虚拟线程（Virtual Threads）直接受 Go goroutine 的启发，采用了非常相似的 M:N 调度模型：

• Platform Thread ≈ M（OS 线程）
• Virtual Thread ≈ G（用户态纤程）
• ForkJoinPool ≈ P 的集合

// Java 虚拟线程示例
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++) {
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));
            return "done";
        });
    }
}

关键差异：

Java 虚拟线程的一个已知问题是"pinning"——当虚拟线程进入 synchronized 块或执行 native 方法时，它会被固定（pin）在载体线程上，无法被调度器卸载。这类似于 Go 的 LockOSThread()。

Rust tokio 运行时：

Rust 的异步运行时 tokio 也使用 work-stealing 调度器，但模型有本质不同：

// Rust tokio 示例
#[tokio::main]
async fn main() {
    let handles: Vec<_> = (0..100_000).map(|i| {
        tokio::spawn(async move {
            tokio::time::sleep(Duration::from_secs(1)).await;
            i
        })
    }).collect();
    
    for handle in handles {
        handle.await.unwrap();
    }
}

tokio 的核心差异在于无栈协程模型——Rust 的 async/await 被编译器转换为状态机，不需要为每个 task 分配栈空间。这使得内存效率更高，但代价是所有 I/O 点都需要显式 await，且不支持抢占。如果一个 task 做了阻塞操作而没用 spawn_blocking，会阻塞整个 worker 线程。

3.5 调度器设计的关键 trade-off

Go 调度器的设计中充满了有意识的 trade-off：

1. 公平性 vs 吞吐量：

10ms 的抢占阈值是一个折中。更短的时间片带来更好的公平性（低延迟），但增加了切换开销（低吞吐量）。Linux CFS 调度器的默认时间片是 6ms（由 sched_latency 和 sched_min_granularity 决定），Go 的 10ms 相对宽松，倾向于吞吐量。

2. 队列大小 vs 溢出频率：

本地队列 256 的大小是另一个 trade-off。更大的队列减少溢出到全局队列的频率，但增加了被偷时的一致性代价；更小的队列让 work stealing 更频繁但也更快。

3. spinning M vs 响应延迟：

Go 调度器维护一小组"spinning"的 M——它们持有 P 但没有在执行 G，不断自旋寻找工作。这浪费了 CPU 但减少了唤醒延迟。spinning M 的数量被控制在一个较小值（不超过空闲 P 的一半），平衡了 CPU 利用率和响应性。

Level 4 · 边界与陷阱

4.1 goroutine 泄漏的常见原因和检测方法

goroutine 泄漏是 Go 程序最常见的资源泄漏类型——被遗忘的 goroutine 无法被垃圾回收（因为栈上可能持有引用），会导致内存持续增长直到 OOM。

常见泄漏场景：

// 场景 1：向无人接收的 channel 发送
func leak1() {
    ch := make(chan int)
    go func() {
        ch <- expensiveComputation() // 永远阻塞
    }()
    // 函数返回，ch 不可达，但 goroutine 无法退出
}

// 场景 2：从无人发送的 channel 接收
func leak2(ctx context.Context) error {
    results := make(chan *Result)
    go func() {
        r, err := callExternalService()
        if err != nil {
            return // 注意：没有往 channel 发数据就 return 了
        }
        results <- r
    }()
    
    select {
    case r := <-results:
        return process(r)
    case <-ctx.Done():
        return ctx.Err()
        // 如果 ctx 超时，goroutine 还在运行 callExternalService
        // 即使函数返回了，goroutine 也不会退出
    }
}

// 场景 3：忘记关闭 channel 导致 range 永远阻塞
func leak3() {
    ch := make(chan int)
    go func() {
        for v := range ch { // 永远阻塞，因为 ch 没有被 close
            process(v)
        }
    }()
    ch <- 1
    ch <- 2
    // 忘记 close(ch)
}

// 场景 4：互相等待（goroutine 死锁）
func leak4() {
    ch1 := make(chan int)
    ch2 := make(chan int)
    go func() {
        <-ch1   // 等 ch1
        ch2 <- 1 // 然后发 ch2
    }()
    go func() {
        <-ch2   // 等 ch2
        ch1 <- 1 // 然后发 ch1
    }()
    // 两个 goroutine 互相等待，永远不会退出
}

检测方法：

方法 1：runtime.NumGoroutine() 监控

// 在测试中检查 goroutine 泄漏
func TestNoLeak(t *testing.T) {
    before := runtime.NumGoroutine()
    
    // 执行被测代码
    doSomething()
    
    // 等待 goroutine 退出
    time.Sleep(100 * time.Millisecond)
    
    after := runtime.NumGoroutine()
    if after > before {
        t.Errorf("goroutine leak: before=%d after=%d", before, after)
    }
}

方法 2：goleak 库（Uber 开源）

import "go.uber.org/goleak"

func TestMain(m *testing.M) {
    goleak.VerifyTestMain(m)
}

// 或者在单个测试中
func TestFoo(t *testing.T) {
    defer goleak.VerifyNone(t)
    // ... test code ...
}

goleak 的工作原理是在测试结束时获取所有 goroutine 的堆栈，过滤掉已知的系统 goroutine（runtime、testing 包自身的），如果还有其他 goroutine 存活则报错。

方法 3：pprof goroutine profile

import (
    "net/http"
    _ "net/http/pprof"
)

func main() {
    go func() {
        http.ListenAndServe(":6060", nil) // 暴露 pprof 端点
    }()
    // ...
}

// 访问 http://localhost:6060/debug/pprof/goroutine?debug=1
// 查看所有 goroutine 的堆栈

// 或使用命令行：
// go tool pprof http://localhost:6060/debug/pprof/goroutine
// (pprof) top    — 查看哪些函数创建了最多 goroutine
// (pprof) traces — 查看所有 goroutine 的调用栈

方法 4：持续监控 + 告警

// 在 Prometheus 中暴露 goroutine 数量
import "github.com/prometheus/client_golang/prometheus"

var goroutineGauge = prometheus.NewGaugeFunc(
    prometheus.GaugeOpts{
        Name: "go_goroutines",
        Help: "Number of goroutines that currently exist.",
    },
    func() float64 { return float64(runtime.NumGoroutine()) },
)

// 告警规则（Prometheus AlertManager）：
// alert: GoroutineLeak
//   expr: go_goroutines > 10000
//   for: 5m

4.2 GOMAXPROCS 设置不当的性能影响

场景 1：容器中未适配 CPU 配额

这是生产环境最常见的问题。假设 Kubernetes Pod 配置了 resources.limits.cpu: "2"（2 核），但宿主机有 64 核：

GOMAXPROCS = 64（错误！）
├── 创建了 64 个 P
├── 64 个 M 竞争 2 核 CPU 时间
├── 大量上下文切换（Linux CFS 强制限流）
├── 调度延迟增大
└── 实际吞吐量比 GOMAXPROCS=2 更差

// 修复方案
import _ "go.uber.org/automaxprocs" // init() 时自动检测 CFS 配额

// automaxprocs 的原理：
// 1. 读取 /sys/fs/cgroup/cpu/cpu.cfs_quota_us
// 2. 读取 /sys/fs/cgroup/cpu/cpu.cfs_period_us
// 3. GOMAXPROCS = quota / period（向上取整）

场景 2：CPU 密集 vs I/O 密集的不同策略

// CPU 密集型：GOMAXPROCS = CPU 核心数（默认值最优）
// 加密计算、图像处理、数值模拟等
func cpuBound() {
    runtime.GOMAXPROCS(runtime.NumCPU()) // 这就是默认值
}

// I/O 密集型：GOMAXPROCS = CPU 核心数 已经够用
// 因为 goroutine 阻塞时不占用 P，P 会去执行其他 G
// 不需要增大 GOMAXPROCS

// 混合型工作负载：特殊情况可能需要调整
// 如果有大量 CGO 调用（CGO 调用会绑定 M），可能需要增大 GOMAXPROCS

场景 3：GOMAXPROCS=1 的特殊用途

// 将 GOMAXPROCS 设为 1 可以简化并发推理
runtime.GOMAXPROCS(1)
// 此时所有 goroutine 只能并发不能并行
// 在某些测试场景下有用（复现竞态条件）
// 但注意：这不能替代 race detector

基准测试：GOMAXPROCS 对不同工作负载的影响

package main

import (
    "crypto/sha256"
    "fmt"
    "runtime"
    "sync"
    "time"
)

func benchCPU(procs int) time.Duration {
    runtime.GOMAXPROCS(procs)
    start := time.Now()
    var wg sync.WaitGroup
    for i := 0; i < 8; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            data := make([]byte, 1024)
            for j := 0; j < 100_000; j++ {
                sha256.Sum256(data)
            }
        }()
    }
    wg.Wait()
    return time.Since(start)
}

func main() {
    for _, p := range []int{1, 2, 4, 8, 16} {
        d := benchCPU(p)
        fmt.Printf("GOMAXPROCS=%2d: %v\n", p, d)
    }
}
// 典型输出（8核机器）：
// GOMAXPROCS= 1: 12.3s
// GOMAXPROCS= 2: 6.2s
// GOMAXPROCS= 4: 3.1s
// GOMAXPROCS= 8: 1.6s   ← 最优
// GOMAXPROCS=16: 1.7s   ← 超过核心数后无提升，反而微降

4.3 面试高频问题

问题 1：请画图解释 GMP 模型

回答要点：

┌─────────────────────────────────────────────────────────┐
│                     Go Process                          │
│                                                         │
│  ┌───────────────── Global Run Queue ──────────────┐    │
│  │  [G] [G] [G] ...  (mutex 保护，低频访问)         │    │
│  └────────────────────────────────────────────────────┘  │
│                                                         │
│  P0 ─────────── P1 ─────────── P2 ─────────── ...     │
│  │ LRQ:[G][G]  │ LRQ:[G]      │ LRQ:[G][G][G]        │
│  │ runnext: G  │ runnext: nil  │ runnext: G           │
│  │ mcache      │ mcache        │ mcache               │
│  │             │               │                       │
│  │ ↕ 绑定      │ ↕ 绑定        │ ↕ 绑定               │
│  │             │               │                       │
│  M0 (thread)  M1 (thread)     M2 (thread)             │
│  │ 正在执行 G  │ 正在执行 G    │ 正在执行 G            │
│                                                         │
│  空闲 M 列表: M3, M4 (等待 P)                          │
│  sysmon: 独立 M，不绑定 P                               │
└─────────────────────────────────────────────────────────┘

数据流：
1. go func() → 新 G 放入当前 P 的 LRQ
2. schedule() → 从 LRQ 取 G 执行
3. LRQ 空 → steal 其他 P 的 LRQ 的一半
4. syscall → P 与 M 解绑 (handoff)
5. G 运行 >10ms → sysmon 发 SIGURG 抢占

问题 2：goroutine 和线程的区别

问题 3：为什么 goroutine 的 ID 不暴露？

Go 团队有意不在 runtime 包中提供获取 goroutine ID 的公开 API。原因是：

1. 暴露 goroutine ID 会诱导开发者写出"thread-local storage"风格的代码（按 ID 存取状态），这违背了 Go 的"通过通信共享内存"哲学
2. goroutine 应该是匿名的、可互换的执行单元，不应该有"身份"
3. 如果确实需要（如日志追踪），应该通过 context.Context 传递请求级别的标识

// 虽然可以 hack 出 goroutine ID，但不推荐
import "runtime"

func goid() int64 {
    var buf [64]byte
    n := runtime.Stack(buf[:], false)
    // 解析 "goroutine 123 [running]:" 中的 123
    // 这是极其 hack 的做法，不要在生产代码中使用
}

问题 4：什么情况下 goroutine 会被调度走？

1. channel 操作阻塞（发送/接收/select）
2. mutex/RWMutex 竞争失败
3. time.Sleep / time.After
4. 网络 I/O（底层走 netpoller）
5. 系统调用（文件 I/O 等）
6. runtime.Gosched() 主动让出
7. 运行超过 10ms 被信号抢占
8. GC STW（Stop The World）
9. 栈增长需要时（极少导致调度，但会暂停执行）

问题 5：如果一个 goroutine 调用了 LockOSThread()，会发生什么？

runtime.LockOSThread()
// 效果：
// 1. 当前 G 被绑定到当前 M，其他 G 不会在此 M 上执行
// 2. 当前 M 也只会执行这个 G
// 3. 如果此 G 创建新 G，新 G 在其他 M 上执行
// 4. 如果此 G 退出或调用 UnlockOSThread()，绑定解除

// 使用场景：
// - CGO 调用（某些 C 库要求在同一线程上调用）
// - GUI 框架（主线程限制）
// - 特定的 Linux namespace 操作（如 setns）

4.4 实际调试：GODEBUG=schedtrace 观察调度行为

Go 运行时提供了强大的内置调试工具，无需修改代码就能观察调度器的实时行为。

schedtrace 基本用法：

# 每 1000ms 输出一次调度器状态
GODEBUG=schedtrace=1000 ./myapp

# 输出示例：
# SCHED 0ms: gomaxprocs=8 idleprocs=5 threads=10 spinningthreads=2
#   idlethreads=3 runqueue=0 [2 0 1 0 3 0 0 1]

各字段含义：

scheddetail 更详细的输出：

GODEBUG=schedtrace=1000,scheddetail=1 ./myapp

# 会额外输出每个 P 和 M 的详细状态
# P0: status=1 schedtick=3423 syscalltick=88 m=0 runqsize=2 gfreecnt=5
# M0: p=0 curg=17 mallocing=0 throwing=0 preemptoff= locks=0
# G17: status=2(running) m=0 lockedm=-1

实战调试案例：排查调度延迟

// 程序表现：某些 HTTP 请求突然变慢（尾延迟 P99 从 5ms 飙到 50ms）
// 使用 schedtrace 观察：

// SCHED 3000ms: gomaxprocs=4 idleprocs=0 threads=12 spinningthreads=0
//   idlethreads=8 runqueue=47 [128 64 0 0]

// 发现：
// 1. idleprocs=0 — 所有 P 都在忙
// 2. runqueue=47 — 全局队列积压了 47 个 G
// 3. [128 64 0 0] — P0 和 P1 的本地队列严重积压，P2 P3 空

// 诊断：P2 和 P3 可能陷入了长时间 syscall（handoff 后 P 转移了）
// 但新创建的 G 仍然集中在 P0/P1 创建
// 解决：检查是否有 goroutine 做了长时间的同步文件 I/O

使用 execution tracer 进行更深入的分析：

import "runtime/trace"

func main() {
    f, _ := os.Create("trace.out")
    trace.Start(f)
    defer trace.Stop()
    
    // ... 你的程序 ...
}

// 然后用 go tool trace 查看：
// go tool trace trace.out
// 可以看到：
// - 每个 P 上 goroutine 的时间线
// - G 从创建到运行的延迟
// - Work stealing 事件
// - 系统调用导致的 P handoff
// - GC STW 的时长和影响

# 获取运行中程序的 trace（通过 pprof HTTP）
curl -o trace.out 'http://localhost:6060/debug/pprof/trace?seconds=5'
go tool trace trace.out

GODEBUG 其他与调度相关的选项：

# 组合使用多个选项
GODEBUG=schedtrace=1000,gctrace=1,madvdontneed=1 ./myapp

# gctrace=1 — GC 日志（能看到 STW 时长，影响调度）
# asyncpreemptoff=1 — 关闭异步抢占（用于对比测试）
# tracebackancestors=N — goroutine 创建链追踪深度

4.5 生产环境最佳实践

实践 1：使用 context 控制 goroutine 生命周期

// 标准模式：所有 goroutine 都应该可取消
func worker(ctx context.Context, tasks <-chan Task) error {
    for {
        select {
        case <-ctx.Done():
            return ctx.Err() // 优雅退出
        case task, ok := <-tasks:
            if !ok {
                return nil // channel 关闭
            }
            if err := process(ctx, task); err != nil {
                return err
            }
        }
    }
}

// 启动时传入可取消的 context
ctx, cancel := context.WithCancel(context.Background())
defer cancel() // 确保所有 worker goroutine 退出

for i := 0; i < numWorkers; i++ {
    go worker(ctx, tasks)
}

实践 2：限制并发 goroutine 数量

// 使用 semaphore 模式限制并发
sem := make(chan struct{}, maxConcurrency)

for _, item := range items {
    sem <- struct{}{} // 获取信号量，可能阻塞
    go func(item Item) {
        defer func() { <-sem }() // 释放信号量
        process(item)
    }(item)
}

// 或使用 errgroup
import "golang.org/x/sync/errgroup"

g, ctx := errgroup.WithContext(ctx)
g.SetLimit(maxConcurrency) // Go 1.20+

for _, item := range items {
    item := item
    g.Go(func() error {
        return process(ctx, item)
    })
}
if err := g.Wait(); err != nil {
    // handle error
}

实践 3：避免 goroutine 在热路径上创建

// 反模式：每个请求创建 goroutine 做超时控制
func handleRequest(w http.ResponseWriter, r *http.Request) {
    done := make(chan struct{})
    go func() {
        result := doWork()     // 每个请求一个新 goroutine
        sendResponse(w, result)
        close(done)
    }()
    select {
    case <-done:
    case <-time.After(5 * time.Second):
        http.Error(w, "timeout", 504)
    }
}

// 优化：使用 context 超时（不需要额外 goroutine）
func handleRequest(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
    defer cancel()
    
    result, err := doWork(ctx) // 在当前 goroutine 中执行
    if err != nil {
        if ctx.Err() == context.DeadlineExceeded {
            http.Error(w, "timeout", 504)
            return
        }
        http.Error(w, err.Error(), 500)
        return
    }
    sendResponse(w, result)
}

实践 4：监控 goroutine 趋势而非绝对数

// 不要只看绝对数——看趋势
// goroutine 数量缓慢但持续增长 = 泄漏
// goroutine 数量随负载波动但有上限 = 正常

// Grafana 告警规则伪代码：
// IF deriv(go_goroutines[1h]) > 10
//    AND go_goroutines > 5000
// THEN alert("possible goroutine leak")

4.6 边界情况与陷阱

陷阱 1：GOMAXPROCS=1 下的"伪死锁"

runtime.GOMAXPROCS(1)
ch := make(chan int)

go func() {
    ch <- 1
}()

// 如果当前 goroutine 在此处做了大量计算
// 且 Go 版本 < 1.14（无异步抢占）
// 新的 goroutine 永远得不到执行机会
// ch <- 1 永远不会发生
// 程序卡死（不是死锁，是饿死）
for {
    // tight loop without function calls
}
<-ch // 永远到不了这里

陷阱 2：CGO 调用锁住 M

// CGO 调用期间，M 被锁定（LockOSThread 的效果）
// 如果有大量 goroutine 同时做 CGO 调用
// 可能导致 M 数量暴涨到 10000 上限

/*
#include <unistd.h>
void slow_c_func() {
    sleep(10); // 阻塞 10 秒
}
*/
import "C"

func main() {
    for i := 0; i < 10001; i++ {
        go func() {
            C.slow_c_func() // 每个 goroutine 锁住一个 M
        }()
    }
    // 可能触发 "thread exhaustion" 导致程序崩溃
}
// 解决方案：使用 worker pool 限制并发 CGO 调用

陷阱 3：GC STW 对延迟的影响

// GC 的 STW（Stop The World）阶段会暂停所有 goroutine
// 在 Go 1.18+ STW 通常只有几十微秒
// 但如果有大量 goroutine，STW 的"栅栏"效应会增大延迟

// 观察 GC STW 时长：
// GODEBUG=gctrace=1 ./myapp
// gc 1 @0.012s 2%: 0.044+1.2+0.033 ms clock, 0.35+0.8/1.1/0+0.26 ms cpu ...
//                   ^^^                ^^^
//                   STW mark start     STW mark termination

// 减少 GC 压力 = 减少 STW 频率 = 降低调度延迟

陷阱 4：runtime.LockOSThread 的继承性

func init() {
    // main goroutine 在 init 中锁定 OS 线程
    runtime.LockOSThread()
    // 注意：如果 main goroutine 退出而没有 UnlockOSThread
    // 线程会被销毁而非回收到空闲池
}

// 此外，LockOSThread 是可以嵌套的
runtime.LockOSThread()
runtime.LockOSThread() // 计数 +1
runtime.UnlockOSThread() // 计数 -1，仍然锁定
runtime.UnlockOSThread() // 计数归零，解锁

本章总结

GMP 调度器是 Go 语言最核心的运行时组件之一。它的设计精妙地平衡了多个目标：

1. 高效创建：goroutine 的创建是纯用户态操作，成本约 0.3μs
2. 公平调度：work stealing 保证负载均衡，信号抢占防止饿死
3. 系统调用不阻塞调度：P 与 M 解绑（handoff）确保 CPU 不闲置
4. 可扩展性：本地无锁队列消除全局锁瓶颈

理解 GMP 模型不只是面试需要——它帮助你：

• 诊断 goroutine 泄漏和调度延迟问题
• 合理设置 GOMAXPROCS（特别是在容器环境）
• 理解为什么某些操作（channel、mutex、I/O）会触发调度
• 写出更符合调度器友好的并发代码

推荐进一步阅读：

1. Dmitry Vyukov, "Scalable Go Scheduler Design Doc" (2012) — GMP 模型的原始设计文档
2. Blumofe & Leiserson, "Scheduling Multithreaded Computations by Work Stealing" (JACM 1999) — work stealing 理论基础
3. Austin Clements, "Proposal: Non-cooperative goroutine preemption" (Go proposal #24543, 2018) — 异步抢占提案
4. Go 源码 runtime/proc.go — 调度器的完整实现（约 6000 行）
5. go tool trace 文档 — 可视化调度行为的最佳工具