深入理解GMP模型

1、GMP模型的设计思想

1)、GMP模型

GMP分别代表:

  • G:goroutine,Go协程,是参与调度与执行的最小单位
  • M:machine,系统级线程
  • P:processor,包含了运行goroutine的资源,如果线程想运行goroutine,必须先获取P,P中还包含了可运行的G队列

在Go中,线程是运行goroutine的实体,调度器的功能是把可运行的goroutine分配到工作线程上

深入理解GMP模型_第1张图片
  1. 全局队列(Global Queue):存放等待运行的G。全局队列可能被任意的P去获取里面的G,所以全局队列相当于整个模型中的全局资源,那么自然对于队列的读写操作是要加入互斥动作的
  2. P的本地队列:同全局队列类似,存放的也是等待运行的G,存的数量有限,不超过256个。新建G’时,G’优先加入到P的本地队列,如果队列满了,则会把本地队列中一半的G移动到全局队列
  3. P列表:所有的P都在程序启动时创建,并保存在数组中,最多有GOMAXPROCS(可配置)个
  4. M:线程想运行任务就要获取P,从P的本地队列获取G,当P队列为空时,M也会尝试从全局队列拿一批G放到P的本地队列,或从其他P的本地队列偷一半放到自己P的本地队列。M运行G,G执行之后,M会从P获取下一个G,不断重复下去

goroutine调度器和OS调度器是通过M结合起来的,每个M都代表了一个内核线程,OS调度器负责把内核线程分配到CPU的核上执行

有关P和M的个数问题:

1)P的数量由启动时环境变量 G O M A X P R O C S 或者是由 r u n t i m e 的方法 G O M A X P R O C S ( ) 决定。这意味着在程序执行的任意时刻都只有 GOMAXPROCS或者是由runtime的方法GOMAXPROCS()决定。这意味着在程序执行的任意时刻都只有 GOMAXPROCS或者是由runtime的方法GOMAXPROCS()决定。这意味着在程序执行的任意时刻都只有GOMAXPROCS个goroutine在同时运行

2)M的数量由Go语言本身的限制决定,Go程序启动时会设置M的额最大数量,默认10000个,但是内核很难支持这么多的线程数,所以这个限制可以忽略。runtime/debug中的SetMaxThreads()函数可设置M的最大数量,当一个M阻塞了时会创建新的M

M与P的数量没有绝对关系,一个M阻塞,P就会去创建或者切换另一个M,所以,即使P的默认数量是1,也有可能会创建很多个M出来

P和M何时会被创建:

1)P创建的时机在确定了P的最大数量n后,运行时系统会根据这个数量创建n个P

2)M创建的时机是在当没有足够的M来关联P并运行其中可运行的G的时候。比如所有的M此时都阻塞住了,而P中还有很多就绪任务,就会去寻找空闲的M,如果此时没有空闲的M,就会去创建新的M

2)、调度器的设计策略

策略一:复用线程

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

1)偷取(work stealing)机制

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

2)移交(hand off)机制

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

策略二:利用并行

GOMAXPROCS设置P的数量,最多有GOMAXPROCS个线程分布在多个CPU上同时运行。GOMAXPROCS也限制了并发的程度,比如GOMAXPROCS=核数/2,则最多利用了一半的CPU核进行并行

策略三:抢占

在coroutine中要等待一个协程主动让出CPU才执行下一个协程,在Go中,一个goroutine最多占用CPU 10ms,防止其他goroutine被饿死,这就是goroutine不同于coroutine的一个地方

策略四:全局G队列

当P的本地队列为空时,优先从全局G队列获取,如果全局队列为空时则通过work stealing机制从其他P的本地队列偷取G

3)、go func()调度流程
深入理解GMP模型_第2张图片

