Go并发编程系列(六)go并发机制之goroutine调度和goroutine阻塞-张柏沛IT博客

正文内容

Go并发编程系列(六)go并发机制之goroutine调度和goroutine阻塞

栏目:Go语言 系列:Go并发编程系列 发布时间:2021-02-05 12:07 浏览量:204

Go调度程序(Go调度器)

Go调度器本质上也是一个结构体。Go调度器并不是运行在某个专用内核线程中的程序,调度程序会运行在若干已存在的M(或者说内核线程)之中。换句话说,运行时系统中几乎所有的M都会参与调度任务的执行。

下面是这个结构体的几个比较重要的字段

 

字段名称

数据类型

用途简述

gcwaiting

uint32

表示是否需要因一些任务而停止调度

stopwait

int32

表示需要停止但仍未停止的P的数量

stopnote

note

用于实现与stopwait 相关的事件通知机制

sysmonwait

uint32

表示在停止调度期间系统监控任务是否在等待

sysmonnote

note

用于实现与sysmonwait 相关的事件通知机制

 

在这张表中的字段都与需要停止调度的任务有关。在Go运行时系统中,一些任务在执行前是需要暂停调度的,例如垃圾回收和发生panic。为了描述方便,我暂且把这类任务称为串行运行时任务。
字段gcwaiting 、stopwait 和stopnote 都是串行运行时任务执行前后的辅助协调手段。

 

Go的调度流程(一轮调度)

上图的过程描述了go程序从开启进程到G开始运行的过程,也就是调度器如何寻找可运行的G并开始运行G的过程。

 

在一轮调度的开始处,调度器会先判断当前M是否已被锁定。MG是可以成对地锁定在一起。我们已经知道,Go的调度器会按照一定策略动态地关联MPG(也就是说M可以运行不同P下的不同G),其优势就在于无需用户程序的任何干预。然而,在极少数的情况下,用户会需要把某个M和某个G锁定在一起,让这些G只能在这个M运行。

锁定MG的操作可以说是为CGO准备的。CGO代表了Go中的一种机制,是Go程序和C程序之间的一座桥梁。有些C语言的函数库(比如OpenGL)会用到线程本地存储技术。这些函数库会把一些数据存储在当前内核线程M的私有缓存中。因此,包含了调用此类C函数库的代码的G会变得特殊。它们在特定时期内只能与同一个M产生关联,否则就有可能丢失其存储在某个内核线程的私有缓存中的数据。我们可以通过调用runtime.LockOSThread 函数,把当前的G与当时运行它的那个M锁定在一起,也可以通过调用runtime.UnlockOSThread 函数解除当前G与某个M的锁定。一个M只能与一个G锁定。

 

当然MG的锁定问题不是重点,因为我们很少这样做。我们继续说一轮调度的流程:如果调度器判断当前M未与任何G锁定,那么一轮调度的主流程就会继续进行。这时,调度器会检查是否有运行时串行任务(即会导致暂停所有MG运行的任务)正在等待执行。这类任务在执行时需要停止Go调度器。官方称此种停止操作为“Stop the world,简称STW。一旦串行任务执行完成,该M就会被唤醒,一轮调度也会继续。

如果调度器在此关于锁定和运行时串行任务的判断都为假,就会开始真正的可运行G寻找之旅。一旦找到一个可运行的G,调度器就会在判定该G未与任何M锁定之后,立即让当前M运行它。

总的来说,一轮调度就是调度器让M找到G,并且运行这个G的过程。

一轮调度是Go调度器最核心的流程,在很多情况下都会被触发。例如,在用户进程刚启动时一轮调度流程会首次启动并使封装main函数的那个G被调度运行。又例如,某个G的运行的阻塞、结束、退出系统调用,以及其栈的增长,都会使调度器进行一轮调度。除此之外,用户程序对某些标准库函数的调用也会触发一轮调度流程。比如,runtime.Gosched 函数的调用会让当前的G暂停运行,并让出CPU给其他的G。这其中就有一轮调度流程的功劳。又比如,调用runtime.Goexit 函数会结束当前G的运行,也会进行一轮调度

 

 

全力查找可运行的G

这个是指调度器会为空闲的M去找可运行的G,让M把这些G运行起来,尽量不让M闲着。调度器会从各种G队列中和网络I/O轮询器中(存放着正在进行网络IOG容器)获取可运行的GM去运行,甚至还会进行工作窃取(本地M从其他PG队列偷取可运行的G来运行)。

go调度器需要查找可运行的G时可以调用runtime.findrunnable 函数,该函数会返回一个处于Grunnable 状态的G进行查找可运行G

调度器全力查找可运行的G的顺序是:先从本地P的可运行G队列和调度器的可运行G队列找,没有的话再从网络IO轮询器中找,还没有的话则从其他P的可运行G队列找(工作窃取),如果还找不到调度器就会停止当前的M。在之后的某个时刻,该M被唤醒之后,它会重新进入“全力查找可运行的G”的子流程

