GMP调度

设计目的，为何设计GMP?

无论是多进程、多线程目的都是为了并发提高cpu的利用率，但多进程、多线程都存在局限性。比如多进程通过时间轮片等调度方式实现宏观上并发，但进程间资源独立，切换开销大，多线程虽然共享内存不需要内存页表的切换，但还是涉及到用户态、内核态的切换，权级的切换开销是最大的。 所以多进程，多线程存在切换开销大、高内存占用的问题； 想进一步提高cpu的高利用率，需要避免内核介入，权级的切换，所以协程就是这样实现的，它相当于用户态的线程，操作都在用户态下进行，对内核透明更加轻量。 协程与线程 为 M：1 的关系，M：1存在问题M个协程在同一个线程上进行，无法实现并行。 所以问题归根起来就是：实现一个好的调度器，能很好的处理M个协程映射到N个线程上。golang通过GMP模型实现这种调度。

GMP的底层实现

几个核心数据结构

G是golang对协程的抽象，如下图：核心字段gobuf是g的运行信息（gobuf的运行信息能保障这个goroutine由于系统调用之外的其他调度而暂停时，下次调度到的时候能恢复执行，里面存了包括堆栈指针SP等信息）， *m是运行当前g的m（动态绑定的）。 g的状态：waiting、runable、running、dead等
G要绑定到P上才能执行，在G的视角里P是CPU；

M是golang对线程的抽象，M不直接执行G，而是由P作为代理，M无需跟G绑定，也无需记录G的状态信息，因此G在生命周期中可以跨线程M执行；在m结构体中有一个g0调度协程，执行g之间的切换调度，不执行用户函数，与M为1：1；TLS中保存当前执行g的信息，这个信息保存能保证M在唤醒的时候能执行休眠之前的goroutine(当然，如果M跟着G一起休眠，大概率是因为G由于系统调用而阻塞，G的其他的3种调度类型比如主动调度、被动调度、正常调度都在用户态下，并不会导致M休眠)

P是golang的调度器，对G来说P是CPU，对M来说P是代理，为M提供可执行的G；数据结构主要是一个256长度的P本地队列，队头指针，队尾指针，以及一个runnext指针，这个指针指向下一个可执行的goroutine（这个指针在维护局部性的时候有用到）

schedt全局队列
全局任务队列加锁，记录长度

GMP调度流程

GMP调度流程主要体现在g0_gg0的循环中

1. g0执行schedule()函数寻找可执行的g；

2. g0执行execute()函数，更新g的状态信息，调用gogo()方法，将执行权交给g

3. g因为4种调度方式调用m_call函数，把执行权重新交给g0；

4. g0重新schedule()寻找可执行的g;

5. g0调用schedule（）寻找可执行g的细节：调用了findRunable()方法，在这个方法中，每寻找61次g都会在全局队列中取一个g（防止全局队列中的G饿死），否则就正常从p的本地队列中取，如果本地队列空了，就加锁到全局队列中取，全局队列也没有就通过workstrealing机制去其他P中尝试获取一半，这个过程是4次尝试，并且通过随机因子寻找P，一定程度上保证了公平性，窃取完后会调整目标P的队首指针；

6. 更新g的状态信息，比如修改g的m为当前m，而后g获得执行权，开始执行任务

7. g执行任务时，有4中调度方式会导致执行权回到g0的手里，主动调度（用户调用shced方法）、被动调度（不满足执行条件，比如管道阻塞、没有获得锁等，调用g_park()后g进入waiting态，可通过g_read()唤醒）、正常完成（G的任务完成）、抢占调度（G发起系统调用，导致进入阻塞，这时的阻塞是进入到了内核态，因为G发起的系统调用是以M的身份发起的，此时M也是僵直的，所以g0是无法感知到的，所以抢占调度其实是需要一个监控协程来完成的，这个协程越过p直接跟M绑定。 此时阻塞的G跟M绑定，监控协程会把P抽离出来，找一个M重新跟P绑定）

所以整个流程可以描述为