声明
下面的分析均基于Golang1.14版本。
以下数据结构均做了裁剪，只留了部分调度密切相关的重要结构。
一、G的定义
裁剪了大部分字段，后面填坑把其它字段的作用及用途整理。
type g struct {
stack stack // offset known to runtime/cgo G的栈信息含栈的起始和终止地址
m *m // current m; offset known to arm liblink 运行时绑定的M
sched gobuf // 运行时的上下文
goid int64 // g id 唯一的标识id
}
type stack struct {
lo uintptr
hi uintptr
}
type gobuf struct {
sp uintptr // 当前的栈顶地址
pc uintptr // 当前的PC值
g guintptr
ctxt unsafe.Pointer
ret sys.Uintreg
lr uintptr
bp uintptr // for GOEXPERIMENT=framepointer
}
二、M的定义
同样裁剪了大量字段，后面把坑填上。
type m struct {
g0 *g // goroutine with scheduling stack 每个m都会绑定一个g0 g0的栈不可扩容 g0的栈和线程的栈重合 运行调度其他g的代码时使用的g0的栈
gsignal *g // signal-handling g
tls [6]uintptr // thread-local storage (for x86 extern register) 通常会存当前正在运行的g的指针
curg *g // current running goroutine
p puintptr // attached p for executing go code (nil if not executing go code)
oldp puintptr // the p that was attached before executing a syscall
id int64
locks int32 // 锁
spinning bool // m is out of work and is actively looking for work
alllink *m // on allm 所有m以链表的方式串联这里表示链表中下一个m
schedlink muintptr // spinning自旋中的m也以链表的方式串联 这里表示下一个自旋的m
lockedg guintptr
syscalltick uint32 // 系统调用时 用来标识陷入系统调用的时间
freelink *m // on sched.freem // 所有的空闲的m以链表的方式串联 这里表示下一个空闲的m
mOS // 绑定的物理线程的数据结构
}
三、P的定义
type p struct {
id int32
status uint32 // one of pidle/prunning/...
link puintptr // 空闲的p以链表的方式串联 表示下一个空闲的p
schedtick uint32 // incremented on every scheduler call
syscalltick uint32 // incremented on every system call
sysmontick sysmontick // last tick observed by sysmon
m muintptr // back-link to associated m (nil if idle)
goidcache uint64 // 缓存的goid的当前值
goidcacheend uint64 // 缓存goid的最大值
// Queue of runnable goroutines. Accessed without lock.
runqhead uint32
runqtail uint32
runq [256]guintptr // 保存的该P上的可运行的G的队列
runnext guintptr // 表示下一个要运行的G 通常newproc产生的g会放在这里
// Available G's (status == Gdead)
gFree struct {
gList
n int32
}
}
四、sched变量
type schedt struct {
goidgen uint64
// allm idlem freem 链表是全局变量均需考虑同步
midle muintptr // idle m's waiting for work 空闲状态m链表中的首个m地址
nmidle int32 // number of idle m's waiting for work //空闲状态m的数量
nmidlelocked int32 // number of locked m's waiting for work
mnext int64 // number of m's that have been created and next M ID // 当前m的数量和下一个m的ID
maxmcount int32 // maximum number of m's allowed (or die) // 允许的m的最大数量
// 空闲p以链表的方式存储 注意同步读写
pidle puintptr // idle p's 空闲的p的链表的首个元素
npidle uint32 // 空闲p的数量
// nmspinning 表示当前处于自旋状态的p的数量（正在执行findrunnable函数）
nmspinning uint32 // See "Worker thread parking/unparking" comment in proc.go.
// Global runnable queue.
runq gQueue // 全局的runnable状态的G 当p的队列满了时会将p放入该队列中
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 // 空闲的m以链表的方式串联 这里表示m空闲链表的首个m
}
其它全局数据
allm *m // 所有m以链表的方式链接在一起 m.alllink表示下一个m
// 所有p都放在该数组中 通常等于CPU核心数 在初始化时确定
allp []*p // len(allp) == gomaxprocs; may change at safe points, otherwise immutable
allgs []*g // 管理所有的g
关于GPM的数量
1.P的数量，P的数量通常等于CPU的数量，在Go程序初始化时创建，且通常不增不减。
2.G的数量，G在newproc函数(即go func(){})中可能会创建，当G对应的函数执行完成后，G不会释放，而是缓存起来，当需要时则优先从缓存中拿。
3.M的数量，当G进入可运行状态时，如果有空闲的P则可能会创建M来执行G。当M陷入系统调用或者cgo时，会剥夺M P的绑定，当退出系统调用后，不会释放M，而是等待空闲的P进行绑定，因此M的数量是不定的。
一些特例
1.特殊的线程sysmon，除该线程外其它物理线程均和m绑定，一一对应。
2.m0，m0是特殊的M，通常执行main函数，且还有其它特定的用途。
3.g0，每个m都有一个g0，g0通常会分配更大的栈，且它的栈不会扩容（普通的g的栈初始大小为2K，根据需要扩容）。g0通常执行调度相关代码，和普通的g的扩容的代码。g0的栈和物理线程的栈进行绑定，物理线程的栈即g0的栈，当使用cgo是，g0栈绑定到物理线程，如果不使用cgo则是物理线程的栈绑定到g0的栈（区别在于栈的位置和栈的大小）。
4.为什么使用cgo时使用物理线程的栈？因为cgo代码通常是别的语言所写，调用cgo时，使用的是g0的栈，如果该栈和物理线程大小不等，则可能出现库在别的语言可以正常调用，在golang中出现栈过小调用失败的情况。
有疑问加站长微信联系（非本文作者）
