Go中，协程被称为goroutine，它非常轻量，一个goroutine只占几KB，并且这几KB就足够goroutine运行完，这就能在有限的内存空间内支持大量goroutine，支持了更多的并发，虽然一个goroutine的栈只占几KB（Go语言官方说明为4～5KB），但实际是可伸缩的，如果需要更多内容，runtime会自动为goroutine分配。

Goroutine特点：

G（Goroutine）：我们在Go语言中所说的协程，为用户级的轻量级线程，每个Goroutine对象中的sched保存着其上下文信息。 M（Machine）：对内核级线程的封装，数量对应真实的CPU数（真正干活的对象，默认最大数量为10000）。 P（Processor）：即为G和M的调度对象，用来调度G和M之间的关联关系，其数量可通过，GOMAXPROCS（）来设置，默认为核心数。

调度器把G都分配M上，不同的G在不同的M并发运行时，都需要向系统申请资源，比如堆栈内存等，因为资源是全局的，就会因为资源竞争造成很多性能损耗。为了解决这样的问题go从1.1版本引入，在运行时系统的时候加入p对象，让P去管理这个G对象，M想要运行G，必须绑定P，才能运行P所管理的G。

GM调度存在的问题：

Go中，线程是运行goroutine的实体，调度器的功能是把可运行的goroutine分配到工作线程上。

Goroutine调度器和OS调度器是通过M结合起来的，每个M都代表了1个内核线程，OS调度器负责把内核线程分配到CPU的核上执行。

流程：

M0 M0是启动程序后的编号为0的主线程，这个M对应的实例会在全局变量runtime.m0中，不需要在heap上分配，M0负责执行初始化操作和启动第一个G，在之后M0就和其他的M一样了。 G0 G0是每次启动一个M都会第一个创建的gourtine，G0仅用于负责调度的G，G0不指向任何可执行的函数，每个M都会有一个自己的G0。在调度或系统调用时会使用G0的栈空间，全局变量的G0是M0的G0；

避免频繁的创建、销毁线程，而是对线程的复用。

GOMAXPROCS设置P的数量，最多有GOMAXPROCS个线程分布在多个CPU上同时运行。GOMAXPROCS也限制了并发的程度，比如GOMAXPROCS = 核数/2，则最多利用了一般的CPU和进行并行。

在go版本1.2-1.13是基于协作的抢占式调度，只能依靠goroutine主动让出CPU资源才能触发调度，在1.14及以后的版本后，golang实现了基于信号的抢占式调度，一个goroutine最多占用 CPU 10ms，防止其他goroutine被饿死。

在新的调度器中依然有全局G队列，但功能被弱化了，当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G。

版本1.2~1.13,程序只能依靠Goroutine主动让出CPU资源才能触发调度。

问题：

在任何情况下，Go 运行时并行执行（注意，不是并发）的 goroutines 数量是小于等于 P 的数量的。为了提高系统的性能，P 的数量肯定不是越小越好，所以官方默认值就是 CPU 的核心数，设置的过小的话，如果一个持有 P 的 M， 由于 P 当前执行的 G 调用了 syscall 而导致 M 被阻塞，那么此时关键点： GO 的调度器是迟钝的，它很可能什么都没做，直到 M 阻塞了相当长时间以后，才会发现有一个 P/M 被 syscall 阻塞了。然后，才会用空闲的 M 来强这个P。通过 sysmon 监控实现的抢占式调度，最快在 20us，最慢在10-20ms才会发现有一个 M 持有 P 并阻塞了。操作系统在 1ms 内可以完成很多次线程调度（一般情况1ms 可以完成几十次线程调度），Go 发起 IO/syscall 的时候执行该 G 的 M会阻塞然后被 OS 调度走，P 什么也不干，sysmon 最慢要10-20ms才能发现这个阻塞，说不定那时候阻塞已经结束了，这样宝贵的 P 资源就这么被阻塞的M 浪费了。

Sysmon 有什么作用？

Sysmon 也叫监控线程，会变动的周期性检查

好处：