golang中G、P、M 和 sched 三者的数据结构

G、P、M 三者是golang实现高并发能的最为重要的概念,runtime 通过 调度器 来实现三者的相互调度执行,通过 p 将用户态的 g 与内核态资源 m 的动态绑定来执行,以减少以前通过频繁创建内核态线程而产生的一系列的性能问题,充分发挥服务器最大有限资源。

GPM 协作

调度器的工作是将一个 G(需要执行的代码)、一个 M(代码执行的地方)和一个 P(代码执行所需要的权限和资源)结合起来。

所有的 g、m 和 p 对象都是分配在上且永不释放的,所以它们的内存使用是很稳定的。得益于此,runtime 可以在调度器实现中避免写屏障。当一个G执行完成后,可以放入pool中被再次使用,避免重复申请资源。

本节主要通过阅读runtime源码来认识这三个组件到底长的是什么样子,以此加深对 GPM 的理解。go version go1.15.6

理解下文前建议先阅读一下 src/runtime/HACKING.md 文件,中文可阅读这里,这个文件内容是面向开发者理解runtime的很值得看一看。

本文若没有指定源码文件路径,则默认为 src/runtime/runtime2.go

G

G是英文字母goroutine的缩写,一般称为“协程”,其实这个词还是无法完整表达它的意思的,但这用的人的多了就成了统称。注意它与线程和进程的区别,这个应该很容易理解,每个gopher应该都知道。

每个 Goroutine 对应一个 g 结构体,它有自己的栈内存, G 存储 Goroutine 的运行堆栈、状态以及任务函数,可重复用,

Goroutine数据结构位于 src/runtime/runtime2.go 文件,注意此文件里有太多重要的底层数据结构,对于我们理解底层runtime非常的重要,建议大量多看看。不需要记住每一个数据结构,但需要的时候要能第一时间想到在哪里查找。

当一个 goroutine 退出时,g 对象会被放到一个空闲的 g 对象池中以用于后续的 goroutine 的使用, 以减少内存分配开销。

Goroutine 字段非常的多,我们这里分段来理解

type g struct {
	// Stack parameters.
	// stack describes the actual stack memory: [stack.lo, stack.hi).
	// stackguard0 is the stack pointer compared in the Go stack growth prologue.
	// It is stack.lo+StackGuard normally, but can be StackPreempt to trigger a preemption.
	// stackguard1 is the stack pointer compared in the C stack growth prologue.
	// It is stack.lo+StackGuard on g0 and gsignal stacks.
	// It is ~0 on other goroutine stacks, to trigger a call to morestackc (and crash).
	stack       stack   // offset known to runtime/cgo

	// 检查栈空间是否足够的值, 低于这个值会扩张栈, 0是go代码使用的
	stackguard0 uintptr // offset known to liblink

	// 检查栈空间是否足够的值, 低于这个值会扩张栈, 1是原生代码使用的
	stackguard1 uintptr // offset known to liblink
}

stack 描述了当前 Goroutine 的栈内存范围[stack.lo, stack.hi),其中stack 的数据结构为

// Stack describes a Go execution stack.
// The bounds of the stack are exactly [lo, hi),
// with no implicit data structures on either side.
// 描述go执行栈
// 栈边界为[lo, hi),左包含可不包含,即 lo≤stack<hi
// 两边都没有隐含的数据结构。
type stack struct {
	lo uintptr // 该协程拥有的栈低位
	hi uintptr // 该协程拥有的栈高位
}

stackguard0 stackguard1 均是一个栈指针,用于扩容场景,前者用于 Go stack ,后者用于C stack。

如果 stackguard0 字段被设置成 StackPreempt 意味着当前 Goroutine 发出了抢占请求。

g结构体中的stackguard0 字段是出现爆栈前的警戒线。stackguard0的偏移量是16个字节,与当前的真实SP(stack pointer)和爆栈警戒线(stack.lo+StackGuard)比较,如果超出警戒线则表示需要进行栈扩容.先调用runtime·morestack_noctxt()进行栈扩容,然后又跳回到函数的开始位置,此时此刻函数的栈已经调整了。然后再进行一次栈大小的检测,如果依然不足则继续扩容,直到栈足够大为止。对于StackGuard 的介绍可以参考这里

关于对 Stack 的理解可参考这篇文章

type g struct {
	preempt       bool // preemption signal, duplicates stackguard0 = stackpreempt
	preemptStop   bool // transition to _Gpreempted on preemption; otherwise, just deschedule
	preemptShrink bool // shrink stack at synchronous safe point
}

preempt 抢占标记,其值为true 执行 stackguard0 = stackpreempt
preemptStop 将抢占标记修改为 _Gpreedmpted,如果修改失败则取消
preemptShrink 在同步安全点收缩栈

type g struct {
	_panic       *_panic // innermost panic - offset known to liblink
	_defer       *_defer // innermost defer
}

_panic 当前Goroutine 中的panic
_defer 当前Goroutine 中的defer

type g struct {
	m            *m      // current m; offset known to arm liblink
	sched        gobuf
	goid         int64
}

m 当前 Goroutine 绑定的M
sched 存储当前 Goroutine 调度相关的数据,上下方切换时会把当前信息保存到这里,用的时候再取出来,它的用途可参考函数 newproc1()
goid 当前 Goroutine 的唯一标识,对开发者不可见,一般不使用此字段。可参考相关文章了解为什么Go开发团队为什么不向外开放访问此字段。

gobuf 结构体

type gobuf struct {
	// The offsets of sp, pc, and g are known to (hard-coded in) libmach.
	// 寄存器 sp,pc和g的偏移量,硬编码在libmach
	//
	// ctxt is unusual with respect to GC: it may be a
	// heap-allocated funcval, so GC needs to track it, but it
	// needs to be set and cleared from assembly, where it's
	// difficult to have write barriers. However, ctxt is really a
	// saved, live register, and we only ever exchange it between
	// the real register and the gobuf. Hence, we treat it as a
	// root during stack scanning, which means assembly that saves
	// and restores it doesn't need write barriers. It's still
	// typed as a pointer so that any other writes from Go get
	// write barriers.
	sp   uintptr
	pc   uintptr
	g    guintptr
	ctxt unsafe.Pointer
	ret  sys.Uintreg
	lr   uintptr
	bp   uintptr // for GOEXPERIMENT=framepointer
}

