失常的执行程序就是线性的，谁在后面，谁就先执行，然而并发能力，会让你的程序，能够由若干个代码片段组合而成，并且每个片段都是独立运行的。Go语言天生反对这种并发能力，而Goroutine就是Go原生反对并发的具体实现。无论是Go的运行时还是用户写的代码都是运行在Goroutine中。
Goroutine是由Go运行时治理的轻量级线程。和操作系统线程相比，goroutine的资源占用和应用代价十分小。咱们能够创立几百到十几万个goroutine，甚至更多。Go运行时负责对goroutine进行治理和调度。
不要让—“治理和调度”这种专业术语吓住，你能够简略了解，什么时候、哪个goroutine将取得资源开始执行，哪个goroutine应该进行执行让出资源，哪个goroutine应该被唤醒回复执行等。这样的了解和现实生活中是截然不同的，例如哨兵站岗。goroutine的调度模型和原理，对于编写出优雅而高质量的代码是大有益处的。因而，在面试中能够说是每次必问。
一 goroutine调度器
调度：操作系统中对过程、线程的调度。操作系统调度器会将零碎中的多个线程依照肯定算法调度到物理CPU下来运行。如C、C++等并发实现多是基于线程模型的，就是应用程序负责创立线程（libpthread等库函数去实现），操作系统负责调度线程。这种模式就是有一些有余： 简单
1)写过C、C++的人必定都晓得，这里有如许的简单，利用libpthread库中的API创立一个线程的时候，尽管要传入的参数很多，然而还能够承受。一旦波及到线程的退出，那就要思考主线程与新线程的很多资源相干的问题。
2) 并发执行单元相互通信艰难，容易出错：多个线程间的通信有很多机制，但用起来也是很简单的；一旦用到共享内存，那就是各种锁机制，导致死锁，更是很轻松就做到的。
难度
1) 咱们应用线程的代价要比过程小很多，然而仍然不能大量创立线程，除了每个线程占用的资源不小之外，操作系统调度切换线程的代价也很大。
2) 很多服务端程序，因为不能大量创立线程，只能抉择在大量线程里做网络多路复用的计划（epoll/kqueue/IoCompletionPort这种机制），或者你会说能够用libevent和libev啊，这样的写法存在大量的钩子回调，给开发人员带来不小的累赘。
看到下面的痛点，Go采纳了Goroutine来解决这些痛点。Goroutine占用资源十分小，每个Gorouine栈的大小默认是2k字节。goroutine调度的切换也不必在操作系统内核中实现，代价很低。所以一个Go程序能够创立成千上万个并发的goroutine，而把这些goroutine依照肯定算法放到cpu上执行的程序，咱们就成为goroutine调度器（Scheduler）。
一个Go程序运行起来，在操作系统看来就是一个用户程序，操作系统的概念，只有线程，它甚至不晓得有Goroutine的存在。Goroutine的调度齐全靠GO本人实现。实现GO程序内Goroutine之间的公平竞争CPU的资源，这个工作就靠GO运行时（runtime）了，一个Go程序中，除了用户层代码，其余就是go运行时了。
二 Go调度器模型与演化过程
第一版 G-M 模型
2012.3.28日,Go1.0正式公布，Go团队实现了一个简略的goroutine调度器。在这个调度其中，每个goroutine对应于运行时中的一个形象构造G（Goroutine），另外一个构造体是M(Machine)，它被看成是“物理CPU”的操作系统线程。这个模型实现起来比较简单，且工作失常，然而也有一些问题，最重要的是限度了GO并发程序的伸缩性，如下几个方面：
繁多全局互斥锁(Sched.Lock)和集中状态存储的存在导致所有goroutine相干操作。如创立、从新调度都要加锁。
goroutine传递问题：M常常在M之间传递“可运行”的goroutine，这导致调度提早增大及额定的性能损耗；
每个M都做内存缓存，导致内存占用过高，数据局部性交差。
因为零碎调用而造成的频繁的工作线程阻塞和解阻塞，导致额定性能损耗。
第二版 G-P-M 模型
基于第一版的问题，在Go1.1中实现了G-P-M模型和work stealing算法,这个模型始终沿用。
咱们看到在G-M中减少了一个P,这个P是何方神圣呢？ P是一个“逻辑Processor”,每个G要想真正运行起来，都须要被调配到一个P，即进入到P的本地运行队列中，先临时疏忽全局队列。对于G来说，P就是运行它的“CPU”,在G看来只有P。但从调度器的角度看，真正的“CPU”是M,只有将P和M绑定能力让P中的G真正的运行起来。这样的P与M的关系，相似Linux操作系统中用户线程和内核线程的对应关系(N*M)
3 抢占式调度
有了G-P-M模型，是很大的提高，然而仍有一个问题，它不反对抢占式调度，一旦某个G中呈现死循环的代码逻辑，那么G将永恒占用调配给他的P和M,而在同一个P中的其余G永远不能被调度，呈现其余G被“饿死”的状况。在Go1.2中实现了“抢占式”调度。
抢占式的原理是在每个函数或办法的入口，加一段额定的代码，让运行时有机会查看是否须要执行抢占调度。这种解决方案只能部分解决“饿死”问题。对于没有函数调用而是存算法计算的G,依然无奈实现抢占。
4 NUMA调度模型
从Go1.2后，Go将重点放在对GC的低提早的优化上，只是一些小的改变。
5 其余优化
Go运行时曾经实现了netpoller(https://morsmachine.dk/netpol...，也不会导致M被阻塞（仅阻塞G）,从而不会导致大量（M）被创立进去。然而对于惯例I/O操作一旦阻塞，那么线程（M）将进入挂起状态，期待I/O返回后被唤醒。这时，P将与挂起的M拆散，再抉择一个处于闲暇的M.如果此时没有闲暇的M,则新建一个M,这就是为何大量I/O操作会导致大量线程被创立的起因。
三 对Go调度器深刻理解
1. G、P、M G、P、M的定义，在 $GOROOT/src/runtime/runtime2.go 源文件中。 G、P、M这三个构造体定义都是很沉重的，每个构造体定义都蕴含十几甚至二、三十个字段。像调度器这样的外围代码都是非常复杂的，思考的因素也很多。简略阐明一下：
G: 它是Goroutine，存储了Goroutine的执行栈信息、Goroutine状态以及Goroutine的工作函数等（G是能够重用的）。
P: 它是逻辑Processor,P的数量决定了零碎内最大可并行的G的数据（物理CPU核数>=P的数量）；P最大的作用是它有各种G对象队列、链表、缓存和状态。
M: 它是真正执行计算的资源。在绑定无效的P后，一个调度循环开始；而调度循环的机制是从各种队列、P的本地运行队列中获取G,切换到G的执行栈上并行执行G的函数，调用goexit做清理工作，而后回到M。这样重复。M并不保留G的状态，这是G能够跨M调度的根底。
G被抢占调用调度
操作系统是按工夫片调度线程的，Go并没有工夫片的概念。如果某个G没有进行零碎调用、没有I/O操作、没有阻塞在一个channel上，那么M是怎么让G停下来并调度下一个可运行的G?
这就要说抢占调度了。
下面说了，除非是有限死循环，否则只有G调用函数，Go运行时就有了抢占G的机会。GO程序启动的时候，运行时会启动一个名为sysmon的M（你能够简略了解为监控器或监控协程），该M非凡之处就是其无需绑定P即可运行（以g0的模式），该M在整个Go程序的运行过程中十分重要。
$GOROOT/src/runtime/proc.go
//The main goroutine.
func main() {
... ... systemstack(func() { newm(sysmon, nil) }) .... ... }
// Always runs without a P, so write barriers are not allowed.
//
//go:nowritebarrierrec
func sysmon() {
// If a heap span goes unused for 5 minutes after a garbage collection, // we hand it back to the operating system. scavengelimit := int64(5 * 60 * 1e9) ... ... if .... { ... ... // retake P's blocked in syscalls // and preempt long running G's if retake(now) != 0 { idle = 0 } else { idle++ } ... ... } }
从下面源代码能够看到symon每20us—10ms启动一次，sysmon次要工作：
开释闲置超过5分钟的span物理内存； 如果超过2分钟没有垃圾回收，强制执行； 将长时间未解决的netpoll后果增加到工作队列； 向长时间运行的G工作收回抢占调度； 发出因syscall长时间阻塞的P; 3 channel阻塞或网络I/O下的调度
如果G被阻塞在某个channel操作或者网络I/O操作上的时候，G会被放入到某个期待队列中，而M会尝试运行P的下一个可运行的G；如果此时P没有可运行的G给M运行，那么M将解绑P，并进入挂起状态。当I/O或者channel操作实现，在期待队列中的G会被唤醒，标记为可运行，并被放入到某个P队列中，绑定一个M后持续运行。
4 零碎调用阻塞状况下，如何调度
如果G被阻塞在某个零碎调用上，那么不仅仅G会阻塞，执行G的M也会解绑P，与G一起进入挂起状态。如果此时有闲暇的M,则P和与其绑定并继续执行其余的G;如果没有闲暇的M,但还是有其余G去执行，那么会创立一个新M。当零碎调用返回后，阻塞在该零碎调用上的G会尝试获取一个可用的P,如果没有可用的P,那么这个G会被标记为runnable，之前的那个挂起的M将再次进入挂起状态。