关于php:经典面试题你觉得-Go-在什么时候会抢占-P

7次阅读

共计 3623 个字符，预计需要花费 10 分钟才能阅读完成。

微信搜寻【脑子进煎鱼了】关注这一只爆肝煎鱼。本文 GitHub github.com/eddycjy/blog 已收录，有我的系列文章、材料和开源 Go 图书。

大家好，我是煎鱼。

前几天咱们有聊到《单核 CPU，开两个 Goroutine，其中一个死循环，会怎么样？》的问题，咱们在一个细节局部有提到：

有新的小伙伴会产生更多的疑难，那就是在 Go 语言中，是如何抢占 P 的呢，这外面是怎么做的？

明天这篇文章咱们就来解密抢占 P。

在 Go 语言中，Goroutine 晚期是没有设计成抢占式的，晚期 Goroutine 只有读写、被动让出、锁等操作时才会触发调度切换。

这样有一个重大的问题，就是垃圾回收器进行 STW 时，如果有一个 Goroutine 始终都在阻塞调用，垃圾回收器就会始终期待他，不晓得等到什么时候 …

这种状况下就须要抢占式调度来解决问题。如果一个 Goroutine 运行工夫过久，就须要进行抢占来解决。

这块 Go 语言在 Go1.2 起开始实现抢占式调度器，不断完善直至今日：

Go0.x：基于单线程的程调度器。
Go1.0：基于多线程的调度器。
Go1.1：基于工作窃取的调度器。
Go1.2 – Go1.13：基于合作的抢占式调度器。
Go1.14：基于信号的抢占式调度器。

调度器的新提案：非平均存储器拜访调度（Non-uniform memory access，NUMA），
但因为实现过于简单，优先级也不够高，因而迟迟未提上日程。

有趣味的小伙伴能够详见 Dmitry Vyukov, dvyukov 所提出的 NUMA-aware scheduler for Go。

为什么会要想去抢占 P 呢，说白了就是不抢，就没机会运行，会 hang 死。又或是资源分配不均了，

这在调度器设计中显然是不合理的。

跟这个例子一样：

// Main Goroutine 
func main() {
    // 模仿单核 CPU
    runtime.GOMAXPROCS(1)
    
    // 模仿 Goroutine 死循环
    go func() {for {}
    }()

    time.Sleep(time.Millisecond)
    fmt.Println("脑子进煎鱼了")
}

这个例子在老版本的 Go 语言中，就会始终阻塞，没法重见天日，是一个须要做抢占的场景。

但可能会有小伙伴问，抢占了，会不会有新问题。因为本来正在应用 P 的 M 就凉凉了（M 会与 P 进行绑定），没了 P 也就没法继续执行了。

这其实没有问题，因为该 Goroutine 曾经阻塞在了零碎调用上，临时是不会有后续的执行新诉求。

但万一代码是在运行了好一段时间后又可能运行了（业务上也容许长期待），也就是该 Goroutine 从阻塞状态中复原了，冀望持续运行，没了 P 怎么办？

这时候该 Goroutine 能够和其余 Goroutine 一样，先查看本身所在的 M 是否依然绑定着 P：

若是有 P，则能够调整状态，持续运行。
若是没有 P，能够从新抢 P，再占有并绑定 P，为本人所用。

也就是抢占 P，自身就是一个双向行为，你抢了我的 P，我也能够去抢他人的 P 来持续运行。

解说了为什么要抢占 P 的起因后，咱们进一步深挖，“他”是怎么抢占到具体的 P 的呢？

这就波及到前文所提到的 runtime.retake 办法了，其解决以下两种场景：

抢占阻塞在零碎调用上的 P。
抢占运行工夫过长的 G。

在此次要针对抢占 P 的场景，剖析如下：

func retake(now int64) uint32 {
    n := 0
    // 避免产生变更，对所有 P 加锁
    lock(&allpLock)
    // 走入主逻辑，对所有 P 开始循环解决
    for i := 0; i < len(allp); i++ {_p_ := allp[i]
        pd := &_p_.sysmontick
        s := _p_.status
        sysretake := false
        ...
        if s == _Psyscall {
            // 判断是否超过 1 个 sysmon tick 周期
            t := int64(_p_.syscalltick)
            if !sysretake && int64(pd.syscalltick) != t {pd.syscalltick = uint32(t)
                pd.syscallwhen = now
                continue
            }
      
            ...
        }
    }
    unlock(&allpLock)
    return uint32(n)
}