sp 栈指针位置
pc 程序计数器,运行到的程序位置
gobuf 主要存储一些寄存器信息,如sppcg 的偏移量,硬编码在libmach
ctxt 不常见,可能是一个分配在heap的函数变量,因此GC 需要追踪它,不过它有可能需要设置并进行清除,在有写屏障 的时候有些困难。重点了解一下 write barriers
g 技能当前 gobuf 的 Goroutine
ret 系统调用的结果
bp 未知

调度器在将 G 由一种状态变更为另一种状态时,需要将上下文信息保存到这个gobuf结构体,当再次运行 G 的时候,再从这个结构体中读取出来,主要用来暂时上下文信息。其中的栈指针和程序计数器会用来存储或者恢复寄存器中的值,改变程序即将执行的代码。

Goroutine 的状态有以下几种(源码

状态描述
_Gidle0 刚刚被分配并且还没有被初始化
_Grunnable1 没有执行代码,没有栈的所有权,存储在运行队列中
_Grunning2 可以执行代码,拥有栈的所有权,被赋予了内核线程 M 和处理器 P
_Gsyscall3 正在执行系统调用,没有执行用户代码,拥有栈的所有权,被赋予了内核线程 M 但是不在运行队列上
_Gwaiting4 由于运行时而被阻塞,没有执行用户代码并且不在运行队列上,但是可能存在于 Channel 的等待队列上。若需要时执行ready()唤醒。
_Gmoribund_unused5 当前此状态未使用,但硬编码在了gdb 脚本里,可以不用关注
_Gdead6 没有被使用,可能刚刚退出,或在一个freelist;也或者刚刚被初始化;没有执行代码,可能有分配的栈也可能没有;G和分配的栈(如果已分配过栈)归刚刚退出G的M所有或从free list 中获取
_Genqueue_unused7 目前未使用,不用理会
_Gcopystack8 栈正在被拷贝,没有执行代码,不在运行队列上
_Gpreempted9 由于抢占而被阻塞,没有执行用户代码并且不在运行队列上,等待唤醒
_Gscan10 GC 正在扫描栈空间,没有执行代码,可以与其他状态同时存在
Goroutine 的状态

需要注意的是对于 _Gmoribund_unused 状态并未使用,但在 gdb 脚本中存在;而对于 _Genqueue_unused 状态目前也未使用,不需要关心。

_Gscan 与上面除了_Grunning 状态以外的其它状态相组合,表示 GC 正在扫描栈。Goroutine 不会执行用户代码,且栈由设置了 _Gscan 位的 Goroutine 所有。

状态描述
_Gscanrunnable= _Gscan + _Grunnable // 0x1001
_Gscanrunning= _Gscan + _Grunning // 0x1002
_Gscansyscall= _Gscan + _Gsyscall // 0x1003
_Gscanwaiting= _Gscan + _Gwaiting // 0x1004
_Gscanpreempted= _Gscan + _Gpreempted // 0x1009
Goroutine 的状态

可以看到除了上面提到的两个未使用的状态外一共有14种状态值。许多状态之间是可以进行改变的。如下图所示

goroutine status (https://github.com/golang-design/Go-Questions)

G的状态机流转图
type g strcut {
	syscallsp    uintptr        // if status==Gsyscall, syscallsp = sched.sp to use during gc
	syscallpc    uintptr        // if status==Gsyscall, syscallpc = sched.pc to use during gc
	stktopsp     uintptr        // expected sp at top of stack, to check in traceback
	param        unsafe.Pointer // passed parameter on wakeup
	atomicstatus uint32
	stackLock    uint32 // sigprof/scang lock; TODO: fold in to atomicstatus
}

atomicstatus 当前G的状态,上面介绍过G的几种状态值
syscallsp 如果G 的状态为 Gsyscall ,那么值为 sched.sp 主要用于GC 期间
syscallpc 如果G的状态为 GSyscall ,那么值为 sched.pc 同上也是用于GC 期间,由此可见这两个字段是一起使用的
stktopsp 用于回源跟踪,如何理解?
param 唤醒G时传入的参数,如调用 ready()
stackLock 栈锁,什么场景下会使用?

type g struct {
	waitsince    int64      // approx time when the g become blocked
	waitreason   waitReason // if status==Gwaiting
}

waitsince G 阻塞时长
waitreason 阻塞原因

type g struct {
	// asyncSafePoint is set if g is stopped at an asynchronous
	// safe point. This means there are frames on the stack
	// without precise pointer information.
	asyncSafePoint bool

	paniconfault bool // panic (instead of crash) on unexpected fault address
	gcscandone   bool // g has scanned stack; protected by _Gscan bit in status
	throwsplit   bool // must not split stack
}

asyncSafePoint 异步安全点;如果 g 在异步安全点停止则设置为true,表示在栈上没有精确的指针信息
paniconfault 地址异常引起的panic(代替了崩溃)
gcscandone g 扫描完了栈,受状态 _Gscan 位保护
throwsplit 不允许拆分stack 什么意思?

type g struct {
	// activeStackChans indicates that there are unlocked channels
	// pointing into this goroutine's stack. If true, stack
	// copying needs to acquire channel locks to protect these
	// areas of the stack.
	activeStackChans bool
	// parkingOnChan indicates that the goroutine is about to
	// park on a chansend or chanrecv. Used to signal an unsafe point
	// for stack shrinking. It's a boolean value, but is updated atomically.
	parkingOnChan uint8
}

activeStackChans 表示是否有未加锁定的channel指向到了g 栈,如果为true,那么对栈的复制需要channal锁来保护这些区域
parkingOnChan 表示g 是放在chansend 还是 chanrecv。用于栈的收缩,是一个布尔值,但是原子性更新

type g struct {
	raceignore     int8     // ignore race detection events
	sysblocktraced bool     // StartTrace has emitted EvGoInSyscall about this goroutine
	sysexitticks   int64    // cputicks when syscall has returned (for tracing)
	traceseq       uint64   // trace event sequencer
	tracelastp     puintptr // last P emitted an event for this goroutine
	lockedm        muintptr
	sig            uint32
	writebuf       []byte
	sigcode0       uintptr
	sigcode1       uintptr
	sigpc          uintptr
	gopc           uintptr         // pc of go statement that created this goroutine
	ancestors      *[]ancestorInfo // ancestor information goroutine(s) that created this goroutine (only used if debug.tracebackancestors)
	startpc        uintptr         // pc of goroutine function
	racectx        uintptr
	waiting        *sudog         // sudog structures this g is waiting on (that have a valid elem ptr); in lock order
	cgoCtxt        []uintptr      // cgo traceback context
	labels         unsafe.Pointer // profiler labels
	timer          *timer         // cached timer for time.Sleep
	selectDone     uint32         // are we participating in a select and did someone win the race?
}

gopc 创建当前G的pc
startpc go func 的pc
waiting 如何理解?
timer 通过time.Sleep 缓存 timer

从字段命名来看,许多字段都与trace 有关,不清楚什么意思

type g struct {
	// Per-G GC state

	// gcAssistBytes is this G's GC assist credit in terms of
	// bytes allocated. If this is positive, then the G has credit
	// to allocate gcAssistBytes bytes without assisting. If this
	// is negative, then the G must correct this by performing
	// scan work. We track this in bytes to make it fast to update
	// and check for debt in the malloc hot path. The assist ratio
	// determines how this corresponds to scan work debt.
	gcAssistBytes int64
}

gcAssistBytes 与GC相关。

为了保证用户程序分配内存的速度不会超出后台任务的标记速度,运行时还引入了标记辅助技术,它遵循一条非常简单并且朴实的原则,分配多少内存就需要完成多少标记任务。每一个 Goroutine 都持有 gcAssistBytes 字段,这个字段存储了当前 Goroutine 辅助标记的对象字节数。在并发标记阶段期间,当 Goroutine 调用 runtime.mallocgc 分配新对象时,该函数会检查申请内存的 Goroutine 是否处于入不敷出的状态。

总结

  • 每个G 都有自己的状态,状态保存在 atomicstatus 字段,共有十几种状态值。
  • 每个 G 在状态发生变化时,即 atomicstatus 字段值被改变时,都需要保存当前G的上下文的信息,这个信息存储在 sched 字段,其数据类型为gobuf,想理解存储的信息可以看一下这个结构体的各个字段
  • 每个G 都有三个与抢占有关的字段,分别为 preemptpreemptStoppremptShrink
  • 每个 G 都有自己的唯一id, 字段为goid,但此字段官方不推荐开发使用
  • 每个 G 都可以最多绑定一个m,如果可能未绑定,则值为 nil
  • 每个 G 都有自己内部的 deferpanic
  • G 可以被阻塞,并存储有阻塞原因,字段 waitsincewaitreason
  • G 可以被进行 GC 扫描,相关字段为 gcscandoneatomicstatus_Gscan 与上面除了_Grunning 状态以外的其它状态组合)

P

P表示逻辑处理器,对 G 来说,P 相当于 CPU 核,G 只有绑定到 P 才能被调度。对 M 来说,P 提供了相关的执行环境(Context),如内存分配状态(mcache),任务队列(G)等。在runtime中使用 p 结构表示。

P 的数量决定了系统内最大可并行的 G 的数量(前提:物理 CPU 核数  >= P 的数量)。

P 的数量由用户设置的 GoMAXPROCS 决定,但是不论 GoMAXPROCS 设置为多大,P 的数量最大为 256。

P的数据结构也有几十个字段,我们还是分开来理解

type p struct {
	id          int32
	status      uint32 // one of pidle/prunning/...
	link        puintptr
	schedtick   uint32     // incremented on every scheduler call
	syscalltick uint32     // incremented on every system call
	sysmontick  sysmontick // last tick observed by sysmon
}

id: P的唯一标识
status P当前状态,状态值有_Pidle、_Prunning、_Psyscall、_Pgcstop 和 _Pdead
link 未知
schedtick 每次程序被调用时递增
syscalltick 每次系统调用时时递增
sysmontick sysmon 最后tick的时间,是一个 sysmontick 数据类型。sysmon介绍:https://www.jianshu.com/p/469d0c7a7936

对于P的状态有五种:

状态描述
_Pidle处理器没有运行用户代码或者调度器,被空闲队列或者改变其状态的结构持有,运行队列为空;也有可能是几种状态正在过度中状态
_Prunning被线程 M 持有,并且正在执行用户代码或者调度器。只能由拥有当前P的M才可能修改此状态。M可以将P的状态修改为_Pidle(无工作可做)、_Psyscall(系统调用) 或 _Pgstop(GC); 另外M也可以P的使用权交给另一个M(调度一个锁定状态的G)
_Psyscall当前P没有执行用户代码,当前线程陷入系统调用
_Pgcstop被线程 M 持有,当前处理器由于垃圾回收被停止,由_Prunning变为_Pgcstop
_Pdead当前处理器已经不被使用,如通过动态调小 GOMAXPROCS进行P收缩
P 的状态
type p struct {
	m           muintptr   // back-link to associated m (nil if idle)
	mcache      *mcache
	pcache      pageCache
	raceprocctx uintptr
}

m 当前正在绑定的m, 有可能为空,如_Pidle
mcache 每个p的小对象缓存,无锁,对应 mcache 结构体
pcache 页面缓存,对应 pageCache 结构体,不需要锁
raceprocctx race相关

其中 mcachepcache 全是缓存相关字段,两个都是无锁结构体。

mcache是为了当G与P关联后,执行go code时,会为一些小对象(<32K)分配内存,这时直接从P.mcache 申请,避免直接从os申请,这样就允许多个P并发执行,减少申请内存的锁粒度,参考这里

type p struct {
	deferpool    [5][]*_defer // pool of available defer structs of different sizes (see panic.go)
	deferpoolbuf [5][32]*_defer
}

deferpool 不同大小的defer,二维数组。具体见 panic.go 文件,有对此字段的一些处理逻辑
deferpoolbuf 同上

这两个字段是与 defer 相关

type p struct {
	// Cache of goroutine ids, amortizes accesses to runtime·sched.goidgen.
	goidcache    uint64
	goidcacheend uint64
}

goidcache goid 缓存
goidcacheend goid 缓存

两个都是 goroutine ids 的缓存。

type p struct {
	// Queue of runnable goroutines. Accessed without lock.
	runqhead uint32
	runqtail uint32
	runq     [256]guintptr

	// runnext, if non-nil, is a runnable G that was ready'd by
	// the current G and should be run next instead of what's in
	// runq if there's time remaining in the running G's time
	// slice. It will inherit the time left in the current time
	// slice. If a set of goroutines is locked in a
	// communicate-and-wait pattern, this schedules that set as a
	// unit and eliminates the (potentially large) scheduling
	// latency that otherwise arises from adding the ready'd
	// goroutines to the end of the run queue.
	runnext guintptr
}

runqhead 运行队列头
runqtail 运行队列尾
runq 运行队列, 数组类型,最大值为256

每个P都有一个自己的runq,除了自身有的runq 还有一个全局的runq, 对于每个了解过GPM的gohper应该都知道这一点。每个P下面runq的允许的最大goroutine 数量为256。

runnext 当前P(进入运行状态时)立即要运行的goroutine,可能为nil。如果此字段不为nil 的话,则表示下次待运行的状态为 runnable 的 goroutine,此时则不从 runq 中获取G,优先级高于runq。如果当前G 还有剩余的可用时间,那么就运行这个 runnext 的G 继承剩下的时间。此字段的调用请参考函数 runtime.runqget()

这个字段是用来实现调度器亲和性的,我们知道原来一个G阻塞时,这时P会再获取一个G进行绑定执行,如果这时原来的G执行阻塞结束时,如果想再次执行,就需要重新在P的runq进行排队,如果当前runq里有太多的工作会造成占用线程的话会导致这个解除阻塞的G迟迟无法执行,同时还有可能被其他处理器所窃取。从 Go 1.5 开始得益于 P 的特殊属性,从阻塞 channel 返回的 Goroutine 会优先运行,这里只需要将这个G放在 runnext 这个字段即可。参考文章理解 Go 并发以及调度器亲和性

If a set of goroutines is locked in a communicate-and-wait pattern, this schedules that set as a
// unit and eliminates the (potentially large) scheduling
// latency that otherwise arises from adding the ready’d goroutines to the end of the run queue.

上面介绍了每个 P 的runq最大可以有256个goroutine, 再加上这个字段的话,一个P最大的情况下可以有257个goroutine了。

type p struct {
	// Available G's (status == Gdead)
	gFree struct {
		gList
		n int32
	}
}

gFree 空闲的g, gFree.n 表示空闲G的个数,字段主要存储空闲G,方便实现对G的复用(只有当状态为 Gdead 时才有效)。关注一下 匿名结构体内的 gList 字段, 这个字段在上篇文章里也介绍过它的使用场景。

type p struct {
	sudogcache []*sudog
	sudogbuf   [128]*sudog
}

sudogcache 缓存相关,slice 类型,*sudog 数据结构
sudogbuf 数组类型,*sudog 缓冲区

与*sudog 相关,可以看出与goroutine相关。不清楚这两个字段与上面的 runq 作用是什么。

type p strcut {
	// Cache of mspan objects from the heap.
	mspancache struct {
		// We need an explicit length here because this field is used
		// in allocation codepaths where write barriers are not allowed,
		// and eliminating the write barrier/keeping it eliminated from
		// slice updates is tricky, moreso than just managing the length
		// ourselves.
		len int
		buf [128]*mspan
	}
}

mspancache 从堆中缓存mspan对象。mspan是什么?

type p struct {
	tracebuf traceBufPtr

	// traceSweep indicates the sweep events should be traced.
	// This is used to defer the sweep start event until a span
	// has actually been swept.
	traceSweep bool
	// traceSwept and traceReclaimed track the number of bytes
	// swept and reclaimed by sweeping in the current sweep loop.
	traceSwept, traceReclaimed uintptr
}

与trace相关

type p struct {
	palloc persistentAlloc // per-P to avoid mutex

	_ uint32 // Alignment for atomic fields below

	// The when field of the first entry on the timer heap.
	// This is updated using atomic functions.
	// This is 0 if the timer heap is empty.
	timer0When uint64
}

palloc ???
_ 为了下面字段原子操作而进行的内存对齐填充
timer0When 此字段由原子操作函数执行,如果 timer heap 为空,则值为 0。它表示P的 timer 定时器小堆第一个对象的when字段值,即最先执行的时间值

type p struct {
	// Per-P GC state
	gcAssistTime         int64    // Nanoseconds in assistAlloc
	gcFractionalMarkTime int64    // Nanoseconds in fractional mark worker (atomic)
	gcBgMarkWorker       guintptr // (atomic)
	gcMarkWorkerMode     gcMarkWorkerMode

	// gcMarkWorkerStartTime is the nanotime() at which this mark
	// worker started.
	gcMarkWorkerStartTime int64

	// gcw is this P's GC work buffer cache. The work buffer is
	// filled by write barriers, drained by mutator assists, and
	// disposed on certain GC state transitions.
	gcw gcWork

	// wbBuf is this P's GC write barrier buffer.
	//
	// TODO: Consider caching this in the running G.
	wbBuf wbBuf

	runSafePointFn uint32 // if 1, run sched.safePointFn at next safe point
}

P 的 GC 状态

gcMarkWrokderStartTime gc的开始时间
gcw GC work的 buffer, 写屏障填充,结构体 gcWork
wbBuf P的GC写屏障buffer
runSafePointFn 如果为1,则在下一个安全点运行 sched.safePointFn

各种状态的切换图

p status (https://github.com/golang-design/Go-Questions)
type p strcut {
	// Lock for timers. We normally access the timers while running
	// on this P, but the scheduler can also do it from a different P.
	timersLock mutex

	// Actions to take at some time. This is used to implement the
	// standard library's time package.
	// Must hold timersLock to access.
	timers []*timer

	// Number of timers in P's heap.
	// Modified using atomic instructions.
	numTimers uint32

	// Number of timerModifiedEarlier timers on P's heap.
	// This should only be modified while holding timersLock,
	// or while the timer status is in a transient state
	// such as timerModifying.
	adjustTimers uint32

	// Number of timerDeleted timers in P's heap.
	// Modified using atomic instructions.
	deletedTimers uint32

	// Race context used while executing timer functions.
	timerRaceCtx uintptr
}

timerLock timer锁
timers timer指针切片类型,timer 是标准库结构
numTimers P堆中的timer数,原子指令修改
adjustTimers p堆中 timerModifiedEarlier timer 的数量,修改时必须持有timerLock锁, 或者当定时器状态处于瞬态时,例如定时器调整。
deletedTimers 当前中p 堆中的 deletedTimers 计数器数量,原子指令修改
timerRaceCtx 执行计时器函数时使用的竞争上下文

上方 timer0WhentimerModifiedEarliesttimersLocktimersnumTimersadjustTimersdeletedTimerstimerDeletedtimerModifiedEarlier,与其它几个相关的 timer 字段均与定时器有关。

type p struct {
	// preempt is set to indicate that this P should be enter the
	// scheduler ASAP (regardless of what G is running on it).
	preempt bool

	pad cpu.CacheLinePad
}

preempt 抢占标记,如果值为true,表示 p 进入调度(不管G在运行什么)
pad cache line 对齐优化。不了解的阅读 CPU缓存体系对Go程序的影响

总结

  • 每个P都有自己的状态,分别为 _Pidle_Prunning_Psyscall_Pgcstop_Pdead
  • 每个P都存储有自己被调度次数系统调用的次数,字段 schedticksyscalltick
  • P 可以指定一个M, 但也有不指定,这时m值为nil,字段m
  • 每个P 都有一个自己的runq,用来存放可以 runnable 状态的 goroutines, 最多可以存放256个 goroutine。一般在介绍GMP关系时,我们称之为 local queue,当然还有一个global queue
  • 每个P都可能有一个 runnext 的 goroutine。如果此字段不为nil,则P下次执行G的时候,优先执行此字段的goroutine(如果P的状态从_Pidle变为_Prunning时此字段的值是变化吗?)
  • P可以缓存goroutine,字段 goidcache
  • P的GC状态
  • P可以有多个timer, 以slice 形式存储, 字段 timers
  • P可以缓存堆上面的mspan对象,mspan对象是什么?
  • P 有一个抢占标记,字段为 preempt。如果为ture ,则表示P立即进入调度
  • P结构体使用了pad, 以优化cpu, 解决cpu伪共享的问题

M

M 是指OS 内核线程,代表着真正执行计算的资源,在绑定有效的 P 后,进入 schedule 循环;而 schedule 循环的机制大致是从 Global 队列、P 的 Local 队列以及 wait 队列中获取。

M 在runtime中对应的是 m 结构体。

M 的数量是不定的,由 Go Runtime 调整,为了防止创建过多 OS 线程导致系统调度不过来,目前默认最大限制为 10000 个。如果一个M工作完成后,找不到可用的P,则需要将自己休眠,并放在空闲线程中,等待下次使用。

切记:M 并不保留 G 状态,这是 G 可以跨 M 调度的基础。

下面对 m 的结构体做下介绍

type m struct {
	g0      *g     // goroutine with scheduling stack
	morebuf gobuf  // gobuf arg to morestack
	divmod  uint32 // div/mod denominator for arm - known to liblink
}

g0 这是一个很特殊的goroutine, 它是一个具有调度堆栈的能力, 参考这里这里这里
morebuf 堆栈扩容使用(见这里),gobuf 数据类型,gobuf这个数据结构在g结构体中已出现过,它的作用就是保存一个g 的上下文数据。这里作为传递给 morestack 的参数
divmod 未知?

type m struct {
	// Fields not known to debuggers.
	procid        uint64       // for debuggers, but offset not hard-coded
	gsignal       *g           // signal-handling g
	goSigStack    gsignalStack // Go-allocated signal handling stack
	sigmask       sigset       // storage for saved signal mask
	tls           [6]uintptr   // thread-local storage (for x86 extern register)
	mstartfn      func()
	curg          *g       // current running goroutine
	caughtsig     guintptr // goroutine running during fatal signal
	p             puintptr // attached p for executing go code (nil if not executing go code)
	nextp         puintptr
	oldp          puintptr // the p that was attached before executing a syscall
	id            int64
}

procid 调度器使用,非硬编码的偏移量(不清楚具体用途)
gsignal 信息处理的g (翻译的可能不准确)
goSigStack 分配的信号处理栈,数据类型为 gsignalStack
sigmask 存储的信号掩码,数据类型为 sigset
tls 数组类型,本地线程存储,最多为6个
mstartfn 表示m启动时立即执行的函数,对其的调用见 mstart1()
curg 当前正在运行的 goroutine
caughtsig 在致命信号期间运行的goroutine
p 用于执行go code 的 p,就是当前正在m绑定的P,如果没有运行code 的话,值为nil
nextp 下次运行时的P
oldp 在执行系统调用之前绑定的P
id m的唯一id

其中与goroutine有关的字段有caughtsigcurg,其中 curg 这个就是当前m绑定的goroutine;

与p相关的字段的pnextpoldp,分别表示当前绑定的P、下次绑定的P和上次绑定的P,nextp 和oldp 具体有什么用呢?

type m struct {
	mallocing     int32
	throwing      int32
	preemptoff    string // if != "", keep curg running on this m
	locks         int32
	dying         int32
	profilehz     int32
}

throwing 当前m抛出异常,即调用了内部函数 throw
preemptoff 如果非空,则保持curg 运行在当前m。

其它几个字段未知

type m struct {
	spinning      bool // m is out of work and is actively looking for work
	blocked       bool // m is blocked on a note
	newSigstack   bool // minit on C thread called sigaltstack
	printlock     int8
	incgo         bool   // m is executing a cgo call
	freeWait      uint32 // if == 0, safe to free g0 and delete m (atomic)
	fastrand      [2]uint32
	needextram    bool
	traceback     uint8
}

spinning 表示当前m空闲,需要找一个新的工作来执行
blockednote 阻塞
newSigstack 在一个C 线程被调用 sigaltstack
printlock
incgo 当前m正在执行一个cgo调用
freeWait 如果值为0,则需要安全的释放go并删除m(原子操作)
fastrand
needextram ?
traceback trace 相关

对于 spinning 这个情况经常见,当前m没有活干了,需要努力找一个新活干,属于GMP调度中的一个关系点。

note 的数据结构为

// sleep and wakeup on one-time events.
// before any calls to notesleep or notewakeup,
// must call noteclear to initialize the Note.
// then, exactly one thread can call notesleep
// and exactly one thread can call notewakeup (once).
// once notewakeup has been called, the notesleep
// will return.  future notesleep will return immediately.
// subsequent noteclear must be called only after
// previous notesleep has returned, e.g. it's disallowed
// to call noteclear straight after notewakeup.
// 一次性事件中的休眠和唤醒
// 对于任何调用 notesleep 或 notwakeup 之前,必须调用 noteclear 进行初始化操作。
// 那么,一个线程调用 notesleep, 一个线程调用 notewakup(只能一次)。
// 当 notewakeup 被调用后,notesleep 还未返回,需要过一段时间 notesleep 才能调用完成。在继续调用 noteclear 之前,必须等待当前一个 notesleep 返回后才可以,
// 不允许在 notewakeup 后直接调用 noteclear。
//
// notetsleep is like notesleep but wakes up after
// a given number of nanoseconds even if the event
// has not yet happened.  if a goroutine uses notetsleep to
// wake up early, it must wait to call noteclear until it
// can be sure that no other goroutine is calling
// notewakeup.
// notetsleep 类似 notesleep, 但唤醒后会返回一个纳秒数值(如果事件正好还不没有发生)
// 如果一个 goroutine 提前使用了 notetsleep 唤醒,它必须等待调用完 noteclear,直到确认没有其它goroutine调用 notewakeup
//
// notesleep/notetsleep are generally called on g0,
// notetsleepg is similar to notetsleep but is called on user g.
// notesleep/notetsleep 通常在 g0 上调用, notetsleepg类似于notetsleep,但在用户g上调用(可能指的用户态的G)

type note struct {
	// Futex-based impl treats it as uint32 key,
	// while sema-based impl as M* waitm.
	// Used to be a union, but unions break precise GC.
	key uintptr
}

对于 note 这个类型,在调度时经常使用,就有三个与其相关的命令(notesleepnotewakupnoteclear, 注意这们的调用顺序要求),参考:https://www.purewhite.io/2019/11/28/runtime-hacking-translate/#%E5%90%8C%E6%AD%A5

type m struct {
	ncgocall      uint64      // number of cgo calls in total
	ncgo          int32       // number of cgo calls currently in progress
	cgoCallersUse uint32      // if non-zero, cgoCallers in use temporarily
	cgoCallers    *cgoCallers // cgo traceback if crashing in cgo call
}

ncgocall cgo的总调用次数
ncgo 目前正在执行的cgo调用数
cgoCallersUse 如果 > 0,临时使用cgoCallers
cgoCaller 如果在调用 cgo 时奔溃,则是进行回溯?

这四个字段主要与cgo相关。

type m struct {
	park          note
	alllink       *m // on allm
	schedlink     muintptr
	lockedg       guintptr
	createstack   [32]uintptr // stack that created this thread.
	lockedExt     uint32      // tracking for external LockOSThread
	lockedInt     uint32      // tracking for internal lockOSThread
	nextwaitm     muintptr    // next m waiting for lock
}

park 数据类型为 note , M休眠时使用的信号量, 唤醒M时会通过它唤醒
alllink ?
schedlink 调度相关,下一个m, 当m在链表结构中会使用
lockedg 锁定的goroutine, g.lockedm的对应值
createstatck 创建当前线程的栈
lockedExt 跟踪外部锁线程
lockedInt 跟踪内部锁线程
nextwaitm 下一个等待此锁的m

type m struct {
	waitunlockf   func(*g, unsafe.Pointer) bool
	waitlock      unsafe.Pointer
	waittraceev   byte
	waittraceskip int
	startingtrace bool
	syscalltick   uint32
	freelink      *m // on sched.freem
}

waitunlockf 等待解锁函数
waitlock 等待锁
waittraceev
waittraceskip
startingtrace
syscalltick
freelink m释放列表,链接到 sched.freem 字段

对于 waitlockfwaitlockwaittraceevwaittraceskip 是与调度相关有关的字段(见gppark()函数)。startingtrace 是与trace相关的三个字段。freelink 看注释是与调度有关的。

type m strcut {
	// these are here because they are too large to be on the stack
	// of low-level NOSPLIT functions.
	libcall   libcall
	libcallpc uintptr // for cpu profiler
	libcallsp uintptr
	libcallg  guintptr
	syscall   libcall // stores syscall parameters on windows

	vdsoSP uintptr // SP for traceback while in VDSO call (0 if not in call)
	vdsoPC uintptr // PC for traceback while in VDSO call
}

前五个字段可能与库调用相关,它们之所以出现在这里,是因为它们太大了,不可能出现在低级NOSPLIT函数的堆栈中。

vdsoSPvdsoPC 属于VDSO调用。vdsoSP 如果值为0,则表示没有调用。

type m struct {
	// preemptGen counts the number of completed preemption
	// signals. This is used to detect when a preemption is
	// requested, but fails. Accessed atomically.
	preemptGen uint32

	// Whether this is a pending preemption signal on this M.
	// Accessed atomically.
	signalPending uint32

	dlogPerM

	mOS

	// Up to 10 locks held by this m, maintained by the lock ranking code.
	locksHeldLen int
	locksHeld    [10]heldLockInfo
}

preemptGen完成的抢占信号数量。这用于检测何时请求抢占,但是失败了。原子访问
signalPending 是不是当前M上挂起的抢占信号
dlogPerM ?
mOS ?
locksHeldLen 当前持有锁的数量
locksHeld 最多可以持有1个锁,数据类型为 heldLockInfo,

preemptGensignalPending 是与抢占有关的字段;
locksHeldLenlocksHeld 是表示持有锁的信息,他们由ranking code 维护。

对于 heldLockInfo 数据结构

// heldLockInfo gives info on a held lock and the rank of that lock
// heldLockInfo 提供了一个锁的相关信息和锁的等级
type heldLockInfo struct {
	lockAddr uintptr
	rank     lockRank
}
// src/runtime/lockrank.go

type lockRank int

总结

  • 每个 m 都持有一个特殊的goroutine,我们称之为g0,它具有调度栈的能力。调度和执行系统调用时会先切换到这个g
  • m 可以与一个G相绑定,字段 curg
  • m 可以与P绑定,也可以不绑定,如果已绑定则字段p不非nil
  • m 可以记录下次和上次绑定的p,字段 nextpoldp
  • 如果m 没有工作可做的话,它会通过自旋积极再找一个活干
  • m会不会在 note 阻塞
  • 可以记录对m完成抢占信息的次数
  • 一个m最多可以持有10个锁

Sched

上面我们分别介绍了 G/P/M 三者的数据结构,想必对他们结构体中的每个字段的作用有了一点的了解了,然而三者的协作需要一个负责协调的角色,而这正是 go sched 的职责。

Go 调度器,它维护有存储 M 和 G 的队列以及调度器的一些状态信息等,全局调度时使用。

调度器循环的机制大致是从各种队列、P 的本地队列中获取 G,然后切换到 G 的执行栈上并执行 G 的函数,调用 Goexit 做清理工作并回到 M,如此反复。

对于三者调度逻辑可参考文章 Go netpoller 网络模型之源码全面解析

下面我们再看一下它的数据结构

type schedt struct {
	// accessed atomically. keep at top to ensure alignment on 32-bit systems.
	// 原子访问, 最顶部,保证32位系统下的对齐
	goidgen uint64

	// 上次网络轮询的时间,如果当前正在轮询,则为0
	lastpoll uint64 // time of last network poll, 0 if currently polling

	// 当前轮询休眠的时间
	pollUntil uint64 // time to which current poll is sleeping

	lock mutex

	// When increasing nmidle, nmidlelocked, nmsys, or nmfreed, be
	// sure to call checkdead().
	// 当增加 nmidle,nmidlelocked, nmsys或 nmfreed 的时候,一定要调用 checkdead()

	// 空闲m等待队列
	midle muintptr // idle m's waiting for work

	// 空闲m的数量
	nmidle int32 // number of idle m's waiting for work

	// 等待工作的锁定m的数量
	nmidlelocked int32 // number of locked m's waiting for work

	// 已创建的m数和下一个m ID, 一个字段代表两个意义?
	mnext int64 // number of m's that have been created and next M ID

	// 允许的最大m数
	maxmcount int32 // maximum number of m's allowed (or die)

	// 死锁不计算系统m的数量
	nmsys int32 // number of system m's not counted for deadlock

	// 累计已释放m的数量
	nmfreed int64 // cumulative number of freed m's

	// 系统goroutins的数量,原子更新
	ngsys uint32 // number of system goroutines; updated atomically

	// 空闲p
	pidle  puintptr // idle p's
	npidle uint32
	// 自旋, 查看proc.go 文件的 "Worker thread parking/unparking" 注释
	nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.

	// Global runnable queue.
	// 全局运行队列信息, gQueue 是一个通过 g.schedlink 链接的双向队列
	runq     gQueue
	// 队列大小
	runqsize int32

	// disable controls selective disabling of the scheduler.
	//
	// Use schedEnableUser to control this.
	//
	// disable is protected by sched.lock.
	disable struct {
		// user disables scheduling of user goroutines.
		user     bool
		runnable gQueue // pending runnable Gs
		n        int32  // length of runnable
	}

	// Global cache of dead G's.
	gFree struct {
		lock    mutex
		stack   gList // Gs with stacks
		noStack gList // Gs without stacks
		n       int32
	}

	// Central cache of sudog structs.
	sudoglock  mutex
	sudogcache *sudog

	// Central pool of available defer structs of different sizes.
	deferlock mutex
	deferpool [5]*_defer

	// freem is the list of m's waiting to be freed when their
	// m.exited is set. Linked through m.freelink.
	// freem 是当 他们的 m.exited 被设置时的等待被释放m列表,通过 m.freelink 链接
	freem *m

	// gc正在等待运行
	gcwaiting  uint32 // gc is waiting to run
	stopwait   int32
	stopnote   note
	sysmonwait uint32
	sysmonnote note

	// safepointFn should be called on each P at the next GC
	// safepoint if p.runSafePointFn is set.
	// 如果 p.runSafePointFn 设置的话, safeopintFn 将在每个p下次 GC safepoint 时被调用
	safePointFn   func(*p)
	safePointWait int32
	safePointNote note

	profilehz int32 // cpu profiling rate

	// 对gomaxprocs的最后更改时间
	procresizetime int64 // nanotime() of last change to gomaxprocs
	totaltime      int64 // ∫gomaxprocs dt up to procresizetime

	// sysmonlock protects sysmon's actions on the runtime.
	//
	// Acquire and hold this mutex to block sysmon from interacting
	// with the rest of the runtime.
	// 在运行时,sysmonlock保护 sysmon 的运行
	sysmonlock mutex
}

type schedt struct {
	// accessed atomically. keep at top to ensure alignment on 32-bit systems.
	// 原子访问, 最顶部位置,保证32位系统下的对齐
	goidgen uint64

	// 上次网络轮询的时间,如果当前正在轮询,则为0
	lastpoll uint64 // time of last network poll, 0 if currently polling

	// 当前轮询休眠的时间
	pollUntil uint64 // time to which current poll is sleeping

	lock mutex
}

goidgen 目前还不清楚它的作用
lastpoll 上次网络轮询的时间,如果值为0,表示当前正在轮询
pollUntil 当前由于轮询导致的休眠的时间
lock

type schedt struct {
	// When increasing nmidle, nmidlelocked, nmsys, or nmfreed, be
	// sure to call checkdead().
	// 当增加 nmidle,nmidlelocked, nmsys或 nmfreed 的时候,一定要调用 checkdead() 函数

	// 空闲m等待时间
	midle muintptr // idle m's waiting for work

	// 空闲m的数量
	nmidle int32 // number of idle m's waiting for work

	// 等待工作的锁定m的数量
	nmidlelocked int32 // number of locked m's waiting for work

	// 已创建的m数和下一个m ID, 一个字段代表两个意义?
	mnext int64 // number of m's that have been created and next M ID

	// 允许的最大m数
	maxmcount int32 // maximum number of m's allowed (or die)

	// 死锁不计算系统m的数量
	nmsys int32 // number of system m's not counted for deadlock

	// 累计已释放m的数量
	nmfreed int64 // cumulative number of freed m's

	// 系统goroutins的数量,原子更新
	ngsys uint32 // number of system goroutines; updated atomically
}

midle 等待工作的空闲m
nmidle 空闲m的数量
nmidlelocked 空间等待m中,加锁的数量
mnext 已创建的m数量和下一个m ID, 一个字段代表两个意义?(如果为9的话,则下个使用的m 就是9号m吗?)
maxmcount 允许使用的最大m数量(空闲m)
nmsys 由于死锁未被计算在内的m的数量
nmfreed 累计已释放m的数量
ngsys 系统groutines的数量,原子更新

调度器会记录当前哪个m在等待工作(midle),一共有多少个空闲m(nmidle),同时还记录等待工作的锁定m的数量(nmidlelocked), 已创建m的数量和允许的最大空间m数量(maxmcount)等信息

type schedt struct {
	// 空闲p
	pidle  puintptr // idle p's
	npidle uint32
	// 自旋, 查看proc.go 文件的 "Worker thread parking/unparking" 注释
	nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.

	// Global runnable queue.
	// 全局运行队列信息, gQueue 是一个通过 g.schedlink 链接的双向队列
	runq     gQueue
	// 队列大小
	runqsize int32
}

pidle 空间的P
npidle 空闲P的数量
nmspinning 正在自旋的m的数量,查看proc.go 文件的 “Worker thread parking/unparking” 注释
runq 全局G队列(还记得吧,P也有自己的G队列,最大值为256)
runqsize 全局队列大小

记录了当前空闲的P是哪一个(pidle),共有几少个空闲的P(npidle),还有多少个正在spinning 的M(nmspinning)。另外还有一个全局G的列队(runq)。是不是越来越有点意思了,有了空闲的M(midle)及其数量(nmidle),也有了空闲的P(pidle)及其数量(npidle),还知道有多少个M正在在spinning(nmspinning)拼命在找活干,除了每个P下面自己的runq队列,调度器自身也有存放G的队列runq,所需要的资源GPM都够了,剩下的就是看如何给他们近排活干了。

type schedt struct {
	// disable controls selective disabling of the scheduler.
	//
	// Use schedEnableUser to control this.
	//
	// disable is protected by sched.lock.
	disable struct {
		// user disables scheduling of user goroutines.
		user     bool
		runnable gQueue // pending runnable Gs
		n        int32  // length of runnable
	}

	// Global cache of dead G's.
	gFree struct {
		lock    mutex
		stack   gList // Gs with stacks
		noStack gList // Gs without stacks
		n       int32
	}
}

disable 禁用受保护调度锁 sched.lock,匿名结构体。
gFree 全局缓存G, 匿名结构体。如果一个G完毕后,并不立即释放它而是先放在一个列表里,以备后续复用,这样可以优先减少创建资源的开销。放入g后再检查一下当前 pp.gFree 长度是否>=64(_p_.gFree.n >= 64) , 如果大于则会将 p.gFree 一半的 g 迁移到 sched.gFree,源码见 gfput()

对于 disable 字段的值受 schedEnableUser 控制, 可以用来控制用户goroutines 的调度。

type schedt struct {
	// Central cache of sudog structs.
	sudoglock  mutex
	sudogcache *sudog

	// Central pool of available defer structs of different sizes.
	deferlock mutex
	deferpool [5]*_defer

	// freem is the list of m's waiting to be freed when their
	// m.exited is set. Linked through m.freelink.
	// freem 是当 他们的 m.exited 被设置时的等待被释放m列表,通过 m.freelink 链接
	freem *m
}

sudoglock sudog锁
sudogcache sudog结构的中央缓存
deferlock defer锁
deferpool 数组,最大值5,不同大小的defer pool 池
freemm.exited 设置的时候,freem就是等待被释放的列表,通过 m.freelink 链接

一个sudog缓存,另一个是defer pool,各自都有一个对应的锁。

type schedt strcut {
	// gc正在等待运行
	gcwaiting  uint32 // gc is waiting to run
	stopwait   int32
	stopnote   note
	sysmonwait uint32
	sysmonnote note
}

这几个都是与等待有关的字段,gcwaiting 与GC有关,xxxnote的与 note 有关。

type schedt strcut {
	// safepointFn should be called on each P at the next GC
	// safepoint if p.runSafePointFn is set.
	// 如果 p.runSafePointFn 设置的话, safeopintFn 将在每个p下次 GC safepoint 时被调用
	safePointFn   func(*p)
	safePointWait int32
	safePointNote note

	profilehz int32 // cpu profiling rate

	// 对gomaxprocs的最后更改时间
	procresizetime int64 // nanotime() of last change to gomaxprocs
	totaltime      int64 // ∫gomaxprocs dt up to procresizetime

	// sysmonlock protects sysmon's actions on the runtime.
	//
	// Acquire and hold this mutex to block sysmon from interacting
	// with the rest of the runtime.
	// 在运行时,sysmonlock保护 sysmon 的运行
	sysmonlock mutex
}

前三个是与安全点有关的字段,目前还不清楚SafePoint 指的是什么?
sysmonlock 是sysmon协程锁

sysmon 协程

总结

  • 调度器会记录当前是否处于轮训状态以及轮训的时间
  • 记录有M相关的信息,如当前空闲的M,如果有多个的话,也会记录个数,记录的还有已用过数量,当前有多少个正在spinning,最大允许的M数量。同时也会记录其中持有锁的数量
  • 记录有P相关的信息,如当前空闲P,空闲的数量。
  • 持有当前系统 groutine 数量
  • 有一个G的全局运行队列及其队列大小
  • 通过gFree 记录有多少个空闲的G,可以被重复利用
  • sudog缓存 和 deferpool
  • 都有一个全局锁(lock)和 sysmon (sysmonlock)锁及其它锁(sugoglock)
  • 可以控制是否禁用用户gorutine的调度行为,字段 disable(调用 schedEnableUser)

如果想学习Golang 的内存管理,则推荐先看这一篇 https://blog.haohtml.com/archives/29385

参考