小小书童窥探goroutine调度

操作系统的调度模型是大致上有两种N:1和1:1. N:1模型中用户态的线程运行在一个内核线程上，这种方式上下文切换快，但不能有效利用多核。

1:1模型中的一个用户态线程对应一个内核线程，这种方式有效利用了多核，但上下文切换非常慢(因为要不停trap陷入内核)。Goroutine是协程，即轻量级线程，用户态完成调度，Rob Pike先生想利用有限的os线程去调度和执行任意数量的goroutine，显然是想把N:1模型和1:1模型的优点都收入囊中。

不要一下子就掉入源码去看go的实现，看下我们能想到的调度模型:  线程+任务队列.

(thread+queue)

其中G就是goroutine，先开一个线程池，线程不停地从queue中取goroutine执行。如果一个goroutine里面出现了长时间系统调用，那么就会阻塞线程直到系统调用结束。假设队列里面所有的goroutine都是长时间系统调用，那么线程都会被阻塞住，这显然不合理。我们需要的是：goroutine可以阻塞，但线程不可以阻塞或者说线程不可以出现长时间阻塞。要做到这点线程必须知道此时goroutine的状态，然后是wait状态的时候就将它换出去，执行其他goroutine，同时记住上次goroutine的上下文，以便下次继续执行。goroutine的状态：

goroutine-stauts

这样G的数据结构就出来了：

struct G  {

      uintptr    stackguard;    // 分段栈的可用空间下界

     uintptr    stackbase;    // 分段栈的栈基址

     Gobuf      sched;        //进程切换时，利用sched域来保存上下文

     uintptr    stack0;  

     FuncVal*    fnstart;    // goroutine运行的函数

     void*    param;          // 用于传递参数，睡眠时其它goroutine设置param，唤醒时此goroutine可以获取

     int16    status;        // 状态Gidle,Grunnable,Grunning,Gsyscall,Gwaiting,Gdead

     int64    goid;          // goroutine的id号

     G*    schedlink;

     M*    m;      // for debuggers, but offset not hard-coded  

     M*    lockedm;          // G被锁定只能在这个m上运行

     uintptr    gopc;        // 创建这个goroutine的go表达式的pc

};

其中status字段就表示goroutine的状态。有了这些信息，线程就可以自如地调度和执行协程了。这个方案是完美的吗? 至少我们能看出一个地方不好：线程每次取G的时候都要加排它锁，这样势必导致调度和执行的效率下降。我们把G分成多个queue，每一个queue都归属于一个线程去执行(M*   lockedm)。这样线程只需要管理自己的queue队列就好了，不需要每次都竞争解决了。

queues

这样是不是完美了呢？牛人说过：计算机上的所有问题都可以通过增加一个抽象层来解决。我们希望线程不要过多的担负调度的任务，调度应该由抽象层来完成，线程只管执行，于是乎：

m-queues

M的数据结构出来了：

struct M   {

     G*    g0;        // 带有调度栈的goroutine

     G*    gsignal;    // signal-handling G 处理信号的goroutine

     void    (*mstartfn)(void);  // 线程入口

     G*    curg;        // M中当前运行的goroutine

    P*    p;        // 关联P以执行Go代码 (如果没有执行Go代码则P为nil)

    P*    nextp;

    int32    mallocing; //状态

    int32    helpgc;        //不为0表示此m在做帮忙gc。helpgc等于n只是一个编号

    M*    alllink;    // 这个域用于链接allm

    M*    schedlink;

     MCache    *mcache;

    G*    lockedg;

    M*    nextwaitm;    // next M waiting for lock

    GCStats    gcstats;

};

增加了一个M层来参与调度goroutine，这样让线程从调度和执行任务里面解脱出来。这下完美了吧！！！！！。假设一个情况：有4个M，其中有3个M在打酱油，1个M忙成狗了，这样好吗？估计有良心的程序员都觉得不太好，那怎么解决这个问题呢？其实我们需要一个机制，如果发现空闲了，就从别人家偷点任务来玩玩，这好刺激啊，偷偷摸摸的感觉。又需要一个抽象层来帮忙下了：

m-p-queues

P的数据结构出来了：

struct P  {

     Lock;

    uint32    status;  // Pidle或Prunning等

    P*    link;

    uint32    schedtick;  // 每次调度时将它加一

    M*    m;    // 链接到它关联的M (nil if idle)

    MCache*    mcache;

    G*    runq[256];

    int32    runqhead;

    int32    runqtail;

    G*    gfree;

};

早期版本的Golang是没有P的，调度是由G与M完成。 这样的问题在于每当创建、终止Goroutine或者需要调度时，需要一个全局的锁来保护调度的相关对象(sched)。 全局锁严重影响Goroutine的并发性能。 (Scalable Go Scheduler)。 通过引入P，实现了一种叫做work-stealing的调度算法：

1. 每个P维护一个G队列；

2. 当一个G被创建出来，或者变为可执行状态时，就把他放到P的可执行队列中；

3. 当一个G执行结束时，P会从队列中把该G取出；如果此时P的队列为空，即没有其他G可以执行， 就随机选择另外一个P，从其可执行的G队列中偷取一半。

该算法避免了在Goroutine调度时使用全局锁。

恩，这下完美了？至少Rob Pike觉得这样完美了。讲到现在一直没有说其中还有一个隐形的手，这个手就是Schedu调度器，它是幕后的大Boss。