从上图可以分析出几个结论:

  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中摘除,然后再创建一个新的操作系统线程(如果有空闲的线程可用就复用空闲线程)来服务这个P
  6. 当M系统调用结束的时候,这个G会尝试获取一个空闲的P执行,并放入到这个P的本地队列。如果获取不到P,那么这个线程M变成休眠状态,加入到空闲线程中,然后这个G会被放入全局队列中
4)、调度器的生命周期
深入理解GMP模型_第3张图片

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

G0:G0是每次启动一个M都会第一个创建的gourtine,G0仅用于负责调度的G,G0不指向任何可执行的函数,每个M都会有一个自己的G0。在调度或系统调用时会使用G0的栈空间,全局变量的G0是M0的G0

package main

import "fmt"

func main() {
	fmt.Println("Hello world")
}

针对上面的代码对调度器里面的结构做一个分析:

  1. runtime创建最初的M0和gourtine G0,并把两者关联
  2. 调度器初始化:初始化M0、栈、垃圾回收,以及创建和初始化由GOMAXPROCS个P构成的P列表
  3. 示例代码中main函数是main.main,runtime中也有一个main函数:runtime.main,代码经过编译后,runtime.main会调用main.main,程序启动时会为runtime.main创建gourtine,称它为main gourtine吧,然后把main gourtine加入到P的本地队列
  4. 启动M0,M0已经绑定了P,会从P的本地队列获取G,获取到main gourtine
  5. G拥有栈,M根据G中的栈信息和调度信息设置运行环境
  6. M运行G
  7. G退出,再次回到M获取可运行的G,这样重复下去,直到main.main退出,runtime.main执行Defer和Panic处理,或调用runtime.exit退出程序

调度器的生命周期几乎占满了一个Go程序的一生,runtime.main的gourtine执行之前都是为调度器做准备工作,runtime.main的gourtine运行,才是调度器的真正开始,直到runtime.main结束而结束

2、Go调度器调度场景过程全解析

1)、场景1

P拥有G1,M1获取P后开始运行G1,G1使用go func()创建了G2,为了局部性G2优先加入到P1的本地队列

深入理解GMP模型_第4张图片
2)、场景2

G1运行完成后(函数:goexit),M上运行的gourtine切换为G0,G0负责调度时协程的切换(函数:schedule)。从P的本地队列取G2,从G0切换到G2,并开始运行G2(函数:execute)。实现了线程M1的复用

深入理解GMP模型_第5张图片
3)、场景3

假设每个P的本地队列只能存3个G。G2要创建6个G,前3个G(G3、G4、G5)已经加入P1的本地队列,P1本地队列满了

深入理解GMP模型_第6张图片
4)、场景4

G2在创建G7的时候,发现P1的本地队列已满,把P1中本地队列中前一半的G,还有新创建G转移到全局队列(实现中并不一定是新的G,如果G是G2之后就执行的,会被保存在本地队列,利用某个老的G替换新G加入全局队列)

深入理解GMP模型_第7张图片

这些G被转移到全局队列时,会被打乱顺序。所以G3、G4、G7被转移到全局队列

5)、场景5

G2创建G8时,P1的本地队列未满,所以G8会被加入到P1的本地队列

深入理解GMP模型_第8张图片

G8加入到P1的本地队列的原因还是因为P1此时在与M1绑定,而G2此时是M1在执行。所以G2创建的新的G会优先放置到自己的M绑定的P上

6)、场景6

规定:在创建G时,运行的G会尝试唤醒其他空闲的P和M组合去执行

深入理解GMP模型_第9张图片

假定G2唤醒了M2,M2绑定了P2,并运行G0,但P2本地队列没有G,M2此时为自选线程(没有G但为运行状态的线程,不断寻找G

7)、场景7

M2尝试从全局队列取一批G放到P2的本地队列(函数:findrunnable())。M2从全局队列取的G数量符合公式:n = min(len(GQ) / GOMAXPROCS + 1, cap(LQ) / 2 )

相关源码参考:

