G M P模型
G —— goroutinue对象，经go语句创建
M —— 系统线程，和P关联后运行G，上限10000
P —— 调度器，和M关联后运行G，数量由 runtime.MAXGOPROCS 设置，默认为CPU核数，上限256
此外还有一个系统调度器（runtime.sched），负责维护一些全局队列。
M的状态
自旋中：M正在从运行队列获取G, 这时候M会拥有一个P
执行中：M正在执行go代码, 这时候M会拥有一个P
挂起中：M正在执行阻塞的syscall, 这时M并不拥有P
休眠中：M发现无待运行的G时会进入休眠，并添加到空闲M链表中, 这时M并不拥有P
P的状态
Pidel：当前P未和任何M关联
Prunning：当前P已经和某个M关联，M在执行某个G
Psyscall：当前P中的被运行的那个G正在进行系统调用
Pgcstop：runtime正在进行GC（runtime会在gc时试图把全局P列表中的P都处于此种状态）
Pdead：当前P已经不再被使用（在调用runtime.GOMAXPROCS减少P的数量时，多余的P就处于此状态）
G的状态
Gidle：G被创建但还未完全被初始化。
Grunnable：G完成初始化，为可运行的，正在等待被运行。
Grunning：G正在被运行。 Gsyscall：G正在被系统调用
Gwaiting：G正在因某个原因（channel阻塞、网络I/O、timer等事件）而等待
Gdead：G完成了运行
存在哪些队列：
全局M列表（runtime.allm）—— 存在于系统，存放所有M
全局P列表（runtime.allp）—— 存在于系统，存放所有P（runtime初始化时会根据P的最大值创建好所有P并存放于此）
全局G列表（runtime.allg）—— 存在于系统，存放所有G
全局空闲M列表（runtime.schedt.midle）—— 存在于调度器，存放休眠状态的M
全局空闲P列表（runtime.schedt.pidle）—— 存在于调度器，存放idel状态的P
全局可运行G队列（runtime.schedt.runq）—— 存在于调度器，存放runnable状态的G
全局自由G列表（runtime.schedt.gfree）—— 存在于调度器，存放dead状态的G，以备复用
P中的可运行G队列（runq）—— 存在于本地P，存放当前P中的可运行G
P中的自由G列表（gfree）—— 存在于本地P，存放当前P中的自由G，以备复用
在 runtime 中有三种线程：
一种是主线程
一种是用来跑 sysmon 的线程
一种是普通的用户线程
主线程用来跑 runtime.main，流程线性执行，没有跳转。
用户线程就是普通的线程了，和 p 绑定，执行 g 中的任务。
sysmon 线程用来监听P上G的执行，实现抢占式调度。
虽然说是有三种，实际上前两种线程整个 runtime 就只有一个实例。用户线程才会有很多实例。
当我们go func()时：
1、会先后在本地和全局自由G队列中看看有没有可复用的G，有的话直接初始化这个G，没有的话新建一个。
2、将这个G放入本地可运行G队列，如果本地满了就放到全局可运行G队列。
3、P和M关联，轮询并执行本地G队列（如果本地G队列没有任务，那就从全局G队列获取全部任务，如果也没有就从其他P的本地G队列中窃取一半任务）
4、处于waiting状态的G会被略过，M继续执行其他的G，当G被唤醒后会被重新丢回P队列底部。
5、sysmon 发现处于syscall状态的P，会断开M和P的关联，并将M挂起，从syscall转出来的G，尝试获取空闲的P，如果不成功，就会被放置到全局调度器的可运行队列中。
（go1.14版本后，sysmon会针对超时10ms执行的G，发送sigurg信号，runtime收到信号后会断开M和P的关联）
6、G任务完成后，会放入本地自由G列表，当积攒到一定程度后，runtime会把其中的部分G转移到全局调度器的自由G列表。
关于goroutinue原理，想知道更详细的内容，强烈推荐这篇文章https://blog.csdn.net/u010853261/article/details/84790392，写得相当细致！
有疑问加站长微信联系（非本文作者）
