为什么在内核的线程调度器之外Go还需要一个自己的调度器？
- POSIX线程API是对已有的UNIX进程模型的逻辑扩展，因此线程和进程在很多方面都类似。例如，线程有自己的信号掩码，可以分配CPU affinity（进程要在某个给定的 CPU 上尽量长时间地运行而不被迁移到其他处理器的倾向性），可以放入 cgroups中，并且可以查询它们使用的资源。但是这些特性对于Go程序来说都是不必要的开销。
- 另外一个问题是基于Go语言模型，OS的调度决定并不一定合理。例如，Go的垃圾回收需要内存处于一致性的状态，这需要所有运行的线程都停止。垃圾回收的时间点是不确定的，如果仅由OS来调度，将会由大量的线程停止工作。单独开发一个Go的调度器能让我们知道什么时候内存处于一致性的状态。也就是说，当开始垃圾回收时，运行时只需要为当时正在CPU核上运行的那个线程等待即可，而不是等待所有的线程。
线程模型——高级语言对内核线程的封装实现
N:1模型，N个用户空间线程在1个内核空间线程上运行。优势是上下文切换非常快但是无法利用多核系统的优点。
1:1模型，1个内核空间线程运行一个用户空间线程。这种充分利用了多核系统的优势但是上下文切换非常慢，因为每一次调度都会在用户态和内核态之间切换。（POSIX线程模型(pthread)，Java）
M:N模型， 每个用户线程对应多个内核空间线程，同时也可以一个内核空间线程对应多个用户空间线程。Go打算采用这种模型，使用任意个内核模型管理任意个goroutine。这样结合了以上两种模型的优点，但缺点就是调度的复杂性。
Golang的调度器实现
Go的调度器使用了三种结构：M，P，S
M代表内核线程，类似于标准的POSIX线程，M代表machine。
G代表goroutine，它拥有自己的栈，程序计数器（instruction counter）和一些关于goroutine调度的信息（如正在阻塞的channel）。
P代表processor，表示调度的上下文。可以把它看作是一个局部的调度器，让Go代码跑在一个单独的线程上。这是让Go从一个N:1调度器映射到一个M:N调度器的关键。
如上图所示，每个线程运行了一个goroutine，所以必须得维持一个上下文P。
上下文的数量由启动时环境变量 G O M A X P R O C S 或 者 是 由 r u n t i m e 的 方 法 G O M A X P R O C S ( ) 决 定 （ 默 认 值 为 1 ） 。 这 意 味 着 在 程 序 执 行 的 任 意 时 刻 都 只 有 GOMAXPROCS或者是由runtime的方法GOMAXPROCS()决定（默认值为1）。这意味着在程序执行的任意时刻都只有 GOMAXPROCS或者是由runtime的方法GOMAXPROCS()决定（默认值为1）。这意味着在程序执行的任意时刻都只有GOMAXPROCS个goroutine在同时运行。
灰色的goroutine没有在运行，等待被调度。它们被维护在一个队列（runqueues）里。当一个go语句执行，就将一个新的goroutine添加到队列尾；当运行当前goroutine到调度点时，就从队列中弹出一个新的goroutine。
每一个context拥有一个局部的runqueue。之前版本的Go调度器只有一个全局的带有互斥锁的runqueue，这样线程经常被阻塞等待其它线程解锁，在多核机器上性能表现及其差。
之所以要维护多个context，是因为当一个OS线程被阻塞时，我们可以把contex移到其它的线程中去。
如上图所示，当一个内核线程M0要被阻塞时，P将会去M1上继续运行。Go的调度器保证了拥有足够的线程跑所有的contexts。因为还有在执行的goroutine，M0会暂时挂起。当syscall返回时，M0会尝试获取一个context来运行G0。一般情况下，它会从其它内核线程偷一个过来。如果没有偷到，它会把G0放到一个全局的runqueue内，将自己放回线程池，进入睡眠状态。
当contexts运行完所有的本地runqueue时，它会从全局runqueue拉取goroutine。contexts也会周期性检查全局runqueue是否存在goroutine，以防止全局runqueue中的goroutine饿死。
这就是为什么Go程序多线程运行的原因，即使GOMAXPROCS只有1。
另外一种情况就是某个context的goroutine运行完了，全局runqueue也没有了goroutine，而其它context还有大量goroutine需要运行。这时候就需要从其它的地方获取goroutine。如图所示，context会尝试从其它context的runqueue里面偷一半的goroutine。这样就能确保所有的线程都能以最大负荷运行。