社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
操作系统的调度模型是大致上有两种N:1和1:1. N:1模型中用户态的线程运行在一个内核线程上，这种方式上下文切换快，但不能有效利用多核。
1:1模型中的一个用户态线程对应一个内核线程，这种方式有效利用了多核，但上下文切换非常慢(因为要不停trap陷入内核)。Goroutine是协程，即轻量级线程，用户态完成调度，Rob Pike先生想利用有限的os线程去调度和执行任意数量的goroutine，显然是想把N:1模型和1:1模型的优点都收入囊中。
不要一下子就掉入源码去看go的实现，看下我们能想到的调度模型: 线程+任务队列.
其中G就是goroutine，先开一个线程池，线程不停地从queue中取goroutine执行。如果一个goroutine里面出现了长时间系统调用，那么就会阻塞线程直到系统调用结束。假设队列里面所有的goroutine都是长时间系统调用，那么线程都会被阻塞住，这显然不合理。我们需要的是：goroutine可以阻塞，但线程不可以阻塞或者说线程不可以出现长时间阻塞。要做到这点线程必须知道此时goroutine的状态，然后是wait状态的时候就将它换出去，执行其他goroutine，同时记住上次goroutine的上下文，以便下次继续执行。goroutine的状态：
这样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队列就好了，不需要每次都竞争解决了。
这样是不是完美了呢？牛人说过：计算机上的所有问题都可以通过增加一个抽象层来解决。我们希望线程不要过多的担负调度的任务，调度应该由抽象层来完成，线程只管执行，于是乎：
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忙成狗了，这样好吗？估计有良心的程序员都觉得不太好，那怎么解决这个问题呢？其实我们需要一个机制，如果发现空闲了，就从别人家偷点任务来玩玩，这好刺激啊，偷偷摸摸的感觉。又需要一个抽象层来帮忙下了：
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。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
