1、Golang调度器的由来
2、Goroutine调度器的GMP模型及设计思想
3、Goroutine调度场景过程全图文解析
早期的单进程操作系统，面临2个问题：
1.单一的执行流程，计算机只能一个任务一个任务处理。
2.进程阻塞所带来的CPU时间浪费。
多进程/线程时代有了调度器需求：
进程拥有太多的资源，进程的创建、切换、销毁，都会占用很长的时间，CPU虽然利用起来了，但如果进程过多，CPU有很大的一部分都被用来进行进程调度了
多进程、多线程已经提高了系统的并发能力，但是在当今互联网高并发场景下，为每个任务都创建一个线程是不现实的，因为会消耗大量的内存(进程虚拟内存会占用4GB[32位操作系统], 而线程也要大约4MB)。
大量的进程/线程出现了新的问题
- 高内存占用
- 调度的高消耗CPU
好了，然后工程师们就发现，其实一个线程分为“内核态“线程和”用户态“线程。
一个“用户态线程”必须要绑定一个“内核态线程”，但是CPU并不知道有“用户态线程”的存在，它只知道它运行的是一个“内核态线程”(Linux的PCB进程控制块)。
Go语言的协程goroutine
runtimeruntimeGoroutine特点：
- 占用内存更小（几kb）
- 调度更灵活(runtime调度)
Goroutine调度器的GMP模型的设计思想：
面对之前调度器的问题，Go设计了新的调度器。
在新调度器中，出列M(thread)和G(goroutine)，又引进了P(Processor)。
Processor，它包含了运行goroutine的资源，如果线程想运行goroutine，必须先获取P，P中还包含了可运行的G队列。
在Go中，线程是运行goroutine的实体，调度器的功能是把可运行的goroutine分配到工作线程上。
GOMAXPROCSGoroutine调度器和OS调度器是通过M结合起来的，每个M都代表了1个内核线程，OS调度器负责把内核线程分配到CPU的核上执行
有关P和M的个数问题：
1、P的数量：
$GOMAXPROCSruntimeGOMAXPROCS()$GOMAXPROCS2、M的数量:
- go语言本身的限制：go程序启动时，会设置M的最大数量，默认10000.但是内核很难支持这么多的线程数，所以这个限制可以忽略。
- runtime/debug中的SetMaxThreads函数，设置M的最大数量
- 一个M阻塞了，会创建新的M。
M与P的数量没有绝对关系，一个M阻塞，P就会去创建或者切换另一个M，所以，即使P的默认数量是1，也有可能会创建很多个M出来。
复用线程：避免频繁的创建、销毁线程，而是对线程的复用。
1）work stealing机制
当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程。
2）hand off机制
当本线程因为G进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行。
GOMAXPROCSGOMAXPROCSGOMAXPROCSGOMAXPROCS = 核数/2抢占：在coroutine中要等待一个协程主动让出CPU才执行下一个协程，在Go中，一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死，这就是goroutine不同于coroutine的一个地方。
全局G队列：在新的调度器中依然有全局G队列，但功能已经被弱化了，当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G。
(4)调度器的生命周期
特殊的M0和G0
M0
M0G0
G0