当前位置：首页 > news >正文

Golang 的 GMP 调度机制常见问题及解答

news 来源：原创 2025/7/17 14:31:30

文章目录

Golang GMP 调度模型详解
常见问题
- 基础概念
- - 1. GMP 各组件的作用是什么？
  - 2. 为什么 Go 需要自己的调度器？
  - 3. GOMAXPROCS 的作用是什么？
- 调度流程
- - 4. Goroutine 如何被调度到 M 上执行？
  - 5. 系统调用会阻塞整个线程吗？
  - 6. 什么是自旋线程（Spinning Thread）？
- 高级特性
- - 7. Work Stealing 如何提升性能？
  - 8. Go 如何实现抢占式调度？
  - 9. 全局队列 vs. 本地队列的优势？
  - 10. Goroutine 泄露会导致什么问题？
  - 11. 如何诊断调度器瓶颈？
  - 12. 为什么 Goroutine 比线程更高效？
- 实战场景
- - 13. GOMAXPROCS 设为 1 会发生什么？
  - 14. 大量 Goroutine 卡在 channel 会怎样？
  - 15. 如何优化高并发下的调度性能？
csview 中有关 GMP 调度机制的八个问题
- 1. 简单介绍 GMP 模型？
- 2. 简述 GMP 的调度流程？
- 3. P 和 M 的个数？
- 4. P 和 M 何时被创建？
- 5. 简述 goroutine 的创建流程？
- 6. goroutine 何时会被挂起？
- 7. 同时启动了一万个 goroutine，会如何调度？
- 8. goroutine 内存泄露和处理办法？

Golang GMP 调度模型详解

Golang 的 GMP 调度模型是 Go 语言高并发能力的核心设计，由以下三个组件组成：

G（Goroutine）：轻量级用户态线程，所占用的内存更小（初始 2 KB），由 Go 运行时管理。
M（Machine）：操作系统线程（OS Thread），负责执行 Goroutine，与内核线程一一对应。
P（Processor）：逻辑处理器，管理 Goroutine 队列（本地队列），充当 M 和 G 的调度上下文。

核心机制：

协作式调度：Goroutine 会主动让出资源（如通过 channel 阻塞或函数调用时）；
抢占式调度：通过系统信号抢占长时间运行的 G；
Work Stealing：当 P 的本地队列为空时，从其它 P 或全局窃取 G；
Hand Off 机制：当 G 阻塞时，M 释放 P 给其它 M 使用，避免资源浪费。

常见问题

基础概念

1. GMP 各组件的作用是什么？

G 是轻量级的用户态线程，是执行任务的最小单元；M 是操作系统级别的线程，是实际执行 G 的线程；P 是逻辑处理器，用于管理 G 的队列，并负责提供调度上下文。

2. 为什么 Go 需要自己的调度器？

因为传统的操作系统级线程切换成本高（需要由用户态切换到内存态度），GMP 模型通过用户态调度、复用线程并减少锁竞争，支持百万级 Goroutine 并发。

3. GOMAXPROCS 的作用是什么？

设置 P 的数量（默认等于 CPU 核数），决定并行执行的 Goroutine 数量。

调度流程

4. Goroutine 如何被调度到 M 上执行？

P 将本地队列中的 G 绑定到 M，若本地队列为空，则 P 从全局队列窃取或创建新的 G。

5. 系统调用会阻塞整个线程吗？

会，但 Go 的 GMP 调度机制会将 M 与 P 解绑，P 将被分配到空闲的 M 或新创建的 M，避免 G 阻塞。

6. 什么是自旋线程（Spinning Thread）？

M 在寻找可用的 G 时不进入休眠，而是循环检查队列，减少唤醒延迟，但会占用 CPU。

高级特性

7. Work Stealing 如何提升性能？

通过分散调度压力，避免单个 P 的队列成为瓶颈，提升多核利用率。

8. Go 如何实现抢占式调度？

通过向 M 发送 SIGURG 信号，触发调度器检查并抢占运行过久的 G。

9. 全局队列 vs. 本地队列的优势？

全局队列公平但加锁，本地队列无锁但可能导致负载不均，Work Stealing 弥补了这一点。

10. Goroutine 泄露会导致什么问题？

