12 Go 并发调度器模型
一、聊聊并发这件事
在基础系列我们学习了Go的并发编程，对并发的概念已经有了一定的了解。在各种现代高级语言中，对并发的支持已经是标配，但Go的并发无论在开发效率还是在性能上都有相当的优越性。Go有什么独特的设计让其在并发编程领域独步江湖？这得益于Go的并发调度器。
我们知道，软件在系统运行的基本单元是进程，由进程开辟出多条线程，而线程则是CPU调度的基本单位。我们常说千级并发、万级并发。甚至百万级并发，是那么多线程真正同一时间执行吗？其实并不是，程序同一时间的并发数完全由物理上的CPU核心数决定，即同一时间单位一个CPU核心只能执行一条线程的计算，其多线程的并发完全由调度器决定。
二、并发模型概述
各种高级语言的调度器设计各不相同，但基本可以分成三种模型设计，第一种为内核级并发模型(1:1)，即内核线程和用户线程绑定；第二种为用户级并发模型(N:1)，由用户维护线程的管理，其内核线程和用户线程的调度由调度器实现；第三种为两级调度的混合并发模型(N:M)，这种集前两种模型的优势，完全由语言运行时的调度器控制，是实现最为复杂的一种。下面我们分别了解一下这三种并发模型：
1.内核级并发模型（1:1）
所谓内核线程，即物理线程，可以被操作系统内核调度器调度的对象实体，是操作系统内核的最小调度单元。这里用户开辟的每一个线程和内核线程绑定（1:1），线程的调度完全由系统内核管理，应用程序对线程几乎没有管理，大部分语言的线程库，如JAVA，都是对操作系统内核线程的封装。
优点：
- 实现简单，直接扔给操作系统内核管理；
- 线程切换由CPU实现，可以有效利用CPU的多核；
缺点：
- CPU管理的线程切换涉及线程的上下文、资源调度，因此切换成本很高；
- 不宜开辟过多的并发量，内核线程的堆栈空间在 Windows 下默认 2M，Linux 下默认 8M，过多的并发量导致的切换开销对性能影响是很大的。
2.用户级并发模型(N:1)
所谓用户级并发模型，是指单个进程内部管理的多条线程，线程的调度完全由用户进程决定，一个进程中的所有线程都只和一个CPU内核线程在运行时动态绑定(N:1)。即CPU内核线程的调度器对用户进程内部的多条线程是无感知的，内核线程只知道用户进程。像python、nodejs等语言的并发实现就是这种模型，简单来说这是一种伪并发，因为同一时间内允许的线程只有一个。
优点：
- 线程调度在用户层面，CPU不需要在用户态和内核态切换，资源开销很小；
- 由于没有上下文切换带来的开销，其用户线程比较轻量化，可以开启较多的用户线程。
缺点：
- 并不能做到真正意义上的并发，其本质还是单核计算，对于IO阻塞的任务还是会被中断；
- 需要线程库把IO阻塞的操作重新封装为完全的非阻塞形式，然后在以前要阻塞的点上，主动让出自己，并通过某种方式通知或唤醒其他待执行的用户线程在内核线程上运行
调度器模型1.jpg
3.混合型并发模型(N:M)
以上两种调度器模型都有优缺点，有没有可能取长补短设计新的调度器模型呢？混合型并发模型就是博采众长之后的产物，充分吸收前两种线程模型的优点且尽量规避它们的缺点。混合型并发模型是让内核线程和用户线程建立多对多的关系(N:M)，即一个用户进程可以和多个内核线程关联，相当于用户进程内部开辟的多个用户线程可以动态绑定多个内核线程。这种模型避免了内核级模型中的完全靠操作系统调度的并发性能问题，也避免了用户级模型中的伪并发问题，它是用户自身调度器和系统调度器协同工作的设计。
优点：
- 充分博采众长，实现真正意义上的高效能并发；
- 对用户友好，用户只需管理业务层面的并发任务。
缺点：
- 由于这种模型需用用户级调度和系统级调度协同工作，所以这种调度器实现都相当复杂。
调度器模型2.jpg
三、Go并发调度器解析
Go调度器中的三种结构G、P、M
系统线程固定2M，且维护一堆上下文，对需求多变的并发应用并不友好，有可能造成内存浪费或内存不够用。Go将并发的单位下降到线程以下，由其设计的goroutine初始空间非常小，仅2kb，但支持动态扩容到最大1G，这就是go自己的并发单元——goroutine协程。
实际上系统最小的执行单元仍然是线程，go运行时执行的协程也是挂载到某一系统线程之上的，这种协程与系统线程的调度分配由Go的并发调度器承担，Go的并发调度器是属于混合的二级调度并发模型，其内部设计有G、P、M三种抽象结构，我们来看一下它们分别是什么：
G-P-M模型抽象结构：
- G: 表示Goroutine，每个Goroutine对应一个G结构体，G存储Goroutine的运行堆栈、状态以及任务函数，可重用。G运行队列是一个栈结构，分全局队列和P绑定的局部队列，每个G不能独立运行，它需要绑定到P才能被调度执行。
- P: Processor，表示逻辑处理器， 对G来说，P相当于CPU核，G只有绑定到P(在P的local runq中)才能被调度。对M来说，P提供了相关的执行环境(Context)，如内存分配状态(mcache)，任务队列(G)等，P的数量决定了系统内最大可并行的G的数量（前提：物理CPU核数 >= P的数量），P的数量由用户设置的GOMAXPROCS决定，但是不论GOMAXPROCS设置为多大，P的数量最大为256。
- M: Machine，系统物理线程，代表着真正执行计算的资源，在绑定有效的P后，进入schedule循环；而schedule循环的机制大致是从Global队列、P的Local队列以及wait队列中获取G，切换到G的执行栈上并执行G的函数，调用goexit做清理工作并回到M，如此反复。M并不保留G状态，这是G可以跨M调度的基础，M的数量是不定的，由Go Runtime调整，为了防止创建过多OS线程导致系统调度不过来，目前默认最大限制为10000个。
关于P这个设计，是在Go1.0之后才实现的，起初的Go并发性能并不十分亮眼，协程和系统线程的调度比较粗暴，导致很多性能问题，如全局资源锁、M的内存过高等造成许多性能损耗，加入P的设计后实现了一个叫做 work-stealing 的调度算法：由P来维护Goroutine队列并选择一个适当的M绑定。
Go并发调度器的GPM模型.jpg
G-P-M模型调度
我们来看看go关键字创建一个协程后其调度器是怎么工作的：
- go关键字创建goroutine(G)，优先加入某个P维护的局部队列（当局部队列已满时才加入全局队列）；
- P需要持有或者绑定一个M，而M会启动一个系统线程，不断的从P的本地队列取出G并执行；
- M执行完P维护的局部队列后，它会尝试从全局队列寻找G，如果全局队列为空，则从其他的P维护的队列里窃取一般的G到自己的队列；
- 重复以上知道所有的G执行完毕。
当然也有一些情况会造成Goroutine阻塞，如：
- 系统GC；
- 系统IO资源的调用，如文件读写；
- 网络IO的延迟；
- 管道阻塞；
- 同步操作。
当遇到上述阻塞时，Go调度器也有相应的处理方式：
- 1.系统调度引起阻塞：
如系统GC，M会解绑P，出让控制权给其他M，让该P维护的G运行队列不至于阻塞。
- 2.用户态的阻塞：
当goroutine因为管道操作或者系统IO、网络IO而阻塞时，对应的G会被放置到某个等待队列，该G的状态由运行时变为等待状态，而M会跳过该G尝试获取并执行下一个G，如果此时没有可运行的G供M运行，那么M将解绑P，并进入休眠状态；当阻塞的G被另一端的G2唤醒时，如管道通知，G又被标记为可运行状态，尝试加入G2所在P局部队列的队头，然后再是G全局队列。
- 3.当存在空闲的P时，窃取其他队列的G：
当P维护的局部队列全部运行完毕，它会尝试在全局队列获取G，直到全局队列为空，再向其他局部队列窃取一般的G。
至此Go的调度器模型解析完毕。基于Go调度器的优越设计，它号称能实现百万级并发，即使日常很难达到这种并发量，我们也应该对并发的使用要心存敬畏，真正的并发依赖于物理核心，启动并发是需要系统开销的，虽然在Go的运行时它看起来很小，但量变引起质变，当业务启动的并发到十万级、百万级甚至千万级时，其性能开销还是非常巨大的。可以通过一定的手段控制并发数量以防止系统奔溃，如实现一个协程池，通过worker机制控制并发数。
Ok，希望学完这一专题你会对Go的并发有更深刻的了解。