关于网络IO轮询器,我们需要知道当某一个G进行网络读写时,会进入一个等待状态(Gwaiting状态)并被放入到网络IO轮询器中并且多路复用器(如epoll或者kqueue)会监听这个G的读事件或写事件并在这个事件上绑定一个回调函数,而当这个G完成了读写操作时,就会触发事件上的回调函数从而将这个GGwaiting状态转为Grunnable的可运行状态。而调度器从网络IO轮询器获取可运行的G只需直接拿Grunnable状态的G即可。

如果某个M正在查找可运行的G(或者说是调度器通过某个M查找可运行的G),那么这个M所处的状态就是自旋状态,我们称之为自旋M,因为此时M既没有睡眠也没有在工作,而是在不停寻找G,这个过程是消耗CPU的,是cpu密集型操作。

如果一个M(我们称之为M1)始终没有找到可运行的G而休眠,其他M(称之为M2)在工作过程会顺便找到可运行的G,并在找到 时将之前睡眠的M唤醒。实际上M2是将自己预连的P转交给M1进行关联,让M1获取这个P中的G进行工作。 

 

这里需要说明的是,我们已知Go的网络请求接口全部使用的异步非阻塞的系统调用,因此G进行网络IO操作的时候是不会阻塞住内核线程M的,这意味着可以减少内核对内核线程M的上下文切换,和减少M的空闲时间。当然了,Go的网络读写其底层虽然是用的异步非阻塞的系统调用,但是Go把他们封装成类看似阻塞的方法提供给我们 使用。  

 

 

 

更多细节 

g0 m0

每个M都会拥有一个特殊的G,一般称为Mg0 g0 管辖的内存称为M的调度栈。可以说,Mg0 对应于操作系统为相应线程创建的栈。

g0 不是由“go 函数()”的方式生成的,而是由Go运行时系统在初始化M时创建的。g0 一般用于执行调度、垃圾回收、栈管理等方面的任务(因此其实调度器本质上就是g0)。顺便提一下,M还会拥有一个专用于处理信号的G,称为gsignal

除了g0 之外,其他由M运行的G都可以视作用户级别的G,简称用户G,而它们的g0 gsignal 都可以称为系统GGo运行时系统会进行切换,以使M都可以交替运行用户G和它的g0 g0  不会被阻塞,也不会包含在任何G队列或列表中。此外,它的栈也不会在垃圾回收期间被扫描。

除了每个M都有属于它自己的g0 之外,还存在一个runtime.g0runtime.g0用于执行引导程序(go程序初始化时运行的程序),它运行在Go程序拥有的第一个内核线程中,这个内核线程也称为runtime.m0runtime.m0g0 runtime.g0

其实main函数或者说main goroutine就是在runtime.m0上运行的。而执行到 go func1() 的时候,会创建或者复用一个G来封装这个func1且并发的运行func1

 

 

Go的垃圾回收

GoGC是基于CMSConcurrent Mark-Sweep,并发的标记-清扫)算法。调度器会自动在特定条件下执行垃圾回收(GC会在为Go程序分配的内存翻倍增长时被触发),系统监测任务在必要时也会进行强制GC。不

 

GC3种执行模式

gcBackgroundMode 。并发地执行垃圾收集(也可称标记)和清扫。

gcForceMode 。串行地执行垃圾收集(即执行时停止调度),但并发地执行清扫。

gcForceBlockMode 。串行地执行垃圾收集和清扫。

 

调度器驱使的自动GC和系统监测任务中的强制GC,都会以gcBackgroundMode 模式执行。但是,前者会检查Go程序当前的内存使用量,仅当使用增量过大时才真正执行GC。然而,后者会无视这个前提条件。

 

我们可以通过环境变量GODEBUG 控制自动GC的并发性。只要使其值包含gcstoptheworld=1 gcstoptheworld=2 ,就可以让GC的执行模式由gcBackgroundMode 变为gcForceMode gcForceBlockMode 。这相当于让并发的GC进入(易于)调试模式。

简单地讲,GC会在为Go程序分配的内存翻倍增长时被触发。

关闭自动GC就意味着我们要在程序中手动GC了,否则程序占用的内存即使不再使用也不会被回收。调用runtime.GC 函数可以手动触发一次GC,不过这个GC函数会阻塞调用方直到GC完成。这种情况下的GC会以gcForceBlockMode 模式执行。这里不再展开它的GC算法详情,感兴趣的读者可以自行查资料。

 

 

runtime包的一些控制goroutine的方法

runtime.GOMAXPROCS

设置运行时系统(runtime)P的最大数量。这样做会引起“Stop the world”,所以我强烈建议应用程序尽量早地,并且更好的方式是设置环境变量GOMAXPROCS 

 

runtime.Goexit 函数