M 和 P 资源占用增加，可能导致程序内存耗尽或调度延迟升高。

11. 如何诊断调度器瓶颈？

使用 go tool trace 查看调度延迟，或通过 GODEBUG=schedtrace=1000 输出调度信息。

12. 为什么 Goroutine 比线程更高效？

Goroutine 的栈可动态扩容，线程切换由用户态调度，避免了从用户态陷入到内核态的上下文切换开销。

实战场景

13. GOMAXPROCS 设为 1 会发生什么？

所有 Goroutine 串行执行，无法利用多核，但并发逻辑仍可通过调度正常运行。

14. 大量 Goroutine 卡在 channel 会怎样？

调度器会将阻塞的 G 移出 M，M 继续执行其它 G，但过多的阻塞 G 会增加调度开销。

15. 如何优化高并发下的调度性能？

减少锁竞争（如使用局部变量）、避免过度阻塞操作、调整 GOMAXPROCS 或拆分任务。

csview 中有关 GMP 调度机制的八个问题

1. 简单介绍 GMP 模型？

G（Goroutine）：是 Golang 中协程 Goroutine 的缩写，相当于操作系统中的进程控制块。G 当中存放着 goroutine 运行时的栈信息、CPU 的一些寄存器状态以及执行的函数指令等。

M（Machine）：代表一个操作系统的主线程，是对内核现成的封装，M 的数量对应于真实的 CPU 数。一个 M 直接关联一个 OS 内核线程，用于执行 G。M 会优先从关联的 P 的本地队列中直接获取待执行的 G。

P（Processor）：代表了 M 所需要的上下文环境，保存着 M 运行 G 所需要的全部资源。P 是处理用户级代码逻辑的处理器，可以将其看作一个局部调度器，使得 Golang 代码块可以在操作系统线程上运行。当 P 上有任务时，就需要创建或唤醒一个系统线程来执行其本地队列当中的任务，所以 P 和 M 是相互绑定的。

2. 简述 GMP 的调度流程？

每个 P 都有局部队列，局部队列保存待执行的 goroutine，当 M 绑定的 P 的局部队列已满时，新追加的 goroutine 就会被放到全局队列。
每一个 P 都和 M 绑定，M 是真正执行 P 中 goroutine 的实体，M 会从其所绑定的 P 当中获取 G 来执行。
当 M 绑定的 P 的局部队列为空时，M 会从全局队列获取 goroutine 并转移到本地队列来执行 G，当从全局队列仍然没有可执行的 G 时，M 会从其它 P 的本地队列中偷取（Work Stealing）G 来执行。
当 G 因系统调用（syscall）阻塞时，会阻塞 M，此时 P 会和 M 解绑（hand off），并寻找新的空闲的 M，若没有空闲的 M，就会新建一个 M（模糊点：需要注意的是，此时 P 与 M 解绑并与新的 M 绑定，继续执行 P 中其它可执行的 G，因为之前的 G 因系统调用将 M 阻塞了。当之前的 G 系统调用完成并恢复之后，被阻塞的 G 会被直接放回原 P 的本地队列，若原来的 P 已经被占用，则将 G 放入全局队列。位于全局队列当中的 G 可以通过 work stealing 被其它 P 窃取）。
当 G 因 channel 或 network I/O 阻塞时，不会阻塞 M，M 会寻找其它可执行的 G。当阻塞的 G 恢复后会重新进行可执行状态并进入 P 队列等待执行。

3. P 和 M 的个数？

P：由启动时环境变量 GOMAXPROCS 决定。这意味着程序执行的任意时刻都只有 GOMAXPROCS 个 goroutine 在同时执行。
M：Go 程序启动时，会设置 M 的最大数量，默认为 10000，但内核很难支持这么多的线程数，所以这个限制可以忽略；一个 M 阻塞时，会创建新的 M。

总结
M 与 P 的数量没有绝对关系，一个 M 阻塞，P 就会去寻找空闲的 M，如果没有空闲的 M，那么就创建一个新的 M。因此，即使 P 的默认数量为 1，也有可能创建很多个 M 出来。

4. P 和 M 何时被创建？

P：在确定了 P 的最大数量 n 后，运行时系统会创建 n 个 P。

