go-GMP 协程切换时机 和 协程实战
当m在执行某个g的时候,g非常耗时,例如一个for循环,每次循环sleep1分钟,循环1000次。
这个例子看似无聊,却是很难解决的,成功的避开了2个系统切换时机。
如果这个时候,一直执行这个g,别的g就会得不到执行,例如有g是处理用户支付的,这样就会造成收钱不积极。
协程饥饿问题
本地队列
本地队列因为 某个G一直 占着M,导致其他G无法执行。
如果占用时间过长的这个G,能让出来M,让别的G也能执行,本地队列循环的着执行,就能解决这个问题。
全局队列
除了本地队列,全局队列也会有这个问题,如果一个新创建的g,放在全局队列中,而现有的p的本地队列都未执行完,则全局队列需要排队很久。
解决办法,每过一段时间,每个本地队列都先来全局队列中取1个,这样就能解决这个问题。
代码实现:
又到了findRunnable()
// Check the global runnable queue once in a while to ensure fairness.
if pp.schedtick%61 == 0 && sched.runqsize > 0 {
lock(&sched.lock)
gp := globrunqget(pp, 1)
unlock(&sched.lock)
if gp != nil {
return gp, false, false
}
}
这个优先级在 本地队列之前。之前看过 globrunqget()
中的逻辑,当max为1时候,就只会取一个。
每61次,就去全局队列中拿一个。
解决办法
协程因为独特的数据结构,能能够暂停的,之前协程的本质有介绍过,暂停后,让别的g也开始循环执行。
切换时机
主动挂起
业务方法主动调用gopark
然后,切换协程。
源码在proc.go中
// Puts the current goroutine into a waiting state and calls unlockf on the
// 让当前的 g 进入 waiting的状态
func gopark(unlockf func(*g, unsafe.Pointer) bool, lock unsafe.Pointer, reason waitReason, traceReason traceBlockReason, traceskip int) {
if reason != waitReasonSleep {
checkTimeouts() // timeouts may expire while two goroutines keep the scheduler busy
}
mp := acquirem()
gp := mp.curg
status := readgstatus(gp)
if status != _Grunning && status != _Gscanrunning {
throw("gopark: bad g status")
}
mp.waitlock = lock
mp.waitunlockf = unlockf
gp.waitreason = reason
mp.waitTraceBlockReason = traceReason
mp.waitTraceSkip = traceskip
releasem(mp)
// can't do anything that might move the G between Ms here.
mcall(park_m) // 切换到了 g0栈,前面讲过mcall
}
// park continuation on g0.
func park_m(gp *g) {
mp := getg().m
// 中间还有代码
if fn := mp.waitunlockf; fn != nil {
ok := fn(gp, mp.waitlock)
mp.waitunlockf = nil
mp.waitlock = nil
if !ok {
if traceEnabled() {
traceGoUnpark(gp, 2)
}
casgstatus(gp, _Gwaiting, _Grunnable)
execute(gp, true) // Schedule it back, never returns.
}
}
schedule() //调了这个方法,之前讲过,一旦调用这个方法,就会给m找新的g
}
有个问题:gapark是小写的,程序员在编码中是使用不了的,那怎么让业务主动调用?
系统runtime里面很多方法有去调用,例如
time.Sleep、channel的等待等
系统调用完成时
在进行一些系统调用后,例如网络请求等会主动去调这个 exitsyscall()
这个方法,这个方法也会最终走到 schedule()
这个源码在 syscall_aix.go中,因为有好几层函数调用,就不贴出来了。
标记抢占 基于 morestack
1. 系统监控到 Goroutine 运行超过 10ms
2. 将 g.stackguard0 置为 Oxfffffade
morestack() 方法,在函数跳转时候,会自动调用,本意是检测下新的函数,有没有足够的栈空间。
系统在这个函数中,去做了一部分协程切换的,防止一些 耗时比较久的协程,不去触发上面两种方案。
看下源码:
// Called during function prolog when more stack is needed.
// record an argument size. For that purpose, it has no arguments.
TEXT runtime·morestack(SB),NOSPLIT,$0-0
// 中间很多扩充栈空间的代码
CALL runtime·newstack(SB) // 跟进这个方法
CALL runtime·abort(SB) // crash if newstack returns
RET
// Goroutine preemption request.
// 0xfffffade in hex.
stackPreempt = uintptrMask & -1314
func newstack() {
// 中间还有很多源码
// 抢占标记 如果g的.stackguard0 字段被标记为抢占,就会触发下面的逻辑
stackguard0 := atomic.Loaduintptr(&gp.stackguard0)
preempt := stackguard0 == stackPreempt
if preempt {
// Act like goroutine called runtime.Gosched.
gopreempt_m(gp) // never return
}
}
func gopreempt_m(gp *g) {
if traceEnabled() {
traceGoPreempt()
}
goschedImpl(gp)
}
func goschedImpl(gp *g) {
//删了一些源码,最终调了 schedule
schedule()
}
基于信号的抢占标记
开头那个 for 循环的例子,虽然很无聊,但是去避开了上面那种方案,
1. 不会调用 gopark
2. 不会系统调用
3.不会调用 morestack,因为没有函数调用
这时候,可以使用 信号 来触发协程的切换。
信号量可以在多线程和多进程直接进行通信(管道、共享内存、信号、消息队列一般作为多进程通信方式)。
原理:
操作系统中,有很多基于信号的底层通信方式,例如: SIGPIPE / SIGURG / SIGHUP
线程可以注册对应信号的处理函数
go的实现流程:
注册 `SIGURG`信号的处理函数
`GC`工作时,向目标线程发送信号
线程收到信号,触发调度,`gc`发送 `sigurg` 触发`runtime`的 `doSigPreempt()`
能够猜到 doSigPreempt()
, 最终会去调 schedule()
方法。 源码就不贴了。
开发中,协程过多的问题
1. 文件打开数限制
过多协程调用文件读写,会操作系统崩溃。
2. 内存限制
过多协程创建,达到了内存的限制
3. 调度开销过大
过多协程,导致调度器调度复杂度增大
解决办法:
1. 优化业务逻辑
2. 利用 channel 的缓存区
3. 协程池
4. 调整系统资源
2和3都是从控制协程的数量入手,2适合 单个业务场景,3适合全局。
1和4好理解
利用 channel 的缓存区
func do(c chan interface{}) {
fmt.Println("do it")
<-c
}
func main() {
// 利用channel的特性来控制 go协程的个数
ch := make(chan interface{}, 100)
for {
ch <- struct{}{}
go do(ch)
}
}
这种适合在一个场景下适用,不推荐全局使用。
协程池
代表:https://github.com/Jeffail/tunny
原理:类似某些语言的线程池
1.预创建一定数量的协程
2.将任务送入协程池队列
3.协程池不断取出可用协程,执行任务
慎用协程池
Go语言的线程,已经相当于池化了
二级池化会增加系统复杂度
Go语言的初衷是希望协程即用即毁,不要池化
到此,go的GMP完结。
热门相关:全系灵师:魔帝嗜宠兽神妃 染指帝国首席:老公,别闹 婚期一年 试婚100天:夜少,宠上瘾 宝贝迷人,总裁圈住爱