↓Skip to main content

golang协程调度器原理与GMP设计思想

·217 words·2 mins
WFUing
Author
WFUing
A graduate who loves coding.
Table of Contents

目标：掌握Golang协程调度器原理：为什么Go的协程的调度是快的

  1. Golang调度器的由来
  2. Goroutine调度器的GMP模型的设计思想
  3. Go调度器GMP调度场景的全过程分析

资料

Golang调度器的由来
#

单进程操作系统
#

单进程时代的两个问题：

  • 单一执行流程、计算机只能一个任务一个任务地处理
  • 进程阻塞所带来的CPU时间浪费

多线程/多进程操作系统

并发执行

问题：

  • 如果进程/线程的数量越多，切换成本就越大，也就越浪费
  • 多线程随着同步进程（如锁、竞争冲突等）

多进程、多线程
#

多进程、多线程的壁垒

  • 高内存占用
    • 进程占用内存：虚拟内存4GB（32bit OS）
    • 线程占用内存：约4MB
  • 高CPU调度消耗

协程（co-routine）引发的问题
#

线程在golang中的处理：

N:1

  • 无法利用多个CPU
  • 若一个协程阻塞了，会影响下一个协程的调度，出现阻塞瓶颈

1:1

  • 跟多进程/多线程模型无异
  • 协程创建、删除和切换的代价都由CPU完成，有点略显昂贵

N:M

  • 能够利用多核
  • 过于依赖协程调度器的优化

Golang对调度器的优化
#

Go routine的优化

线程内存占用只有几KB，可以大量开辟；可以灵活调度，切换成本低

早期调度器的处理

基本的全局Go队列和比较传统的轮询利用多个thread去调度

老调度器的缺点：

  1. 创建、销毁、调度G都需要每个M获取锁，这就形成了激烈的锁竞争
  2. M转移G会造成延迟和额外的系统负载
  3. 系统调用（CPU在M之间的切换）导致频繁的线程阻塞和取消阻塞操作增加了系统开销

Goroutine调度器的GMP模型的设计思想
#

GMP模型的简介
#

  • G：goroutine 协程
  • P：processor 处理器
  • M：thread 内核线程

  • 全局队列：存放等待运行的G
  • P的本地队列：
    • 存放等待运行的G；
    • 有数量限制，不超过256G；
    • 优先将新创建的G放在P的本地队列中，如果满了会放在全局队列中
  • P列表：
    • 程序启动时创建
    • 最多有 GOMAXPROCS 个（可配置）
  • M列表当前操作系统分配到当前GO程序的内核线程数
  • P和M的数量：
    • P的数量问题：
      • 通过环境变量 $GOMAXPROC
      • 在程序中通过 runtime.GOMAXPROCS() 来设置
    • M的数量问题：
      • Go语言本身是限定了M的最大量是10000（忽略）
      • 通过 runtime/debug 包中的 SetMaxThreads 函数来设置
      • 有一个 M 阻塞，会创建一个新的 M
      • 如果有 M 空闲，那么就会回收或者睡眠

调度器的设计策略
#

  • 复用线程
  • 利用并行
  • 抢占
  • 全局G队列

复用线程

避免频繁的创建、销毁线程，而是对线程的复用

work stealing机制

当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程。

hand off机制

当本线程因为G进行系统调用阻塞时候，线程释放绑定的P，把P转移给其他空闲的线程执行

利用并行

GOMAXPEOCS限定P的个数 = CPU核数/2

最多有GPMAXPROCS个线程分布在多个CPU上同时运行

抢占

在coroutine中要等待一个协程主动让出CPU才执行下一个协程，在Go中，一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死。

全局G队列

当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G。

加锁、解锁，从全局G队列获取

go func() 经历了什么过程
#

  1. 我们通过 go func 来创建一个goroutine；
  2. 有两个存储G的队列，一个是局部调度器P的本地队列、一个是全局G队列。新创建的G会先保存在P的本地队列中，如果P的本地队列已经满了就会保存在全局的队列中；
  3. G只能运行在M中，一个M必须持有一个P，M与P是1:1的关系。M会从P的本地队列弹出一个可执行状态的G来执行，如果P的本地队列为空，就会想其他的MP组合偷取一个可执行的G来执行；
  4. 一个M调度G执行的过程是一个循环机制；
  5. 当M执行某一个G时候如果发生了syscall或则其余阻塞操作，M会阻塞，如果当前有一些G在执行，runtime会把这个线程M从P中摘除（detach），然后再创建一个新的操作系统的线程（如果有空闲的线程可用就复用空闲线程）来服务于这个P；
  6. 当M系统调用结束时候，这个G会尝试获取一个空闲的P执行，并放入到这个P的本地队列。如果获取不到P，那么这个线程M变成休眠状态，加入到空闲线程中，然后这个G会被放入全局队列中。

调度器的生命周期
#

M0

  • M0是启动程序后的编号为0的主线程
  • 这个M对应的实例会在全局变量runtime.m0中，不需要在heap上分配
  • M0负责执行初始化操作和启动第一个G
  • 启动第一个G之后，M0就和其他的M一样了

G0

  • G0每次启动一个M，都会第一个创建的goroutine，就是GO
  • G0仅用于负责调度的G
  • G0不指向任何可执行的函数
  • 每个M都会有一个自己的G0
  • 在调度或系统调用时会使用G0的栈空间，会使用M会切换到G0，来调度
  • M0的G0会放在全局空间，全局变量的G0是M0的G0

可视化的GMP编程
# 

import(
  "fmt"
  "os"
  " runtime/trace"
)
//trace的编程过程
//1 创建文件
//2 启动
//3 停止

func main() {
  //1.创建一个trace文件
  f, err := os.Create("trace.out")
  if err != nil {
    panic(err)
  }

  defer f.Close()

  //2.启动trace
  err = trace.Start (f)
  if err != nil {
    panic(err)
  ｝

  //正常要调试的业务
  fmt.Println("Hello GMP")

  //3.停止trace
  trace.Stop()

}
  • 基本的trace编程
    • 创建trace文件：f, err := os.Create("trace.out")
    • 启动trace：trace.Start(f)
    • 停止trace：trace.Stop()
    • go build 并且运行之后，会得到一个 trace.out 文件
  • 通过 go tool trace 工具打开 trace 文件：go tool trace trace.out

💬评论