为什么在内核的线程调度器之外Go还需要一个自己的调度器?
- POSIX线程API是对已有的UNIX进程模型的逻辑扩展,因此线程和进程在很多方面都类似。例如,线程有自己的信号掩码,可以分配CPU affinity(进程要在某个给定的 CPU 上尽量长时间地运行而不被迁移到其他处理器的倾向性),可以放入 cgroups中,并且可以查询它们使用的资源。但是这些特性对于Go程序来说都是不必要的开销。
- 另外一个问题是基于Go语言模型,OS的调度决定并不一定合理。例如,Go的垃圾回收需要内存处于一致性的状态,这需要所有运行的线程都停止。垃圾回收的时间点是不确定的,如果仅由OS来调度,将会由大量的线程停止工作。单独开发一个Go的调度器能让我们知道什么时候内存处于一致性的状态。也就是说,当开始垃圾回收时,运行时只需要为当时正在CPU核上运行的那个线程等待即可,而不是等待所有的线程。
线程模型——高级语言对内核线程的封装实现
N:1模型,N个用户空间线程在1个内核空间线程上运行。优势是上下文切换非常快但是无法利用多核系统的优点。
1:1模型,1个内核空间线程运行一个用户空间线程。这种充分利用了多核系统的优势但是上下文切换非常慢,因为每一次调度都会在用户态和内核态之间切换。(POSIX线程模型(pthread),Java)
M:N模型, 每个用户线程对应多个内核空间线程,同时也可以一个内核空间线程对应多个用户空间线程。Go打算采用这种模型,使用任意个内核模型管理任意个goroutine。这样结合了以上两种模型的优点,但缺点就是调度的复杂性。
Golang的调度器实现
Go的调度器使用了三种结构:M,P,G
M代表内核线程,类似于标准的POSIX线程,M代表machine。
G代表goroutine,它拥有自己的栈,程序计数器(instruction counter)和一些关于goroutine调度的信息(如正在阻塞的channel)。
P代表processor,表示调度的上下文。可以把它看作是一个局部的调度器,让Go代码跑在一个单独的线程上。这是让Go从一个N:1调度器映射到一个M:N调度器的关键。
如上图所示,每个线程运行了一个goroutine,所以必须得维持一个上下文P。
上下文的数量由启动时环境变量$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。这样就能确保所有的线程都能以最大负荷运行。