Go 调度器：GMP 模型与抢占式调度的深度解析

1. GMP 模型：调度器的核心架构

Go 的调度器采用了 GMP（Goroutine - Machine - Processor）模型，这一设计使得 Go 能够在少量 OS 线程上调度海量 Goroutine，实现了 M:N 的线程模型。

1.1 核心组件

// 核心数据结构 (src/runtime/runtime2.go)

// Goroutine
type g struct {
    stack       stack       // 栈信息
    m            *m          // 所属的 M
    sched        gobuf       // 调度信息（PC, SP 等）
    atomicstatus uint32      // 状态：running, runnable, waiting...
    waitreason   string      // 等待原因
    goid         uint64     // Goroutine ID
    // ...
}

// Machine (OS Thread)
type m struct {
    g0      *g              // 调度栈的 Goroutine
    curg    *g              // 当前运行的 G
    p       *p              // 绑定的 P
    nextp   *p              // 下一个要绑定的 P
    spinning bool           // 是否在窃取工作
    // ...
}

// Processor (调度上下文)
type p struct {
    runq    [256]guintptr   // 本地运行队列
    runqhead uint32
    runqtail uint32
    m       *m              // 所属的 M
    status  uint32          // idle, running, syscall...
    // ...
}

1.2 M:N 线程模型的优势

与 Java Virtual Thread 的 M:N 模型不同，Go 的 GMP 模型中 P 的数量固定为 GOMAXPROCS（默认等于 CPU 核数），这使得调度更加可预测。

// Go 调度器的启动流程
func bootstrap() {
    // 1. 创建初始 P
    for i := 0; i < gomaxprocs; i++ {
        allp[i] = allocm()
    }

    // 2. 创建 M 运行 schedule()
    for i := 0; i < gomaxprocs; i++ {
        newm(nil, allp[i])
    }

    // 3. 主 Goroutine 运行 main()
   .main()
}

// 每个 M 都在执行 schedule() 循环
func schedule() {
    // 1. 从本地队列获取 G
    gp, inheritTime := runqget(gp)
    if gp == nil {
        gp = findrunnable() // 工作窃取
    }

    // 2. 执行 G
    execute(gp, inheritTime)
}

2. Goroutine 队列与工作窃取

Go 调度器采用两级队列结构：每个 P 有本地队列，全局有共享队列。同时实现了工作窃取（Work-Stealing）机制来保证负载均衡。

2.1 本地运行队列

// 本地队列是一个无锁的环形队列
type p struct {
    runq    [256]guintptr   // 最多 256 个 G
    runqhead uint32
    runqtail uint32
    // ...
}

// 入队操作：无锁快速路径
func runqput(gp *g, next bool) {
    // 如果 next=true，插入到队列头部（用于新 G）
    // 否则插入到尾部
}

// 当本地队列满时，溢出到全局队列
func runqputslow(gp *g, h, t uint32) {
    // 从队列中间选取一半 G 放入全局队列
    // 让出一半的队列空间
}

2.2 工作窃取算法

当本地队列为空时，M 会从其他 P 的队列"窃取"工作。这确保了即使某个 P 的 G 数量很少，也能获得公平的执行机会。

func findrunnable() *g {
    // 1. 尝试从本地队列获取
    gp, _ := runqget(gp)
    if gp != nil {
        return gp
    }

    // 2. 从全局队列获取
    gp = globrunqget(gp, 0)
    if gp != nil {
        return gp
    }

    // 3. 从其他 P 窃取
    for i := 0; i < 4; i++ {
        // 随机选择目标 P
        target := randomP()
        if runqempty(target) {
            continue
        }

        // 原子性地从目标队列取走一半 G
        gp = runqsteal(target)
        if gp != nil {
            return gp
        }
    }

    // 4. 阻塞等待新 G
    return park()
}

2.3 窃取时机与开销

3. 抢占式调度：从协作到异步

Go 的抢占式调度经历了从协作式到异步的演进。理解这一过程有助于诊断高并发场景下的调度问题。

3.1 协作式抢占（Go 1.13 之前）

早期 Go 的抢占依赖于 Garbage Collection（GC）协作。当 GC 发生时，所有 Goroutine 会被标记并暂停，但这导致长计算任务可能阻塞调度。

// 协作式抢占的问题
func heavyComputation() {
    for i := 0; i < 1_000_000_000; i++ {
        // 如果这里没有函数调用，GC 无法抢占
        // 导致其他 Goroutine 饥饿
        _ = i * 2
    }
}