该办法会先对 allpLock 上锁，这个变量含意如其名，allpLock 能够避免该数组发生变化。

其会爱护 allp、idlepMask 和 timerpMask 属性的无 P 读取和大小变动，以及对 allp 的所有写入操作，能够防止影响后续的操作。

前置处理完毕后，进入主逻辑，会应用万能的 for 循环对所有的 P（allp）进行一个个解决。

            t := int64(_p_.syscalltick)
            if !sysretake && int64(pd.syscalltick) != t {pd.syscalltick = uint32(t)
                pd.syscallwhen = now
                continue
            }

第一个场景是：会对 syscalltick 进行断定，如果在零碎调用（syscall）中存在超过 1 个 sysmon tick 周期（至多 20us）的工作，则会从零碎调用中抢占 P，否则跳过。

如果未满足会持续往下，走到如下逻辑：

func retake(now int64) uint32 {for i := 0; i < len(allp); i++ {
        ...
        if s == _Psyscall {
            // 从此处开始剖析
            if runqempty(_p_) && 
      atomic.Load(&sched.nmspinning)+atomic.Load(&sched.npidle) > 0 && 
      pd.syscallwhen+10*1000*1000 > now {continue}
            ...
        }
    }
    unlock(&allpLock)
    return uint32(n)
}

第二个场景，聚焦到这一长串的判断中：

runqempty(_p_) == true 办法会判断工作队列 P 是否为空，以此来检测有没有其余工作须要执行。
atomic.Load(&sched.nmspinning)+atomic.Load(&sched.npidle) > 0 会判断是否存在闲暇 P 和正在进行调度窃取 G 的 P。
pd.syscallwhen+10*1000*1000 > now 会判断零碎调用工夫是否超过了 10ms。

这里奇怪的是 runqempty 办法明明曾经判断了没有其余工作，这就代表了没有工作须要执行，是不须要争夺 P 的。

但理论状况是，因为可能会阻止 sysmon 线程的深度睡眠，最终还是心愿持续占有 P。

在实现上述判断后，进入到争夺 P 的阶段：

func retake(now int64) uint32 {for i := 0; i < len(allp); i++ {
        ...
        if s == _Psyscall {
            // 承接上半局部
            unlock(&allpLock)
            incidlelocked(-1)
            if atomic.Cas(&_p_.status, s, _Pidle) {
                if trace.enabled {traceGoSysBlock(_p_)
                    traceProcStop(_p_)
                }
                n++
                _p_.syscalltick++
                handoffp(_p_)
            }
            incidlelocked(1)
            lock(&allpLock)
        }
    }
    unlock(&allpLock)
    return uint32(n)
}

解锁相干属性：须要调用 unlock 办法解锁 allpLock，从而实现获取 sched.lock，以便持续下一步。
缩小闲置 M：须要在原子操作（CAS）之前缩小闲置 M 的数量（假如有一个正在运行）。否则在产生争夺 M 时可能会退出零碎调用，递增 nmidle 并报告死锁事件。
批改 P 状态：调用 atomic.Cas 办法将所争夺的 P 状态设为 idle，以便于交于其余 M 应用。
争夺 P 和调控 M：调用 handoffp 办法从零碎调用或锁定的 M 中争夺 P，会由新的 M 接管这个 P。

至此实现了抢占 P 的根本流程，咱们可得出满足以下条件：

如果存在零碎调用超时：存在超过 1 个 sysmon tick 周期（至多 20us）的工作，则会从零碎调用中抢占 P。
如果没有闲暇的 P：所有的 P 都曾经与 M 绑定。须要抢占以后正处于零碎调用之，而实际上零碎调用并不需要的这个 P 的状况，会将其调配给其它 M 去调度其它 G。
如果 P 的运行队列外面有期待运行的 G，为了保障 P 的本地队列中的 G 失去及时调度。而本人自身的 P 又忙于零碎调用，得空治理。此时会寻找另外一个 M 来接管 P，从而实现持续调度 G 的目标。

若有任何疑难欢送评论区反馈和交换，最好的关系是相互成就 ，各位的点赞就是煎鱼创作的最大能源，感激反对。