浅谈go协程及其调度模型

迷南。 2023-07-06 14:36 3阅读 0赞

每当我看着大海的时候，我总想找人谈谈。但当我和人交谈时，我又总想去看看大海。                                                                                                                                                      —— 村上春树

**go并发之美·干货好文合集：**

[go并发之美·redis篇·接口幂等性设计实现][go_redis]

[go并发之美·redis篇·实现实时排行榜][go_redis 1]

[go并发日记·多goroutine并发安全的操作共享变量][go_goroutine]

[go并发日记·常用并发场景中的并发控制思路与方案][go]

[go并发日记·避免goroutine泄漏/实现协程可控][go_goroutine 1]

[go并发日记·深入理解go语言channel与goroutine阻塞][go_go_channel_goroutine]

[go并发日记·基于channel优雅的进行并发控制][go_channel]

[go并发日记·WaitGroup并发控制探索及实际场景运用][go_WaitGroup]

[channel死锁的情况分析][channel]

[go并发之美·B操作伴随A操作(B和A同步)][go_B_A_B_A]

[go多函数并发通用工具的设计与实现][go 1]

go在语言层面对协程进行了原生的支持并且称为goroutine，这也是go语言强大并发能力的重要支撑。

> 本文并非一蹴而就，而是蓄势待发已久。后续随着知识及理解的不断深入仍将持续补充进来。同时也欢迎各位留言探讨，互相学习。

**目录**

进程、线程、协程

为什么会选择协程

goroutine调度模型-GPM

并发与并行

--------------------

### 进程、线程、协程 ###

1，进程是系统资源分配的最小单位，线程是CPU调度的最小单位；

2，进程是线程的载体，一个进程可由多个线程组成，进程内的多个线程间可以相互通信；

3，进程的创建和销毁都是系统资源级别，因此是一种比较昂贵的操作；

4，线程是抢占式调度，协程是协作式调度，多线程无可避免的会带来频繁的CPU上下文切换，调度成本高，但抢占式调度由系统内核来完成的，用户态不需要参与，内核参与使得平台移植好；协作式调度中用户态协程会主动让出CPU控制权来让其他协程使用；

5，协程不和内核交互，协程是用户态轻量级线程；

6，线程与协程可简单的理解为捆绑关系，任意数量的用户态协程可以运行在任意数量的os线程上；用户创建的协程会被专门负责管理goroutine的processor接管调度，一个processor可对应N个协程；

7，原生的linux线程从进程栈分配空间，所分配的线程栈空间大小默认为8M：

![20200220153733700.png][]

而创建一个协程分配的空间是2k，空间可能会自动扩增。

### 为什么会选择协程 ###

原生线程的调度成本高，那么go语言自己进行了接管调度---go runtime进行调度。

### goroutine调度模型-GPM ###

源码位置：src/runtime/proc.go

// Goroutine scheduler
    // The scheduler's job is to distribute ready-to-run goroutines over worker threads.
    //
    // The main concepts are:
    // G - goroutine.
    // M - worker thread, or machine.
    // P - processor, a resource that is required to execute Go code.
    //     M must have an associated P to execute Go code, however it can be
    //     blocked or in a syscall w/o an associated P.

G：是对Goroutine的抽象。其中包括执行的函数指令及参数,G保存的任务对象、线程上下文切换，现场保护和现场恢复需要的寄存器(SP、IP)等信息，源码中runtime.g 结构表示的就是G。  
M：os线程，即操作系统内核线程，也可以叫物理processor。源码中runtime.m 结构表示的就是M。通过M来找寻空闲的P从而给其下面挂需要执行的G；

M最大数量10000个（见源码proc.go的schedinit()函数：sched.maxmcount = 10000）。  
P：执行go代码所需的处理器，是负责golang运行时的线程，负责执行goroutine，真正决定并发程度的是P，最大值为256个。初始化的时候一般会去读取GOMAXPROCS对应的值，如果没有显示设置，则会读取默认值。在Go1.5之后GOMAXPROCS被默认设置可用的核数，而之前则默认为1，源码中runtime.p 结构表示的就是P。

![format_png][]

全局队列：维护一个队列用来存放等待执行的G，新创建的goroutine会先存放在本地队列，如果本地队列满了，则会将本地队列的G移动到全局队列里面，本地队列保存G数量默认不超过256个。所有M共享P全局队列。

调度器：Goroutine调度器中的P和OS调度器通过M相结合，操作系统调度器负责把内核线程分配到CPU的核上执行。当P有任务时需要创建或者唤醒一个系统线程来执行它队列里的任务，所以P和M需要进行绑定，所有的G实质上在M上执行。

**每个P对应着一个M(线程想运行任务就需要先获取P)，即M必须具有关联的P才能调度goroutine。**新创建的goroutine会先存放在P的本地队列（图中灰色部分的G所在队列）中，等待调度器进行调度。

M与P绑定后，M先从P的运行队列（图中浅蓝色部分的G所在的待运行队列）中取出G，并切换到G的堆栈执行，当P的本地队列中没有G时，再从本地待调度队列中获取一个G分配给这个P，当本地队列中也没有待运行的G时，则尝试从其它的P偷部分G来执行(偷的时候偷一半)。

通过这种模型，go避免了大量的上下文切换。

