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的联系，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列表。

参考资料：

https://blog.csdn.net/u010853261/article/details/84790392

https://blog.csdn.net/u010853261/article/details/85231944

关于goroutinue和channel原理，想知道更详细的内容，强烈推荐这俩篇文章，写得相当细致！