目录
一、 Go的并发机制:线程模型
二、 Go的并发机制:goroutine、channel(待续)
最近在使用Golang开发一个项目,也是第一次使用Go,属于边学边用,刚开始使用觉得Go非常简洁易学,项目开发到阶段,需要用涉及到并发相关的知识了,如果是其他语言感觉没什么,多线程就完了。但是Go主打的就是它的并发机制,goroutine的名字在未使用Go的时候已经知道了。
由于我的项目是完全处于个人兴趣,没有人会催进度,所以我觉得在使用goroutine之前,还是需要学习一下,读懂里面的实现原理。而我们的需求是并发/并行,所以一切从它开始。
并发和并行
在讨论并发(Concurrent)的时候,必定会引出另一个概念,并行(parallel)。先发一张大神的图解:
![f404ab185d9cdfce803a2f693edd1449.png](https://i-blog.csdnimg.cn/blog_migrate/b76ed82c3a3236b780066e0bb4b03819.jpeg)
并发与并行
并发,两队人交替的使用一台咖啡机,而并行有两台咖啡机。就像我们平时写了多个任务,使用了多个线程去执行,这时候可以说你的程序是并发的,但是不一定是并行的,这取决于CPU是但和还是多核。
要了解Go并发机制,先要了解它的线程模型,在开始之前还是要熟悉一下有关线程的知识。
对于一个CPU来说,每时每刻都在为调度线程(或者说切换上下文)而忙碌,CPU有两个存放线程的队列,一个是存放等待运行的线程队列,另一个是正在运行的队列。调度器会被时间划分为很小的时间片段分配给线程,这样每个线程都可以在CPU上面运行,但是同一时间只能运行一个,如果线程因为一些原因而导致他进入睡眠状态,调度器会把它在队列移除,等待它被唤醒,就会重新加入到队列,继续执行。
一般的用户程序是无法直接来操作线程的,能操作线程的一般叫做系统调用,系统调用属于内核的一部分,出于系统的安全考虑,这和普通的程序调用是不一样的,可以说操作系统划分了用户空间和内核空间,当运行用户程序是,CPU出于用户空间,这时候它的身份是用户,只能访问用户空间的资源。
线程模型
正因为划分了两个割裂的空间,所以就分别有了内核线程和用户线程。用户线程再内核线程之上,这两种线程并不都是一对一的,在实现中,需要将用户线程根据不同的策略映射到内核线程,根据他们的映射关系不同可以分为下面三种线程模:
- 用户级线程模型
在此模型下,调度器可调度的最小单元就是 进程 ,所以内核线程不知道用户程序线程(后面统一叫用户线程)的存在,所以这些用户线程的管理由用户程序来完成,因此它们的切换速度也极快,由于进程下所有用户线程都只能对应同一内核线程,所以这种此模型有一个用户线程被阻塞(例如执行I/O操作),这个进程就会完全停下来,因为内核无法调度里面的用户线程,即使存在多个CPU,用户线程也无法分配给其他CPU执行,完全无法发挥出多核的优势,这种模型在现代的操作系统都已不再使用,由于看起来像是多个用户线程对应一个内核线程,所以这种模型也叫做(M:1)线程实现。 - 内核级线程模型
在此模型下的用户线程与内核线程一一对应,也就是说完全接管了用户线程,它也属于内核的一部分,统一由调度器来创建、终止和切换。这样就能完全发挥出多核的优势,多个线程可以跑在不同的CPU上,实现真正的并行。但也正由于一切都由内核来调度,这样大大增加了工作量,线程的切换是非常耗时的,而且创建也很用到更多的资源,所以也大大减少能创建线程的数量。由于是一对一的关系所以也叫(1:1)线程实现。 - 两层线程模型
或者叫混合线程模型(M:N),这种模型结合了以上两种的优点。同一个 进程 可以关联多个内核线程,这和内核级线程模型类似,不同的是用户线程与内核线程并不是一一对应关系,实现了此模型的线程库会将多个用户线程关联到一个内核线程上,当一个内核线程阻塞,可以通过线程库将部分用户线程再关联到其他的内核线程,由于允许多对多或一对一操作,所以也叫两层模型。这种设计增加了复杂性,因为管理线程的工作需要内核和用户线程库协同完成,但是也因为这后只能怪灵活的设计,使内核资源的消耗可以大大减少,同时也使线程调度效率提高(类似用户级线程模型)。这种模型的实现是要体现在语言层面的,例如Java,是否支持此模型取决于JVM的实现,当然其他两种模型也是可以支持。
![c332f4fb82ad544ddf8527462dcad10b.png](https://i-blog.csdnimg.cn/blog_migrate/00a9771476cf51df3bda6b07a9c72c98.jpeg)
三种线程模型实现
Go的线程模型
Go在内核线程之上, 搭建了一个特有的两层线程模型,这个特有的两层线程模型架构主要由G(goroutine)、M(machine)、P(processer)再加一个调度器(schedt)组成。简单的介绍它们的关系:M和P的存在,都是为了执行G,而我们写的支持并发的代码块,通过G的包裹,挂到一个P上,获得了执行所需的上下文环境。等待调度器将P于M关联,而M是和核心线程对应的,这样G就能被调度到内核线程上执行。
![357ecf78768633518aeda0d9a6889347.png](https://i-blog.csdnimg.cn/blog_migrate/2a579d79ca4c367fc50c8a7fcc518332.jpeg)
GMP关系图
上图实现表示关系是固定的,虚线表示不固定。M与核心线程是固定的,在它的生命周期内不会变更,而M与P,P与G关系都是可变。下面深入了解它们每一个独立个体,这部分内容时,我是同步阅读Go的源代码 https://github.com/golang/go.git
,这样更方便理解。
说到Go的运行时源代码,不得不提Go是实现了自举的语言, 它的运行时和编译器源代码也是用Go语言写的,我觉得自举的过程还是比较有趣的一起分享下:Go最早使用C语言编写它的编译器,然后使用Go编写了另一个程序,这个程序功能和前面的编译器一样,接着使用C语言写的编译器去编译这个程序,这样就得到了一个Go语言版本的编译器。当然实际没有说的这么简单,当中还要进行大量的测试和优化,这是个不错的想法,后面可以考虑写个demo试一试。
M(machine)
可以理解为一个M就对应一个内核线程。看到位于源码 runtime/runtime2.go 看下M的结构
type m struct { g0 *g // goroutine with scheduling stack mstartfn func() curg *g // current running goroutine p puintptr // attached p for executing go code (nil if not executing go code) nextp puintptr ... spinning bool // m is out of work and is actively looking for work}
M结构里有几十个字段,这里挑选相关的几个,字段 g0 :每个M都有一个特殊的gorountine,用于执行一些运行时任务,g0在源代码中也大量出现,它并不是由Go程序创建的,而是由Go的运行时系统初始化M的时候分配的。字段 mstartfn : M的起始函数,起始就是编写go语句携带的函数。字段 curg :保存当前M正在执行的那个G,字段 p :保存正在与当前M关联的P,字段 nextp :保存M与潜在关联的P,在某些情况下,运行时重新启动了M,这时候M会把这个的P关联在一起。字段 spinning :布尔类型,如果为真,表示当前M正在不停的到处去寻找可运行的G,直到找到为止,所以字段的名字才叫自旋(这部分内容下面会详细介绍)。M在创建的时候会被加入到一个运行时的全局列表( runtime.allm ),这样做是为了方便管理。M的数量是有限制的,限制数量的初始值是10000个,正因为它与内核线程一一对应,新建一个M就等于需要一个内核线程对应,一个线程需要分配的内存以MB为单位,况且用户程序是能使用用户空间的虚拟内存,所以基本上是不会达到这个值。
P(processer)
Go运行时的调度器会根据不同的情况,让P与不同的M进行关联,尽量使那些等待运行的G都有就会在M上运行。看下P的结构:
type p struct { ... status uint32 // one of pidle/prunning/... m muintptr // back-link to associated m (nil if idle) runq [256]guintptr // runnext, if non-nil, is a runnable G that was ready'd by // the current G and should be run next instead of what's in // runq if there's time remaining in the running G's time // slice. It will inherit the time left in the current time // slice. If a set of goroutines is locked in a // communicate-and-wait pattern, this schedules that set as a // unit and eliminates the (potentially large) scheduling // latency that otherwise arises from adding the ready'd // goroutines to the end of the run queue. runnext guintptr // Available G's (status == Gdead) gFree struct { gList n int32 } ...}
P结构的字段也有很多,这里也挑出几个,字段 m :表示与当前P关联的M,如果当前P是空闲的,此值为零值nil。字段 runq :当前P维护一个用于存放可运行的G的队列。字段 runnext :当前准备运行的G。字段 gFree :用于存放空闲的G的队列。可以看到P中有两个队列:可运行G和空闲G队列。当一个G初始化完成变得可运行后便会加入到P的 runq 队列,当前一个G运行完成后,就会放到 runnext 空闲队列中。在结构中不难看出,同一时间一个P只能关联一个M,这个关联关系是灵活变化的,受控于运行时的调度器。例如一个P已关联了一个M,取出队列的最新G正在运行,这时候G正在进行一些I/O操作阻塞,调度器会考虑将当前P与M分离,与其他空闲的M关联(如果没有空闲M则创建一个)。这种调度发生在Go运行时。和M一样,Go运行时也拥有一个P的列表,里面存放所有的P。
另外,调度器分别存放了空闲的M列表(schedt.midle)、空闲的P列表(schedt.pidle)和空闲的G列表(schedt.gFree),当一个P与M不再关联(可能是G已全部执行完毕,也可能是发生STW),运行时会把它放入空闲列表,等到需要新的P与M关联,再拿出来。至于schedt.gFree,上面介绍了已执行完的G存放在当前P的 gFree 空闲列表,当G存放到一定数量,调度器会把它移到调度器里的空闲G列表。
当前用户使用go去启动一个函数,运行时会从P的空闲G列表获取一个,如果没有,再尝试从调度器的空闲列表获取,都没有才会创建一个新的G。可以看出,Go的线程模型中,把一切的资源尽可能的复用来提升效率。
P的最大数量默认是CPU的核数,上限是256个。因为P中已经存放了一个G的队列,我猜是Go的开发者觉得可以满足需要,设置更多的P反而在运行时增加复杂性。
P结构还有一个字段 status 没介绍,表示P是有状态的, runtime2.go 文件中:
const ( // P status _Pidle = iota _Prunning _Psyscall _Pgcstop _Pdead)
- _Pidle:当前P处于空闲状态,没有与任何M关联。
- _Prunning:表示当前P与关联了一个M,需要注意的是关联意味着M拥有了当P,只有该M能修改P的状态。
- _Psyscall:当前P中运行的G正在进行系统调用(syscall)。
- _Pgcstop:表示进行STW(stop the world,运行时需要执行一些特殊的任务,需要停止调度器工作),需要停止调度。
- _Pdead:表示当前P已经不再使用,一个处于pdead状态的P,只有面临被释放掉资源的命运。
P的初始化函数源码 runtime/proc.go:func (pp *p) init(id int32) ,初始化时status值为 _Pgcstop ,初始化完成后,运行时会把它设置为 _Pidle ,放入到空闲列表,等待调用,与某个M关联后状态变为 _Prunning ,如果进入系统调用会转变为 _Psyscall ,等到调用完成状态又变为 _Pgcstop 。
G(goroutine)
Go编写一个段并发代码很简单:
go func() {fmt.Printf("go")}()
只要在普通的函数前面加一个 go 关键字,运行时就会按我们的要求,对函数进行并行执行(也许)。而运行时后面的底层逻辑从G、P、M、内核线程传递。除了G,其他的上面已经介绍。
goroutine与现有的线程、协程等概念并不一样,在这里我们可以理解为一个G,它是执行上面func函数的基础。
运行时遇到 go ,来到源代码 runtime/proc.go
func newproc(siz int32, fn *funcval) { argp := add(unsafe.Pointer(&fn), sys.PtrSize) gp := getg() pc := getcallerpc() systemstack(func() { newg := newproc1(fn, argp, siz, gp, pc) _p_ := getg().m.p.ptr() runqput(_p_, newg, true) if mainStarted { wakep() } })}
第二个参数是go后面的函数,接着调用了 getg() 函数,获取当前的G。继续往下主要逻辑在 newproc1(...) 实现。此函数先检查入参合法性,尝试从P的空闲列表获取一个G,如果没有再尝试从调度器的空闲列表获取,都没有就新创建一个G。对G进行初始化,并加入到运行时的全局G列表 runtime.allgs 。 go 后面的函数会被放在字段 g.startpc 。G还有一个字段 m 用于记录当前关联的M的指针。
G也一样是有状态的,挑选其中涉及到的一部分介绍:
const ( // G status _Gidle = iota // 0 _Grunnable // 1 _Grunning // 2 _Gsyscall // 3 _Gwaiting // 4 _Gmoribund_unused // 5 _Gdead // 6 ...)
- _Gidle:刚的到的G(新建或从空闲列表获取),尚未初始化的G。
- _Grunnable:一个已初始化并已加入P的等待运行队列,准备运行。
- _Grunning:表示当前G正在运行。
- _Gsyscall:表示当前G正在进行系统调用。
- _Gwaiting:表示当前G正在阻塞。
-_Gdead:表示G正处于闲置状态,例如G的函数执行完成。
G的状态会根据开发者编写的go函数变化,例如函数有I/O操作、time.sleep会导致进入 _Gwaiting 状态。当G进入 _Gdead 状态后,其实并不会真正死亡,它可以重新初始化被复用。
普通函数如果想要并发执行,就要穿上G这个个强大的外壳,加入到P的待执行队列,到达M,通过M由最终的内核来执行。
调度器(schedt)
调度器也是Go线程模型组成的重要部分,上面多次出现这个词,本篇如没特别说明,调度器是指Go运行时下的schedt,要和内核的调度器区分开来。不过两者在职责上基本相同。
首先看下调度器的结构体,位于源代码 runtime/runtime2.go :
type schedt struct { midle muintptr // idle m's waiting for work pidle puintptr // idle p's // Global cache of dead G's. gFree struct { lock mutex stack gList // Gs with stacks noStack gList // Gs without stacks n int32 }
上面也有提到过,调度器本身也是拥有G、P、M的空闲列表,这样可以提升调度效率。
![17134ea42e46610efe69b63c41f8e96b.png](https://i-blog.csdnimg.cn/blog_migrate/d072f7b5803d4e0153c8f90406dc2ccc.jpeg)
调度器一轮调用流程
调度器启动于 runtime.schedule() ,上图是调度器的一轮流程图,左边和右边的判断条件是当前M是否锁定了G,我们先来看左边的流程:其实现是在M中有个 lockedm 的字段,该字段保存一个G的指针。为什么要锁定G?出于某些原因,有些时候G中的代码需要在同一核心线程执行,由于M和内核线程是一对一不变,所以M锁定G即可。当前调度器遇到锁定G的情况,会调用 runtime.stoplockedm() 函数来停止M,当需要唤醒时,导调用``runtime.startlockedm()函数来继续执行:
// Stops execution of the current m that is locked to a g until the g is runnable again.// Returns with acquired P.func stoplockedm() { _g_ := getg() //判断当前M是否与G锁定 if _g_.m.lockedg == 0 || _g_.m.lockedg.ptr().lockedm.ptr() != _g_.m { throw("stoplockedm: inconsistent locking") } //接触当前M与P之间的关联 if _g_.m.p != 0 { // Schedule another M to run this p. _p_ := releasep() handoffp(_p_) } incidlelocked(1) // Wait until another thread schedules lockedg again. mPark() status := readgstatus(_g_.m.lockedg.ptr()) if status&^_Gscan != _Grunnable { print("runtime:stoplockedm: lockedg (atomicstatus=", status, ") is not Grunnable or Gscanrunnable") dumpgstatus(_g_.m.lockedg.ptr()) throw("stoplockedm: not runnable") } acquirep(_g_.m.nextp.ptr()) //停止当前M,等待被唤醒 _g_.m.nextp = 0}======= 唤醒M的代码`runtime.startlockedm()`=======// Schedules the locked m to run the locked gp.// May run during STW, so write barriers are not allowed.//go:nowritebarrierrec//参数gp表示被锁定的G,也就是与需要唤醒的M关联的Gfunc startlockedm(gp *g) { //当前G _g_ := getg() mp := gp.lockedm.ptr() if mp == _g_.m { throw("startlockedm: locked to me") } if mp.nextp != 0 { throw("startlockedm: m has p") } // directly handoff current P to the locked m incidlelocked(-1) //取消关联P,把P转给将要唤醒的M _p_ := releasep() mp.nextp.set(_p_) notewakeup(∓.park) //因为唤醒了与gp锁定的M,所以这里停止当前M stopm()}
接着继续看右边的M未锁定的流程,调度器会导出寻找可执行的G,实际上这也是调度器的日常工作。调度器首先会在P和全局列表获取,如果都没有,调用 runtime.findrunnable() 使M处于自旋的状态直到找到一个可执行的G,或者出现STW的情况导致调度器停止。
同一时刻只会出现一个M在自旋,而当找到一个可执行的G时,就会把这个G挂在自旋的M上。
调度器的工作远不止这些,要复杂的多,由于这里只是想写些初步的了解,就不全部记录了。
总结
Go为方便使用并发编程,提供了gorountie、select、channel的组合,这些是处于编程使用层面的,如果想深入去了解它的机制原理,就需要读懂它的线程模型,而它的模型框架实现是类似两层(混合)线程模型,所以也需要读懂内核的线程模型。