goroutine 和 thread
- thread
linux线程本质是轻量级进程，
线程的特点是资源共享，意思就是线程之间共享进程的内存空间，所以一个线程可以访问另一个线程的局部变量，
线程也有自己独立的堆栈，用户的代码逻辑可以在这些堆栈上执行。
当用户启动一个线程时，需要指定一个
让该线程执行的起始函数和
该函数的参数，
那么线程要做的事情就是去执行用户指定的函数。而且在线程里可以创建另一个线程。
- 内存占用
创建一个 goroutine 的栈内存消耗为 2 KB，
实际运行过程中，如果栈空间不够用，会自动进行扩容。
创建一个 thread 则需要消耗 1 MB 栈内存，而且还需要一个被称为 “a guard page” 的区域用于和其他 thread 的栈空间进行隔离。
对于一个用 Go 构建的 HTTP Server 而言，对到来的每个请求，创建一个 goroutine 用来处理是非常轻松的一件事。而如果
用一个使用线程作为并发原语的语言构建的服务，
例如 Java 来说，每个请求对应一个线程则太浪费资源了，很快就会出 OOM 错误（OutOfMermoryError）。
- 创建和销毀
Thread 创建和销毀都会有巨大的消耗，
因为要和操作系统打交道，是内核级的，
通常解决的办法就是线程池。而
goroutine 因为是由 Go runtime 负责管理的，创建和销毁的消耗非常小，是用户级。
- 切换
当 threads 切换时，需要保存各种寄存器，以便将来恢复：
16 general purpose registers,
PC (Program Counter),
SP (Stack Pointer),
segment registers,
16 XMM registers,
FP coprocessor state,
16 AVX registers,
all MSRs etc.
而 goroutines 切换只需保存三个寄存器：
Program Counter,
Stack Pointer and
BP。
一般而言，线程切换会消耗 1000-1500 纳秒，一个纳秒平均可以执行 12-18 条指令。所以由于线程切换，执行指令的条数会减少 12000-18000。
Goroutine 的切换约为 200 ns，相当于 2400-3600 条指令。
因此，goroutines 切换成本比 threads 要小得多。
m:n模型
Go runtime 会负责 goroutine 的生老病死，从创建到销毁整个生命周期，都一手包办。
Runtime 会在程序启动的时候，创建 M 个线程（CPU 执行调度的单位），
之后创建的 N 个 goroutine 都会依附在这 M 个线程上执行。这就是 M:N 模型：
在同一时刻，一个线程上只能跑一个 goroutine。
当 goroutine 发生阻塞（例如上篇文章提到的向一个 channel 发送数据，被阻塞）时，runtime 会把当前 goroutine 调度走，让其他 goroutine 来执行。
目的就是不让一个线程闲着，榨干 CPU 的每一滴油水。
什么是 scheduler
Go 程序的执行由两层组成：
Go Program
Runtime，即用户程序和运行时。
它们之间通过函数调用来实现
内存管理、
channel 通信、
goroutines 创建等功能。
用户程序进行的系统调用都会被 Runtime 拦截，以此来帮助它进行调度以及垃圾回收相关的工作。
为什么要 scheduler
Go scheduler 可以说是 Go 运行时的一个最重要的部分了。
Runtime 维护所有的 goroutines，并通过 scheduler 来进行调度。
Goroutines 和 threads 是独立的，
但是 goroutines 要依赖 threads 才能执行。
Go 程序执行的高效和 scheduler 的调度是分不开的。
scheduler 底层原理
实际上在操作系统看来，所有的程序都是在执行多线程。
将 goroutines 调度到线程上执行，仅仅是 runtime 层面的一个概念，在操作系统之上的层面。
scheduler有三个基础的结构体来实现 goroutines 的调度。g，m，p。
G（goroutine）
调度系统的最基本单位goroutine，存储了
goroutine的执行stack信息、
goroutine状态以及
goroutine的任务函数等。
在G的眼中只有P，P就是运行G的“CPU”。P保存了需要执行的那些goroutine；
相当于两级线程
// 每个g的实例都有任务函数，如下代码, 任务函数是userFunc
userFunc := func() {
fmt.Println("hi boya!")
}
go userFunc()
P（processor）
P表示逻辑processor，代表线程M的执行的上下文。
P的最大作用是其拥有的各种G对象队列、链表、cache和状态。
P的数量也代表了golang的执行并发度，即有多少goroutine可以同时运行
这里的p虽然表示逻辑处理器，但P并不执行任何代码，
对G来说，P相当于CPU核，G只有绑定到P才能被调度。
对M来说，P提供了相关的执行环境(Context)，如内存分配状态(mcache)，任务队列(G)等
M（machine）
M代表着真正的执行计算资源，可以认为它就是os thread（系统线程）。
M是真正调度系统的执行者，每个M就像一个勤劳的工作者，总是从各种队列中找到可运行的G，而且这样M的可以同时存在多个。
M在绑定有效的P后，进入调度循环，而且M并不保留G状态，这是G可以跨M调度的基础。
在整个go调度的层面，对外的是M，P会找到一个M，让它去与外面的线程交互，从而去真正执行程序。
- GPM的关系示意图
通过连线可以看出来，
M和P有关联，
G和P有关联，
但M和G没有关联, 这是为何G可以在不同的M上执行的本质原因。g眼中之后p, p选一个m执行, 对外的是M
当然还有一个核心的结构体：sched，它总览全局。
Runtime 起始时会启动一些 G：
垃圾回收的 G，
执行调度的 G，
运行用户代码的 G；
并且会创建一个 M 用来开始 G 的运行。
随着时间的推移，更多的 G 会被创建出来，更多的 M 也会被创建出来。
- src/runtime/runtime2.go
type g struct {...
type m struct {...
type p struct {...
type schedt struct {...
Go scheduler 会启动一个后台线程 sysmon，用来检测长时间（超过 10 ms）运行的 goroutine，将其调度到 global runqueues。这是一个全局的 runqueue，优先级比较低，以示惩罚。
总览
通常讲到 Go scheduler 都会提到 GPM 模型，我们来一个个地看。
下图是我使用的 mac 的硬件信息，只有 2 个核。
func main() {
// NumCPU 返回当前进程可以用到的逻辑核心数
fmt.Println(runtime.NumCPU()) //因为 NumCPU 返回的是逻辑核心数，而非物理核心数，所以最终结果是 4。
}
当我在本地启动一个 Go 程序时，会得到 4 个系统线程去执行任务，每个线程会搭配一个 P。
G、P、M 都说完了，还有两个比较重要的组件没有提到： 全局可运行队列（GRQ）和本地可运行队列（LRQ）。 LRQ 存储本地（也就是具体的 P）的可运行 goroutine，GRQ 存储全局的可运行 goroutine，这些 goroutine 还没有分配到具体的 P。
Go scheduler 是 Go runtime 的一部分，它内嵌在 Go 程序里，和 Go 程序一起运行。因此它运行在用户空间，在 kernel 的上一层。和 Os scheduler 抢占式调度（preemptive）不一样，Go scheduler 采用协作式调度（cooperating）。
work stealing
Go scheduler 的职责就是将所有处于 runnable 的 goroutines 均匀分布到在 P 上运行的 M。
当一个 P 发现自己的 LRQ 已经没有 G 时，会从其他 P “偷” 一些 G 来运行。看看这是什么精神！自己的工作做完了，为了全局的利益，主动为别人分担。这被称为 Work-stealing，Go 从 1.1 开始实现。
Go scheduler 使用 M:N 模型，在任一时刻，M 个 goroutines（G） 要分配到 N 个内核线程（M），这些 M 跑在个数最多为 GOMAXPROCS 的逻辑处理器（P）上。每个 M 必须依附于一个 P，每个 P 在同一时刻只能运行一个 M。如果 P 上的 M 阻塞了，那它就需要其他的 M 来运行 P 的 LRQ 里的 goroutines。
个人感觉，上面这张图比常见的那些用三角形表示 M，圆形表示 G，矩形表示 P 的那些图更生动形象。
找到一个可执行的 goroutine 后，就会一直执行下去，直到被阻塞。
当 P2 上的一个 G 执行结束，它就会去 LRQ 获取下一个 G 来执行。如果 LRQ 已经空了，就是说本地可运行队列已经没有 G 需要执行，并且这时 GRQ 也没有 G 了。这时，P2 会随机选择一个 P（称为 P1），P2 会从 P1 的 LRQ “偷”过来一半的 G。
这样做的好处是，有更多的 P 可以一起工作，加速执行完所有的 G。
调度中存在的问题
问题1 G不均
我们知道，现实情况有的goroutine运行的快，有的慢，那么势必肯定会带来的问题就是，忙的忙死，闲的闲死，go肯定不允许摸鱼的P存在，势必要榨干所有劳动力。
如果你没有任务，那么，我们看到模型中还有一个全局G队列的存在，如本地队列已满，会一次性转移半数到全局队列。其他闲的小伙子就会从全局队列中拿；（顺便说一下，优先级是先拿下一个需要执行的，然后去本地队列中拿，再去全局队列中拿，先把自己的做完再做别人的嘛）同时如果全局都没有了，就会去抢别人的做。
问题2 任务卡主了
万一有个程序员启动一个goroutine去执行一个任务，然后这个任务一直睡觉（sleep）就是循环睡觉，那咋办嘛！你作为执行人，你总不能说，让它一直占用着一整个线程的资源，然后后面的goroutine都卡主了，那如果只有一个核心P，不就完蛋了？聪明的go才不会那么傻，它采用了抢占式调度来解决这个问题。只要你这个任务执行超过一定的时间（10ms），那么这个任务就会被标识为可抢占的，那么别的goroutine就可以抢先进来执行。只要下次这个goroutine进行函数调用，那么就会被强占，同时也会保护现场，然后重新放入P的本地队列里面等待下次执行。
谁来做的呢？
sysmon，就是这个背后默默付出的人，它是一个后台运行的监控线程，它来监控那些长时间运行的G任务然后设置可以强占的标识符。（同时顺便提一下，它还会做的一些事情，例如，释放闲置的span内存，2分钟的默认gc等）
问题3 阻塞可怎么办？
我们经常使用goroutine还有一个场景就是网络请求和IO操作，这种阻塞的情况下，我们的G和M又会怎么做呢？
这个时候有个叫做netpoller的东西出现了，当每次有一个网络请求阻塞的时候，如果按照原来的方法这个时候这个请求会阻塞线程，而有了netpoller这个东西，可以将请求阻塞到goroutine。
意思是说，当阻塞出现的时候，当前goroutine会被阻塞，等待阻塞notify，而放出M去做别的g，而当阻塞恢复的时候，netpoller就会通知对应的m可以做原来的g了。
同时还要顺便提一句，当P发现没有任务的时候，除了会找本地和全局，也会去netpoll中找。
问题4 系统方法调用阻塞？
还有一个问题，我们自己想可能比较难想到，就是当调用一些系统方法的时候，如果系统方法调用的时候发生阻塞就比较麻烦了。下面引用一段话：
当G被阻塞在某个系统调用上时，此时G会阻塞在_Gsyscall状态，M也处于block on syscall状态，此时的M可被抢占调度：执行该G的M会与P解绑，而P则尝试与其它idle的M绑定，继续执行其它G。如果没有其它idle的M，但P的Local队列中仍然有G需要执行，则创建一个新的M；当系统调用完成后，G会重新尝试获取一个idle的P进入它的Local队列恢复执行，如果没有idle的P，G会被标记为runnable加入到Global队列。