关于golang:Go-面试官GMP-模型为什么要有-P

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

大家好，我是煎鱼。

最近金三银四，是面试的节令。在我的 Go 读者交换群里呈现了许多小伙伴在探讨本人面试过程中所遇到的一些 Go 面试题。

明天的配角，是 Go 面试的万能题 GMP 模型的延长题（疑难），那就是”GMP 模型，为什么要有 P？“

进一步斟酌问题的背地，其实这个面试题实质是想问：”GMP 模型，为什么不是 G 和 M 间接绑定就完了，还要搞多一个 P 进去，那么麻烦，为的是什么，是要解决什么问题吗？“

这篇文章煎鱼就带你一起摸索，GM、GMP 模型的变迁是因为什么起因。

在 Go1.1 之前 Go 的调度模型其实就是 GM 模型，也就是没有 P。

明天带大家一起回顾过去的设计。

咱们理解一个货色的方法之一就是看源码，和煎鱼一起看看 Go1.0.1 的调度器源码的外围关键步骤：

static void
schedule(G *gp)
{
    ...
    schedlock();
    if(gp != nil) {
        ...
        switch(gp->status){
        case Grunnable:
        case Gdead:
            // Shouldn't have been running!
            runtime·throw("bad gp->status in sched");
        case Grunning:
            gp->status = Grunnable;
            gput(gp);
            break;
        }

    gp = nextgandunlock();
    gp->readyonstop = 0;
    gp->status = Grunning;
    m->curg = gp;
    gp->m = m;
    ...
    runtime·gogo(&gp->sched, 0);
}

调用 schedlock 办法来获取全局锁。
获取全局锁胜利后，将以后 Goroutine 状态从 Running（正在被调度）状态批改为 Runnable（能够被调度）状态。
调用 gput 办法来保留以后 Goroutine 的运行状态等信息，以便于后续的应用；
调用 nextgandunlock 办法来寻找下一个可运行 Goroutine，并且开释全局锁给其余调度应用。
获取到下一个待运行的 Goroutine 后，将其的运行状态批改为 Running。
调用 runtime·gogo 办法，将刚刚所获取到的下一个待执行的 Goroutine 运行起来。

通过对 Go1.0.1 的调度器源码分析，咱们能够发现一个比拟乏味的点。那就是调度器自身（schedule 办法），在失常流程下，是不会返回的，也就是不会完结主流程。

他会一直地运行调度流程，GoroutineA 实现了，就开始寻找 GoroutineB，寻找到 B 了，就把曾经实现的 A 的调度权交给 B，让 GoroutineB 开始被调度，也就是运行。

当然了，也有被正在阻塞（Blocked）的 G。假如 G 正在做一些零碎、网络调用，那么就会导致 G 停滞。这时候 M（零碎线程）就会被会从新放内核队列中，期待新的一轮唤醒。

这么外表的看起来，GM 模型仿佛颠扑不破，毫无缺点。但为什么要改呢？

在 2012 年时 Dmitry Vyukov 发表了文章《Scalable Go Scheduler Design Doc》，目前也仍然成为各大钻研 Go 调度器文章的次要对象，其在文章内讲述了整体的起因和思考，下述内容将援用该文章。

以后（代指 Go1.0 的 GM 模型）的 Goroutine 调度器限度了用 Go 编写的并发程序的可扩展性，尤其是高吞吐量服务器和并行计算程序。

实现有如下的问题：

存在繁多的全局 mutex（Sched.Lock）和集中状态治理：
- mutex 须要爱护所有与 goroutine 相干的操作（创立、实现、重排等），导致锁竞争重大。
Goroutine 传递的问题：
- goroutine（G）交接（G.nextg）：工作者线程（M’s）之间会常常交接可运行的 goroutine。
- 上述可能会导致提早减少和额定的开销。每个 M 必须可能执行任何可运行的 G，特地是刚刚创立 G 的 M。
每个 M 都须要做内存缓存（M.mcache）：
- 会导致资源耗费过大（每个 mcache 能够吸纳到 2M 的内存缓存和其余缓存），数据局部性差。
频繁的线程阻塞 / 解阻塞：
- 在存在 syscalls 的状况下，线程常常被阻塞和解阻塞。这减少了很多额定的性能开销。

为了解决 GM 模型的以上诸多问题，在 Go1.1 时，Dmitry Vyukov 在 GM 模型的根底上，新增了一个 P（Processor）组件。并且实现了 Work Stealing 算法来解决一些新产生的问题。

GMP 模型，在上一篇文章《Go 群友发问：Goroutine 数量管制在多少适合，会影响 GC 和调度？》中曾经解说过了。

感觉不错的小伙伴能够关注一下，这里就不再复述了。

加了 P 之后会带来什么扭转呢？咱们再更显式的讲一下。

每个 P 有本人的本地队列，大幅度的加重了对全局队列的间接依赖，所带来的成果就是锁竞争的缩小。而 GM 模型的性能开销大头就是锁竞争。
每个 P 绝对的均衡上，在 GMP 模型中也实现了 Work Stealing 算法，如果 P 的本地队列为空，则会从全局队列或其余 P 的本地队列中窃取可运行的 G 来运行，缩小空转，进步了资源利用率。

这时候就有小伙伴会纳闷了，如果是想实现本地队列、Work Stealing 算法，那为什么不间接在 M 上加呢，M 也照样能够实现相似的组件。为什么又再加多一个 P 组件？

联合 M（零碎线程）的定位来看，若这么做，有以下问题：

一般来讲，M 的数量都会多于 P。像在 Go 中，M 的数量默认是 10000，P 的默认数量的 CPU 核数。另外因为 M 的属性，也就是如果存在零碎阻塞调用，阻塞了 M，又不够用的状况下，M 会一直减少。
M 一直减少的话，如果本地队列挂载在 M 上，那就意味着本地队列也会随之减少。这显然是不合理的，因为本地队列的治理会变得复杂，且 Work Stealing 性能会大幅度降落。
M 被零碎调用阻塞后，咱们是冀望把他既有未执行的任务分配给其余持续运行的，而不是一阻塞就导致全副进行。

因而应用 M 是不合理的，那么引入新的组件 P，把本地队列关联到 P 上，就能很好的解决这个问题。

明天这篇文章联合了整个 Go 语言调度器的一些历史状况、起因剖析以及解决方案阐明。

”GMP 模型，为什么要有 P“这个问题就像是一道零碎设计理解，因为当初很多人为了应答面试，会硬背 GMP 模型，或者是泡面式过了一遍。而了解其中真正背地的起因，才是咱们要去学的要去了解。

知其然知其所以然，才可破局。

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

文章继续更新，能够微信搜【脑子进煎鱼了】浏览，回复【000】有我筹备的一线大厂面试算法题解和材料；本文 GitHub github.com/eddycjy/blog 已收录，欢送 Star 催更。

关于golang:Go-面试官GMP-模型为什么要有-P

GM 模型

解密 Go1.0 源码

思考 GM 模型

GM 模型的毛病

GMP 模型

带来什么扭转

为什么要有 P

总结