GM模型是什么
在 Go 1.1版本之前，其实用的就是GM模型。
-
G，协程。通常在代码里用
go关键字执行一个方法，那么就等于起了一个G。 -
M，内核线程，操作系统内核其实看不见
G和P，只知道自己在执行一个线程。G和P都是在用户层上的实现。
除了G和M以外，还有一个全局协程队列，这个全局队列里放的是多个处于可运行状态的G。M如果想要获取G，就需要访问一个全局队列。同时，内核线程M是可以同时存在多个的，因此访问时还需要考虑并发安全问题。因此这个全局队列有一把全局的大锁，每次访问都需要去获取这把大锁。
并发量小的时候还好，当并发量大了，这把大锁，就成为了性能瓶颈。
GMP模型是什么
基于没有什么是加一个中间层不能解决的思路，golang在原有的GM模型的基础上加入了一个调度器P，可以简单理解为是在G和M中间加了个中间层。
于是就有了现在的GMP模型里。
-
P的加入，还带来了一个本地协程队列，跟前面提到的全局队列类似，也是用于存放G，想要获取等待运行的G，会优先从本地队列里拿，访问本地队列无需加锁。而全局协程队列依然是存在的，但是功能被弱化，不到万不得已是不会去全局队列里拿G的。 -
GM模型里M想要运行G，直接去全局队列里拿就行了；GMP模型里，M想要运行G，就得先获取P，然后从P的本地队列获取G。
-
新建
G时，新G会优先加入到P的本地队列；如果本地队列满了，则会把本地队列中一半的G移动到全局队列。 -
P的本地队列为空时，就从全局队列里去取。
- 如果全局队列为空时，
M会从其他P的本地队列偷（stealing）一半G放到自己P的本地队列。
M运行G，G执行之后，M会从P获取下一个G，不断重复下去。
为什么P的逻辑不直接加在M上
主要还是因为M其实是内核线程，内核只知道自己在跑线程，而golang的运行时（包括调度，垃圾回收等）其实都是用户空间里的逻辑。操作系统内核哪里还知道，也不需要知道用户空间的golang应用原来还有那么多花花肠子。这一切逻辑交给应用层自己去做就好，毕竟改内核线程的逻辑也不合适啊。
如果文章对你有帮助，看下文章底部右下角，做点正能量的事情（点两下）支持一下。（疯狂暗示，拜托拜托，这对我真的很重要！）
我是小白，我们下期见。