Go语言goroutine并发模型

简介

stack

OS线程初始栈为2MB。Go语言中,每个goroutine采用动态扩容方式,初始2KB,按需增长,最大1G。此外GC会收缩栈空间。
BTW,增长扩容都是有代价的,需要copy数据到新的stack,所以初始2KB可能有些性能问题。
更多关于stack的内容,可以参见大佬的文章。聊一聊goroutine stack

管理

用户线程的调度以及生命周期管理都是用户层面,Go语言自己实现的,不借助OS系统调用,减少系统资源消耗。

G-M-P

Go语言采用两级线程模型,即用户线程与内核线程KSE(kernel scheduling entity)是M:N的。最终goroutine还是会交给OS线程执行,但是需要一个中介,提供上下文。这就是G-M-P模型

  • G: goroutine, 类似进程控制块,保存栈,状态,id,函数等信息。G只有绑定到P才可以被调度。
  • M: machine, OS线程,绑定有效的P之后,进入调度。
  • P: 逻辑处理器,保存各种队列G。对于G而言,P就是cpu core。对于M而言,P就是上下文。P的数量由GOMAXPROCS设置,最大256。
  • sched: 调度程序,保存GRQ,midle M空闲队列,pidle P空闲队列以及lock等信息

在这里插入图片描述

队列

Go调度器有两个不同的运行队列:

  • GRQ,全局运行队列,尚未分配给P的G
  • LRQ,本地运行队列,每个P都有一个LRQ,用于管理分配给P执行的G

状态

go1.10\src\runtime\runtime2.go
  • _Gidle: 分配了G,但是没有初始化
  • _Grunnable: 在run queue运行队列中,LRQ或者GRQ
  • _Grunning: 正在运行指令,有自己的stack。不在runq运行队列中,分配给M和P
  • _Gsyscall: 正在执行syscall,而非用户指令,不在runq,分给M,P给找idle的M
  • _Gwaiting: block。不在RQ,但是可能会在channel的wait queue等待队列
  • _Gdead: unused。在P的gfree list中,不在runq。idle闲置状态
  • _Gcopystack: stack扩容或者gc收缩

上下文切换

Go调度器根据事件进行上下文切换。

  • go关键字,创建goroutine
  • gc垃圾回收,gc也是goroutine,所以需要时间片
  • system call系统调用,block当前G
  • sync同步,block当前G

调度

调度的目的就是防止M堵塞,空闲,系统进程切换。
详见 Golang - 调度剖析【第二部分】

异步调用

Linux可以通过epoll实现网络调用,统称网络轮询器N(Net Poller)。

  1. G1在M上运行,P的LRQ有其他3个G,N空闲;
  2. G1进行网络IO,因此被移动到N,M继续从LRQ取其他的G执行。比如G2就被上下文切换到M上;
  3. G1结束网络请求,收到响应,G1被移回LRQ,等待切换到M执行。

同步调用

文件IO操作

  1. G1在M1上运行,P的LRQ有其他3个G;
  2. G1进行同步调用,堵塞M;
  3. 调度器将M1与P分离,此时M1下只有G1,没有P。
  4. 将P与空闲M2绑定,并从LRQ选择G2切换
  5. G1结束堵塞操作,移回LRQ。M1空闲备用。

任务窃取

上面都是防止M堵塞,任务窃取是防止M空闲

  1. 两个P,P1,P2
  2. 如果P1的G都执行完了,LRQ空,P1就开始任务窃取。
  3. 第一种情况,P2 LRQ还有G,则P1从P2窃取了LRQ中一半的G
  4. 第二种情况,P2也没有LRQ,P1从GRQ窃取。

g0

每个M都有一个特殊的G,g0。用于执行调度,gc,栈管理等任务,所以g0的栈称为调度栈。g0的栈不会自动增长,不会被gc,来自os线程的栈。

code

go1.10\src\runtime\proc.go

new

// The minimum size of stack used by Go code
    var _StackMin = 2048

func newproc1(fn *funcval, argp *uint8, narg int32, callerpc uintptr) {
    _g_ := getg()
    _p_ := _g_.m.p.ptr()
    
    newg := gfget(_p_)
    if newg == nil {
        newg = malg(_StackMin)
    }    
    
    newg.startpc = fn.fn
    
    runqput(_p_, newg, true)
    
    if atomic.Load(&sched.npidle) != 0 && atomic.Load(&sched.nmspinning) == 0 && mainStarted {
        wakep()
    }
}
  1. 获取当前G
  2. 获取当前G的P
  3. 从P的gfree中获取G,避免重新创建,有点池化的意思
  4. 如果没有可复用的G,就重新创建,参数表示stack大小,起始2KB,支持动态扩容
  5. 将G入队,放入P的LRQ中;由于有工作窃取机制,其他P可以从这个P窃取G
  6. 如果runq满了(长度256),就放入GRQ中,在sched中
  7. 尝试加入额外的P去执行G

start

G没办法自己运行,必须通过M运行

func mstart() {
    mstart1(0)
    
    mexit(osStack)
}

func mstart1(dummy int32) {
    _g_ := getg()

    if _g_ != _g_.m.g0 {
        throw("bad runtime·mstart")
    }    
    
    schedule()    
}

M通过通过调度,执行G

schdule

// One round of scheduler: find a runnable goroutine and execute it.
// Never returns.
func schedule() {
    _g_ := getg()
    
    var gp *g
    
    gp, inheritTime = runqget(_g_.m.p.ptr())
    
    execute(gp, inheritTime)
}

参考

Goroutine并发调度模型深度解析&手撸一个协程池
Golang 的 goroutine 是如何实现的?
Golang - 调度剖析【第二部分】

发布了158 篇原创文章 · 获赞 119 · 访问量 81万+

猜你喜欢

转载自blog.csdn.net/u013474436/article/details/103824154