Go有四大核心模块，基本全部体现在runtime，有调度系统、GC、goroutine、channel，那么深入理解其中的精髓可以帮助我们理解Go这一门语言！
参考: 调度系统设计精要
下面是我用Go语言简单写的一个调度器，大家可以看看设计思路，以及存在的问题！
1、测试条件，调度器只启动两个线程，然后一个线程主要是负责循环的添加任务，一个线程循环的去执行任务
2、测试条件，调度器启动三个线程，然后两个线程去执行任务，一个添加任务
3、继续测试，启动十个线程，一个添加任务，九个执行任务
4、我们添加一些阻塞的任务
执行可以看到完全不可用
1、 可以看到随着M的不断的增加，可以发现执行任务的数量也不断的减少，原因是什么呢？有兴趣的同学可以加一个pprof可以看看，其实大量的在等待锁的过程！
2、如果我的M运行了类似于Sleep操作的方法如何解决了，我的调度器还能支撑这个量级的调度吗？
关于pprof如何使用：在代码头部加一个这个代码：
我们查看一下 go tool pprof main/prof.pporf
可以看到真正执行代码的时间只有 0.17s + 0.02s 其他时间都被阻塞掉了！
1、GM模型中的所有G都是放入到一个queue，那么导致所有的M取执行任务时都会去竞争锁，我们插入G也会去竞争锁，所以解决这种问题一般就是减少对单一资源的竞争，那就是桶化，其实就是每个线程都分配一个队列
2、GM模型中没有任务状态，只有runnable，假如任务遇到阻塞，完全可以把任务挂起再唤醒
这里其实会遇到一个问题，假如要分配很多个线程，那么此时随着线程的增加，也会造成队列的增加，其实也会造成调度器的压力，因为它需要遍历全部线程的队列去分配任务以及后续会讲到的窃取任务！
因为我们知道CPU的最大并行度其实取决于CPU的核数，也就是我们没必要为每个线程都去分配一个队列，因为就算是给他们分配了，他们自己去那执行调度，其实也会出现大量阻塞，原因就是CPU调度不过来这些线程！
Go里面是只分配了CPU个数的队列，这里就是P这个概念，你可以理解为P其实是真正的资源分配器，M很轻只是执行程序，所有的资源内存都维护在P上！M只有绑定P才能执行任务（强制的）！
这样做的好处：
1、首先调度程序其实就是调度不同状态的任务，go里面为Go标记了不同的状态，其实大概就是分为：runnable，running，block等，所以如何充分调度不同状态的G成了问题，那么关于阻塞的G如何解决，其实可以很好的解决G调度的问题！
上面这些情况其实就分为：
2、用户态阻塞，一般Go里面依靠 gopark 函数去实现，大体的代码逻辑基本上和go的调度绑定死了
源码在：https://golang.org/src/runtime/proc.go
3、其实对于netpool 这种nio模型，其实内核调用是非阻塞的，所以go开辟了一个网络轮训器队列，来存放这些被阻塞的g，等待内核被唤醒！那么什么时候会被唤醒了，其实就是需要等待调度器去调度了！
4、如果是内核态阻塞了（内核态阻塞一般都会将线程挂起，线程需要等待被唤醒），我们此时P只能放弃此线程的权利，然后再找一个新的线程去运行P！
关于着新线程：找有没有idle的线程，没有就会创建一个新的线程！
关于当内核被唤醒后的操作：因为GPM模型所以需要找到个P绑定，所以G会去尝试找一个可用的P，如果没有可用的P，G会标记为runnable放到全局队列中！
5、其实了解上面大致其实就了解了Go的基本调度模型
答案文章里慢慢品味！
如果某个 G 执行时间过长，其他的 G 如何才能被正常的调度？ 这便涉及到有关调度的两个理念：协作式调度与抢占式调度。协作式和抢占式这两个理念解释起来很简单： 协作式调度依靠被调度方主动弃权；抢占式调度则依靠调度器强制将被调度方被动中断。
例如下面的代码，我本地的版本是 go1.13.5
执行: GOMAXPROCS=1 配置全局只能有一个P
可以看到main函数无法执行!也就是那个go 空转抢占了整个程序
备注：
但是假如我换为用 1.14+版本执行，有兴趣的话可以使用我的docker镜像，直接可以拉取： fanhaodong/golang:1.15.11 和 fanhaodong/golang:1.13.5
首先我们知道G/M/P，G可能和M也可能和P解除绑定，那么关于数据变量放在哪哇！其实这个就是逃逸分析！
输出可以看到其实没有发生逃逸，那是因为 demo被拷贝它自己的栈空间内
备注：
-gcflags"-N -l -m" 其中 -N禁用优化-l禁止内联优化，-m打印逃逸信息
那么继续改成这个
可以看到发现 demo对象其实被逃逸到了堆上！这就是不会出现类似于G如果被别的M执行，其实不会出现内存分配位置的问题！
所以可以看到demo其实是copy到了堆上！这就是g逃逸的问题，和for循环一样的
执行可以发现，其实x已经逃逸到了堆上，所以你所有的g都引用的一个对象，如何解决了
如何解决了，其实很简单
也谈goroutine调度器
图解Go运行时调度器
Go语言回顾：从Go 1.0到Go 1.13
Go语言原本
调度系统设计精要
Scalable Go Scheduler Design Doc
NIO（非阻塞IO）是一种IO编程模型，Golang中的IO底层实现方式和java NIO模型一致，通俗点说就是都采用了EPOLL。 你在使用golang读文件的时候，goroutine 会默默的挂起，只是你不知道，当读完毕了，goroutine 再次恢复，但你不用担心，goroutine 的挂起和恢复没有java线程那样可怕，你可以认为goroutine 的挂起和恢复就是保存和恢复几个变量的值，其实也是这样的。剩下的就是goroutine 和 java线程的区别了，goroutine是用户态的线程切换，java采用的是系统线程切换，用汇编语言描述是一个(java)调用int 80软中断,一个没有。 意味着goroutine更轻量级，可以同时相应成千上万的线程切换，java你创造上千个线程就有些吃力了。
因为java线程不能创造过多的线程，如果同时处理上万上千的请求时候，就要考虑在几十个线程来处理上万上千的请求，这就出现了很多请求和线程不可能一一对应，所以通常做法是每个线程分别处理单个请求各个阶段。好比流水线，请求是要加工的商品，每个线程处理一道工序，这样做的好处是每人都做自己熟悉的，对于程序来说每个线程执行的代码永远都是自己很短的一块，这样根据局部优化原理，更具备CPU，内存亲和力，利于JIT。说这样多，就是说如果线程和请求不能一一对应，流水线式的并发编程很麻烦，阅读性也很差，通常是线程A里面一段逻辑代码，线程B又有另一处处理的逻辑代码。
由于goroutine 的轻便，你可以将请求和goroutine 一一对应起来，不用考虑将请求在线程之间换来换去，只关心你的业务逻辑，这就是goroutine 的好处。
总结：
golang的goroutine让你比java更容易编写并发程序，但性能不会有差别（目前来说，golang性能还不能和java比，看过代码就知道了，GC弱到爆），代码不会减少，该写的逻辑还得写。ps，其实golang的(sched)go程切换代码虽然原理和java的fork-join框架一样，但是fork-join比golang的sched代码牛逼不少，开始膜拜Doug Lea吧，golang还有很长的路要走。
![python中文字符串怎么定位啊，比如‘我爱中国’，，那么如果‘我爱中国’[2:3]不是“中国”两个字啊](/aiimages/python%E4%B8%AD%E6%96%87%E5%AD%97%E7%AC%A6%E4%B8%B2%E6%80%8E%E4%B9%88%E5%AE%9A%E4%BD%8D%E5%95%8A%EF%BC%8C%E6%AF%94%E5%A6%82%E2%80%98%E6%88%91%E7%88%B1%E4%B8%AD%E5%9B%BD%E2%80%99%EF%BC%8C%EF%BC%8C%E9%82%A3%E4%B9%88%E5%A6%82%E6%9E%9C%E2%80%98%E6%88%91%E7%88%B1%E4%B8%AD%E5%9B%BD%E2%80%99%5B2%3A3%5D%E4%B8%8D%E6%98%AF%E2%80%9C%E4%B8%AD%E5%9B%BD%E2%80%9D%E4%B8%A4%E4%B8%AA%E5%AD%97%E5%95%8A.png)