——引入：如何减少上下文切换？(参考[https://studygolang.com/articles/20909][https_studygolang.com_articles_20909])

*  无锁并发编程，锁的获取与释放会发生上下文切换，多线程时会影响效率。无锁并发编程就是将数据分块，每个线程处理各自模块。比如LongAdder中部分代码。
 *  CAS算法，并发编程时通过CAS算法更新数据，而不必加锁。如Java的atomic包下的工具类。
 *  使用最少线程，减少不必要的线程创建，自定义线程池。
 *  使用协程，在单线程中维护多任务调度，处理任务间切换，Golang对于协程的使用貌似很强大。

调度执行与现场恢复：M执行过程中随时会发生上下文切换。当发生上线文切换时需要对执行现场进行保护，以便下次被调度执行时进行现场恢复。Go调度器M的栈保存在G对象上，只需要将M所需要的寄存器(SP、PC等)保存到G对象上就可以实现现场保护。当这些寄存器数据被保护起来就随时可以做上下文切换了，在中断之前把现场保存起来。如果此时G任务还没有执行完，M可以将任务重新丢到P的任务队列，等待下一次被调度执行。当再次被调度执行时，M通过访问G的vdsoSP、vdsoPC寄存器进行现场恢复(从上次中断位置继续执行)。

源码对应

type m struct {
    	g0      *g     // goroutine with scheduling stack
    	morebuf gobuf  // gobuf arg to morestack
    	divmod  uint32 // div/mod denominator for arm - known to liblink
    
    	// Fields not known to debuggers.
    	procid        uint64       // for debuggers, but offset not hard-coded
    	gsignal       *g           // signal-handling g
    	goSigStack    gsignalStack // Go-allocated signal handling stack
    	sigmask       sigset       // storage for saved signal mask
    	tls           [6]uintptr   // thread-local storage (for x86 extern register)
    	mstartfn      func()
    	curg          *g       // current running goroutine
    	caughtsig     guintptr // goroutine running during fatal signal
    	p             puintptr // attached p for executing go code (nil if not executing go code)
    	nextp         puintptr
    	oldp          puintptr // the p that was attached before executing a syscall
    	id            int64
    	mallocing     int32
    	throwing      int32
    	preemptoff    string // if != "", keep curg running on this m
    	locks         int32
    	dying         int32
    	profilehz     int32
    	spinning      bool // m is out of work and is actively looking for work
    	blocked       bool // m is blocked on a note
    	newSigstack   bool // minit on C thread called sigaltstack
    	printlock     int8
    	incgo         bool   // m is executing a cgo call
    	freeWait      uint32 // if == 0, safe to free g0 and delete m (atomic)
    	fastrand      [2]uint32
    	needextram    bool
    	traceback     uint8
    	ncgocall      uint64      // number of cgo calls in total
    	ncgo          int32       // number of cgo calls currently in progress
    	cgoCallersUse uint32      // if non-zero, cgoCallers in use temporarily
    	cgoCallers    *cgoCallers // cgo traceback if crashing in cgo call
    	park          note
    	alllink       *m // on allm
    	schedlink     muintptr
    	mcache        *mcache
    	lockedg       guintptr
    	createstack   [32]uintptr // stack that created this thread.
    	lockedExt     uint32      // tracking for external LockOSThread
    	lockedInt     uint32      // tracking for internal lockOSThread
    	nextwaitm     muintptr    // next m waiting for lock
    	waitunlockf   func(*g, unsafe.Pointer) bool
    	waitlock      unsafe.Pointer
    	waittraceev   byte
    	waittraceskip int
    	startingtrace bool
    	syscalltick   uint32
    	freelink      *m // on sched.freem
    
    	// these are here because they are too large to be on the stack
    	// of low-level NOSPLIT functions.
    	libcall   libcall
    	libcallpc uintptr // for cpu profiler
    	libcallsp uintptr
    	libcallg  guintptr
    	syscall   libcall // stores syscall parameters on windows
    
    	vdsoSP uintptr // SP for traceback while in VDSO call (0 if not in call)
    	vdsoPC uintptr // PC for traceback while in VDSO call
    
    	// preemptGen counts the number of completed preemption
    	// signals. This is used to detect when a preemption is
    	// requested, but fails. Accessed atomically.
    	preemptGen uint32
    
    	dlogPerM
    
    	mOS
    }

###  ###

### 并发与并行 ###

文末，顺带聊聊并发与并行

并行：你在吃饭，来了个电话，无关紧要，你一边吃一边说；

并发：你在吃饭，来了个电话，因为一些因素必须通完电话才能继续吃饭（你的身体先由打电话支配使用），通完电话后继续吃饭（身体切换到可以吃饭）。

[go_redis]: https://lan6193.blog.csdn.net/article/details/108938119
[go_redis 1]: https://lan6193.blog.csdn.net/article/details/108931188
[go_goroutine]: https://lan6193.blog.csdn.net/article/details/105715373
[go]: https://lan6193.blog.csdn.net/article/details/108670428
[go_goroutine 1]: https://lan6193.blog.csdn.net/article/details/105559568
[go_go_channel_goroutine]: https://lan6193.blog.csdn.net/article/details/97528721
[go_channel]: https://lan6193.blog.csdn.net/article/details/101201408
[go_WaitGroup]: https://lan6193.blog.csdn.net/article/details/100887891
[channel]: https://lan6193.blog.csdn.net/article/details/97656420
[go_B_A_B_A]: https://lan6193.blog.csdn.net/article/details/108901339
[go 1]: https://lan6193.blog.csdn.net/article/details/103298105
[20200220153733700.png]: https://img-blog.csdnimg.cn/20200220153733700.png
[format_png]: https://imgconvert.csdnimg.cn/aHR0cDovL21vcnNtYWNoaW5lLmRrL2luLW1vdGlvbi5qcGc?x-oss-process=image/format,png
[https_studygolang.com_articles_20909]: https://studygolang.com/articles/20909