调用runtime.Goexit 函数之后,会立即使当前goroutine的运行终止,而其他goroutine并不会受此影响。runtime.Goexit 函数在终止当前goroutine之前,会先执行该goroutine中所有还未执行的defer 语句。

该函数会把被终止的goroutine置于Gdead 状态,并将其放入本地P 的自由G列表,然后触发调度器的一轮调度流程。

请注意,千万不要在主goroutine中调用runtime.Goexit 函数,否则会引发panic

 

runtime.Gosched 函数

runtime.Gosched 函数的作用是暂停当前goroutine的运行(其实就是手动切换,从运行当前goroutine变为运行其他goroutine,也可以说是人为干预调度)。当前goroutine会被置为Grunnable 状态,并放入调度器的可运行G队列;这也是使用“暂停”这个词的原因。经过调度器的调度,该goroutine马上就会再次运行。

 

 

runtime.NumGoroutine 函数

runtime.NumGoroutine 函数在被调用后,会返回当前Go运行时系统中处于非Gdead 状态的用户G的数量。这些goroutine被视为“活跃的”或者“可被调度运行的”。该函数的返回值总会大于等于1 

   

runtime.LockOSThread 函数和runtime.UnlockOSThread 函数

对前者的调用会使当前goroutine与当前M锁定在一起,而对后者的调用则会解除这样的锁定。多次调用前者不会造成任何问题,但是只有最后一次调用会生效,可以想象成对同一个变量的多次赋值。另一方面,即使在之前没有调用过前者,对后者的调用也不会产生任何副作用。

  

runtime/debug.SetMaxStack 函数

runtime/debug.SetMaxStack 函数的功能是约束单个goroutine所能申请栈空间的最大size。已知,在main 函数及init 函数真正执行之前,主goroutine会对此数值进行默认设置。250 MB1 GB分别是在32位和64位的计算机系统下的默认值。

 

runtime/debug.SetMaxThreads 函数

runtime/debug.SetMaxThreads 函数的作用是对Go运行时系统所使用的内核线程的数量(也可以认为是M的数量)进行设置。在引导程序中,该数量被设置成了10 000。这对于操作系统和Go程序来说,都已经是一个足够大的值了。

如果调用此函数时给定的新值比运行时系统当前正在使用的M的数量还要小的话,就会引发一个panic。如果程序运行中M增长到大于M最大数量的设定,运行时系统就会发起一个同样的panic

  

在实际开发中,这些函数几乎不会被用到,而且也要少用。

  

最后需要提醒一点的是:

虽然G的创建和切换成本远小于M,但是也不意味着我们可以无限制的创建大量的G,因为大量的G创建会增加栈内存的占用和调度器负担加重,对内存和cpu的消耗都是我们需要考虑的。因此,即使是使用goroutine也要有意识的去限制其并发量不能过大。 

  

 

 

 

 

Goroutine阻塞(重点)

G阻塞分为以下4种情况:

1. 由于原子、互斥量或通道操作调用导致 Goroutine 阻塞

调度器将把当前阻塞的 Goroutine 切换出去(相当于调用了runtime.Goexit,把当前的goroutine从运行中的状态换成Grunnable状态并放入可运行G队列中),当前M会换其他的goroutine运行。

该情况的G阻塞不会阻塞内核线程M,因此不会导致M的上下文切换而只涉及到G的切换。

如下图:

 

如果G1是被chan阻塞住的话,情况会和上图中的有所不同,G1不会回到当前P的可运行G队列,而是被挂在了chan的recvq和sendq这两个队列中,我们将在下一节介绍chan通道的时候对此说明。

 

 

2. 由于网络请求和文件IO 操作导致 Goroutine 阻塞

之前说过go的网络IO其实用的是异步非阻塞的系统调用结合多路复用器的事件监听机制,所以当前G会由于IO事件未就绪而被切换,但是不会阻塞M。另外,Go的文件IO其实也是使用的异步的系统调用和多路复用的事件监听优化。

该情况的G阻塞不会阻塞内核线程M,因此不会导致M的上下文切换而只涉及到G的切换。

如下图:

3. 由于调用阻塞的系统调用时导致的goroutine阻塞

这种情况会导致当前M阻塞,内核会进行M的切换。而与当前M关联的当前P不会等待M的阻塞,因为这意味当前P下的所有G都无法执行,所以此时P会与当前M解除关联,转而关联到另一个内核线程M2,M2可能时新创建的内核线程,也可能时之前空闲的内核线程被唤醒来执行P的G
如下图:

 

4. 由于调用time.Sleep或者ticker计时器会导致Goroutine阻塞

这种情况和情况2相似,不会阻塞当前M。

 

如果您需要转载,可以点击下方按钮可以进行复制粘贴;本站博客文章为原创,请转载时注明以下信息

张柏沛IT技术博客 > Go并发编程系列(六)go并发机制之goroutine调度和goroutine阻塞

热门推荐
推荐新闻