// 从全局队列中偷取,调用时必须锁住调度器
func globrunqget(_p_ *p, max int32) *g {
	// 如果全局队列中没有g直接返回
	if sched.runqsize == 0 {
		return nil
	}

	// per-P的部分,如果只有一个P的全部取
	n := sched.runqsize/gomaxprocs + 1
	if n > sched.runqsize {
		n = sched.runqsize
	}

	// 不能超过取的最大个数
	if max > 0 && n > max {
		n = max
	}

	// 计算能不能在本地队列中放下n个
	if n > int32(len(_p_.runq))/2 {
		n = int32(len(_p_.runq)) / 2
	}

	// 修改本地队列的剩余空间
	sched.runqsize -= n
	// 拿到全局队列队头g
	gp := sched.runq.pop()
	// 计数
	n--

	// 继续取剩下的n-1个全局队列放入本地队列
	for ; n > 0; n-- {
		gp1 := sched.runq.pop()
		runqput(_p_, gp1, false)
	}
	return gp
}

至少从全局队列取一个G,但每次不要从全局队列移动太多的G到P的本地队列,给其他P留一点

深入理解GMP模型_第10张图片

假定场景中一共有4个P(GOMAXPROCS设置为4,那么允许最多就能用4个P来供M使用)。所以M2只能从全局队列取1个G(即G3)放到P2本地队列,然后完成从G0到G3的切换,运行G3

8)、场景8

假设G2一直在M1上运行,经过2轮后,M2已经把G7、G4从全局队列获取到了P2的本地队列并完成运行,全局队列和P2的本地队列都空了,如场景8图的左半部分

深入理解GMP模型_第11张图片

全局队列已经没有G,那M就要执行work stealing(偷取):从其他有G的P那里偷取一半G过来,放到自己的P本地队列。P2从P1的本地队列尾部取一半的G,本例中一半则只有一个G8,放到P2的本地队列并执行

9)、场景9

G1本地队列G5、G6已经被其他M偷走并运行完成,当前M1和M2分别运行G2和G8,M3和M4没有gourtine可以运行,M3和M4处于自旋状态,它们不断寻找gourtine

深入理解GMP模型_第12张图片

为什么要让M3和M4自旋,自旋本质是在运行,线程在运行却没有执行G,就变成了浪费CPU。为什么不销毁现场,来解决CPU资源。因为创建和销毁CPU也会浪费时间,希望当有新gourtine创建时,立刻能有M运行它,如果销毁再新建就增加了时延,降低了效率。当然也考虑了过多的自旋线程是浪费CPU,所以系统中最多有GOMAXPROCS个自旋的线程(当前例子中的GOMAXPROCS=4,所以一共4个P),多余的没事做线程会让它们休眠

10)、场景10

假定当前除了M3和M4为自旋线程,还有M5和M6为空闲线程(没有得到P的绑定,注意这里最多就只能存在4个P,所以P的数量应该永远是M>=P,大部分都是M在抢占需要运行的P),G8创建了G9,G8进行了阻塞的系统调用,M2和P2立即解绑,P2会执行以下判断:如果P2本地队列有G、全局队列有G或有空闲的M,P2都会立马唤醒1个M和它绑定,否则P2则会加入到空闲P队列,等待M来获取可用的P。本场景中,P2本地队列有G9,可以和其他空闲的线程M5绑定

深入理解GMP模型_第13张图片
11)、场景11

G8创建了G9,假如G8进行了非阻塞系统调用

深入理解GMP模型_第14张图片

M2和P2会解绑,但M2会记住P2,然后G8和M2进入系统调用状态。当G8和M2退出系统调用时,会尝试获取P2,如果无法获取,则获取空闲的P,如果依然没有,G8会被记为可运行状态,并加入到全局队列,M2因为没有P的绑定而变成休眠状态(长时间休眠等待GC回收销毁)

参考:

Golang的协程调度器原理及GMP设计思想

你可能感兴趣的:(#,Go,golang,GMP模型)