M：在没有足够的 M 来关联 P 并运行其中的 G 时，会创建新的 M 并关联 P。正如上文所提到的，假设当前所有 M 都由于 G 需要系统调用而阻塞了，而 P 当中还有很多就绪的 G，那么就会创建新的 M 来与 P 绑定。

5. 简述 goroutine 的创建流程？

调用 go func() 时，会调用 runtime.newproc 来创建一个 goroutine，这个 goroutine 有自己的栈空间，同时在 G 的 sched 中维护栈地址与程序计数器信息（即调用 go func() 之后，创建一个 goroutine 并维护 goroutine 运行所需要的状态，比如栈空间以及程序计数器信息）。

创建好的 goroutine 会被放到它对应的内核线程 M 所使用的上下文 P 的 run_queue 中（如果 run_queue 已满，则保存至其它 P 的 run_queue，如果所有 P 的 run_queue 都满了，那么送至全局队列），等待 GMP 调度器决定这个 G 何时取出并执行（又分为两种情况，可能顺序等待自己的 P 调度执行，也可能触发 work stealing 由其它 M 执行）。

6. goroutine 何时会被挂起？

宏观上来说分为两种情况，分别是 goroutine 触发系统调用阻塞，以及 goroutine 等待 channel 或 network I/O。

触发系统调用而阻塞时，G 的 M 会被阻塞，此时与 M 绑定的 P 会寻找一个空闲的 M（无空闲 M 时创建一个新的 M），并取出当前处于就绪态的 G 执行。刚才触发系统调用的 G 在结束系统调用后，被阻塞的 M 会进入休眠状态，等待下一次被唤醒，G 会尝试放入原来 P 的本地队列，如果 P 的本地队列已满，则 G 被放入全局队列。位于全局队列中的 G 会通过 work stealing 机制被其它 P 窃取。

当 goroutine 等待 channel 或 network I/O 而阻塞时，不会阻塞 M，此时 M 会立即取出 P 中其它空闲的 G 执行。当前阻塞的 G 在就绪时会优先放入原来 P 的本地队列当中，否则将 G 放入全局队列。

7. 同时启动了一万个 goroutine，会如何调度？

一万个 G 会按照 P 的设定个数，尽可能平均地分配到每个 P 的本地队列当中。如果所有本地队列都已满，那么就放入 GMP 的全局队列当中。接下来开始执行 GMP 模型的调度策略：

本地队列轮转：每一个 P 都维护着一个保存着 G 的本地队列。不考虑 G 进行系统调用和 I/O 情况下的阻塞，P 会周期性地从本地队列中调度 G 到 M 执行，执行一段时间后将 G 的上下文保存起来并插入到队尾，再从队首调度 G 执行；
系统调用：P 的个数默认等于 CPU 的核数，每一个 M 必须与 P 绑定才能够运行 P 队列当中的 G。通常来说，运行时 M 的个数会略大于 P 的个数，原因是当 G 触发系统调用时，M 会被阻塞，此时与 M 绑定的 P 会触发 hand off 机制与 M 解绑，并寻找一个新的空闲的 M1 并与之绑定，继续执行这个 P 中就绪的 G。被阻塞的 M 就绪时，会进入休眠状态，等待下一次与 P 绑定。
工作量窃取：多个 P 中维护的 G 队列可能是不平衡的，当某个 P 执行完了全部本地队列当中的 G，就会去查询全局队列，如果全局队列在无 G，那么就从另一个 P 的本地队列当中窃取 G 并执行。一般来说每次窃取一半。

8. goroutine 内存泄露和处理办法？

Goroutine 内存泄漏是指程序中启动的 goroutine 由于某些原因无法正常退出，从而长期占用了内存和资源，最终导致程序内存耗尽或性能下降。

预防 Goroutine 泄露的最佳实践

始终为阻塞操作设置超时（如 channel、I/O 请求，可以通过 select + time.After 来完成）；
使用 context 传递取消信号，确保 goroutine 可以及时退出；
优先使用带 buffer 的 channel，避免无缓存 channel 的意外阻塞；
通过 defer 关闭资源；
定期检查 goroutine 的数量，结合监控工具预警异常增长（比如 pprof 和 go tool trace）