前言:

前段 时间跟一个滴滴的小哥聊了关于golang饥饿调度的话题，似乎大家觉得golang不会出现太长时间饥饿。 虽然大家看过golang sysmon抢占的源码实现，但不确定实际运行的结果是否跟预想的一致。 什么是饥饿调度，就是长时间得不到调度器来调度运行,  长时间算多长？这个时间是个相对值。 这里主要测试go在 cpu密集 和 非cpu密集 下的调度器表现。 当然， go里面做cpu密集计算是有些反社会的，go社区里也不推荐这么使用go，应该没人这么干吧 ？

该文章后续仍在不断的更新修改中， 请移步到原文地址 xiaorui.cc/?p=5251

我们知道golang是善于做的是服务端开发，大家写的服务端程序或多或少会有这些 network io, channel, disk io, sleep 调用什么的。这些的操作都会导致M跟G的解绑，并且M重新的获取可用G的调度。golang很多的syscall调用之前也会做一些解绑操作。也就是说，golang在正常的场景下似乎很难出现 同一组 MPG 长时间绑定的情况。 另外，就算出现mpg长时间绑定运行，sysmon也会帮你做抢占，不管你是Psyscall, 还是Prunning状态。

sysmon retake() 是怎么抢占的？

起初runtime.main会创建一个额外的M运行sysmon函数, 抢占就是在sysmon中实现的. sysmon会进入一个无限循环, 第一轮回休眠20us, 之后每次休眠时间倍增,  最大不会超过10ms. sysmon中有netpool(获取fd事件), retake(抢占), forcegc(按时间强制执行gc), scavenge heap等处理. 这里只说 retake 抢占。
Sysmon会调用retake()函数，retake()函数会遍历所有的P，如果一个P处于Psyscall状态，会被调用handoffp来解绑MP关系。 如果处于Prunning执行状态，一直执行某个G且已经连续执行了 > 10ms的时间，就会被抢占。retake()调用preemptone()将P的stackguard0设为stackPreempt，这将导致该P中正在执行的G进行下一次函数调用时， 导致栈空间检查失败。进而触发morestack()然后进行一连串的函数调用，主要的调用过程如下：

# xiaorui.cc
 
morestack()（汇编代码）-> newstack() -> gopreempt_m() -> goschedImpl() -> schedule()

golang的PMG怎么可能会一直处于Prunning状态，一般来说只有cpu密集场景才会吧…. （废话）

测试一把cpu密集场景

我先写了一个看起来是协程调度饥饿的例子。 为了高度模拟cpu密集的场景，脚本的逻辑很简单，spawn了10w个协程，每个协程不断的在循环计数, 协程初次和结束都会做一个atomic计数，好让监控协程支持大家都有被调度到。 当监控协程检测到大家都有被触发时, 退出.

另外，runtime.GOMAXPROCS为什么设置为 3 ? 运行的阿里云机器是 4core,  procs设为3，在cpu密集场景下应该是cpu 300%. sysmon是在一个独立出一个M也就是线程去执行，这样避免了4个core下cpu 400%的情况下，在满荷载下ssh登陆都是个问题，导致无法进行其他操作。

# xiaorui.cc
 
package main
 
import (
	"fmt"
	// "net/http"
	"os"
	"runtime"
	"sync"
	"sync/atomic"
	"time"
)
 
var (
	startIncr int32
	endIncr   int32
)
 
const goCount = 100000
const plusCount = 10000
const callCount = 1000
 
func IncrCounter(num *int32) {
	atomic.AddInt32(num, 1)
}
 
func LoadCounter(num *int32) int32 {
	return atomic.LoadInt32(num)
}
 
func DecrCounter(num *int32) {
	atomic.AddInt32(num, -1)
}
 
func main() {
	runtime.GOMAXPROCS(3)
	var wg sync.WaitGroup
	startT := time.Now()
 
	go detect(&wg)
	for i := 0; i < goCount; i++ {
		wg.Add(1)
		go work(i, &wg)
	}
	wg.Wait()
	elapsed := time.Since(startT)
	fmt.Println("all exit, time cost: ", elapsed)
}
 
func detect(wg *sync.WaitGroup) {
	defer wg.Done()
 
	runtime.LockOSThread()
	defer runtime.UnlockOSThread()
	startT := time.Now()
	for {
		fmt.Println("time since: ", time.Since(startT))
		fmt.Println("start incr: ", LoadCounter(&startIncr))
		fmt.Println("end incr: ", LoadCounter(&endIncr))
		fmt.Println()
 
		if LoadCounter(&startIncr) == goCount && LoadCounter(&endIncr) == goCount {
			fmt.Println("finish detect")
			os.Exit(0)
			break
		}
		time.Sleep(1 * time.Millisecond)
	}
}
 
func work(gid int, wg *sync.WaitGroup) {
	defer wg.Done()
	var first = true
	var localCounter = 0
 
	for {
		if first == true {
			IncrCounter(&startIncr)
			// fmt.Printf("gid:%d#\n", gid)
		}
 
		for i := 0; i < plusCount; i++ {
			localCounter += 1
		}
 
		if first == true {
			IncrCounter(&endIncr)
			// fmt.Printf("gid:%d#\n", gid)
			first = false
		}
	}
}

我们先看下CPU使用情况，跟我们想象中的结果是一样的几乎到了cpu 300%

程序一直扔在tmux后台跑, 在等了两天之后，发现10w个协程中还有一些goroutine没有被调度到, 也就是说 程序一直还在运行着。 下面的截图是6个小时的cpu运行状态，因为监控系统存储误操作，清理了数据, 丢失了2天的图表。

为什么没有触发抢占?

为什么没有被触发？ golang runtime sysmon代码看起来是10ms会发生触发一次抢占请求,  当然，当M处于处于正在分配内存或者非抢占模式下或其他原因，可能会跳过这次抢占。 但，6个小时过去了，依然有一些协程没有被调度到，这是什么原因？

上面sysmon原理的时候有提过，retake会触发 morestack, 然后调用 newstack, 然后gopreempt_m会重置g的状态，扔到runq并且重新调度. 关键点是 morestack ? goroutine stack默认是2kb, 而然我们的goroutine被spawn之后，基本是自己玩自己的，没有调用其他的function, 那自然stack没啥变化了，所以说，没有发生抢占.  runtime代码有说，morestack — > newstack才会真的触发抢占，我们加上一些有层次的函数调用, 让stack扩充不就行了。

使用了递归调用栈来迅速扩充stack大小。经过测试，下面的代码 在 2分钟 内 1w个协程都会被调度到的。