go语言的任务调度 golang 调度( 六 )

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的调度绑定死了
源码在:
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

推荐阅读