ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Golang调度器

2021-09-27 09:32:05  阅读:118  来源: 互联网

标签:runqueue goroutine 调度 Golang 线程 内核 Go


为什么在内核的线程调度器之外Go还需要一个自己的调度器?

  1. POSIX线程API是对已有的UNIX进程模型的逻辑扩展,因此线程和进程在很多方面都类似。例如,线程有自己的信号掩码,可以分配CPU affinity(进程要在某个给定的 CPU 上尽量长时间地运行而不被迁移到其他处理器的倾向性),可以放入 cgroups中,并且可以查询它们使用的资源。但是这些特性对于Go程序来说都是不必要的开销。
  2. 另外一个问题是基于Go语言模型,OS的调度决定并不一定合理。例如,Go的垃圾回收需要内存处于一致性的状态,这需要所有运行的线程都停止。垃圾回收的时间点是不确定的,如果仅由OS来调度,将会由大量的线程停止工作。单独开发一个Go的调度器能让我们知道什么时候内存处于一致性的状态。也就是说,当开始垃圾回收时,运行时只需要为当时正在CPU核上运行的那个线程等待即可,而不是等待所有的线程。

线程模型——高级语言对内核线程的封装实现

N:1模型,N个用户空间线程在1个内核空间线程上运行。优势是上下文切换非常快但是无法利用多核系统的优点。
1:1模型,1个内核空间线程运行一个用户空间线程。这种充分利用了多核系统的优势但是上下文切换非常慢,因为每一次调度都会在用户态和内核态之间切换。(POSIX线程模型(pthread),Java)
M:N模型, 每个用户线程对应多个内核空间线程,同时也可以一个内核空间线程对应多个用户空间线程。Go打算采用这种模型,使用任意个内核模型管理任意个goroutine。这样结合了以上两种模型的优点,但缺点就是调度的复杂性。

Golang的调度器实现

Go的调度器使用了三种结构:M,P,S

M代表内核线程,类似于标准的POSIX线程,M代表machine。
G代表goroutine,它拥有自己的栈,程序计数器(instruction counter)和一些关于goroutine调度的信息(如正在阻塞的channel)。
P代表processor,表示调度的上下文。可以把它看作是一个局部的调度器,让Go代码跑在一个单独的线程上。这是让Go从一个N:1调度器映射到一个M:N调度器的关键。
在这里插入图片描述

如上图所示,每个线程运行了一个goroutine,所以必须得维持一个上下文P。

上下文的数量由启动时环境变量 G O M A X P R O C S 或 者 是 由 r u n t i m e 的 方 法 G O M A X P R O C S ( ) 决 定 ( 默 认 值 为 1 ) 。 这 意 味 着 在 程 序 执 行 的 任 意 时 刻 都 只 有 GOMAXPROCS或者是由runtime的方法GOMAXPROCS()决定(默认值为1)。这意味着在程序执行的任意时刻都只有 GOMAXPROCS或者是由runtime的方法GOMAXPROCS()决定(默认值为1)。这意味着在程序执行的任意时刻都只有GOMAXPROCS个goroutine在同时运行。

灰色的goroutine没有在运行,等待被调度。它们被维护在一个队列(runqueues)里。当一个go语句执行,就将一个新的goroutine添加到队列尾;当运行当前goroutine到调度点时,就从队列中弹出一个新的goroutine。

每一个context拥有一个局部的runqueue。之前版本的Go调度器只有一个全局的带有互斥锁的runqueue,这样线程经常被阻塞等待其它线程解锁,在多核机器上性能表现及其差。

之所以要维护多个context,是因为当一个OS线程被阻塞时,我们可以把contex移到其它的线程中去。
在这里插入图片描述

如上图所示,当一个内核线程M0要被阻塞时,P将会去M1上继续运行。Go的调度器保证了拥有足够的线程跑所有的contexts。因为还有在执行的goroutine,M0会暂时挂起。当syscall返回时,M0会尝试获取一个context来运行G0。一般情况下,它会从其它内核线程偷一个过来。如果没有偷到,它会把G0放到一个全局的runqueue内,将自己放回线程池,进入睡眠状态。

当contexts运行完所有的本地runqueue时,它会从全局runqueue拉取goroutine。contexts也会周期性检查全局runqueue是否存在goroutine,以防止全局runqueue中的goroutine饿死。

这就是为什么Go程序多线程运行的原因,即使GOMAXPROCS只有1。
在这里插入图片描述

另外一种情况就是某个context的goroutine运行完了,全局runqueue也没有了goroutine,而其它context还有大量goroutine需要运行。这时候就需要从其它的地方获取goroutine。如图所示,context会尝试从其它context的runqueue里面偷一半的goroutine。这样就能确保所有的线程都能以最大负荷运行。

标签:runqueue,goroutine,调度,Golang,线程,内核,Go
来源: https://blog.csdn.net/kwinH/article/details/120501628

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有