// 解决方案：插入安全点检查
func safeHeavyComputation() {
    for i := 0; i < 1_000_000_000; i++ {
        // runtime.Gosched() 主动让出
        if i % 1000 == 0 {
            runtime.Gosched()
        }
        _ = i * 2
    }
}

3.2 异步抢占（Go 1.14+）

Go 1.14 引入了基于信号的异步抢占。当 P 的时间片用尽时，调度器向 M 发送 SIGURG 信号，中断当前 Goroutine。

// 异步抢占的实现
// 当 G 运行超过 sysmon 或 scheduler 检查点时
func preempt(gp *g) {
    // 发送信号给 M
    signalM(m, sigPreempt)

    // M 的信号处理器会调用 asyncMNote
    // 进而调用 mstart 进入调度循环
}

// 信号处理（src/runtime/signal_unix.go）
func sighandler(sig, ctxt uintptr) {
    if sig == sigPreempt {
        // 触发抢占
        goexit()
    }
}

3.3 抢占的代价与限制

异步抢占虽然解决了长计算任务的饥饿问题，但也带来了额外的开销和限制。

4. Pacing 算法与公平性

Go 调度器使用 Pacing 算法控制 Goroutine 的时间片分配，确保公平性和低延迟。

4.1 时间片分配

// 时间片常量
const (
    // 纳秒时间片
    // 默认 10ms，但会根据 GOMAXPROCS 动态调整
    globalSchedPacePeriod = 10 * 1000 * 1000 // 10ms

    // 每个 G 的最小时间片
    // 当 GOMAXPROCS 较大时，时间片会减少
    minQuantum = 1000 * 1000 // 1ms
)

// 调度决策时检查是否用尽时间片
func shouldYield(gp *g) bool {
    // 检查是否超过时间片
    if !sched.bucket.tick - gp.slice >= 0 {
        return true
    }
    // 检查优先级
    if gp.priority < gQueueScanPriority {
        return true
    }
    return false
}

4.2 GC Pacing

Go 的 GC 与调度器深度集成，通过 GC Pacing 控制何时启动 GC 以及并行度。

// GC Pacing 的核心逻辑
func gcPacing() {
    // 计算目标 GC 结束时间
    // 确保在下一次 GC 开始前有足够的时间片
    goal := atomic.LoadInt64(&gcController.targetEndTime)

    // 计算应该启动 GC 的时机
    // 基于内存分配速率和 CPU 利用率
    if goal - now > gcPauseSlack {
        // 继续运行，等待更合适的时机
        return
    }

    // 启动 GC
    gcStart(trigger)
}

5. 重度计算场景下的调度陷阱

在 CPU 密集型工作负载中，调度器的行为可能与直觉不符。理解这些陷阱有助于写出高效的 Go 代码。

5.1 密集计算导致的饥饿

// 问题：大量 CPU 密集型 Goroutine
func main() {
    runtime.GOMAXPROCS(4) // 4 核

    for i := 0; i < 1000; i++ {
        go func() {
            // 没有 I/O，纯粹的数学计算
            sum := 0
            for j := 0; j < 1_000_000; j++ {
                sum += j * j
            }
        }()
    }

    // 调度器可能在这些 G 之间分配不均
    // 导致某些请求延迟极高
}

// 解决方案：定期让出时间片
func betterComputation() {
    sum := 0
    for j := 0; j < 1_000_000; j++ {
        sum += j * j
        if j % 1000 == 0 {
            runtime.Gosched() // 让出 CPU
        }
    }
}

5.2 锁竞争导致的调度延迟

// 问题：全局锁的持有时间过长
var globalLock sync.Mutex
var counters = make(map[int]int)

func updateCounter(id, value int) {
    globalLock.Lock()
    counters[id] = value  // 快速操作
    globalLock.Unlock()   // 但仍可能导致竞争
}

// 更好的做法：分片锁
type ShardedCounters struct {
    shards []struct {
        mu   sync.Mutex
        data map[int]int
    }
}

func (s *ShardedCounters) Update(id, value int) {
    shard := id % len(s.shards)
    shard.mu.Lock()
    shard.data[id] = value
    shard.mu.Unlock()
}

5.3 channel 阻塞的调度影响

// channel 操作会触发调度
func channelDemo() {
    ch := make(chan int, 1)

    go func() {
        for {
            select {
            case v := <-ch:
                process(v)
            case <-done:
                return
            }
        }
    }()

    // 当 ch 为空时，接收操作会 park 当前 G
    // 调度器会立即选择其他可运行的 G
}

5.4 调优参数建议