Golang的一大特色就是Goroutine。Goroutine是Golang支持高并发的重要保障。Golang可以创建成千上万个Goroutine来处理任务，将这些Goroutine分配、负载、调度到处理器上采用的是G-M-P模型。

Goroutine = Golang + Coroutine。 Goroutine是golang实现的协程，是用户级线程 。Goroutine具有以下特点：

在仅支持进程的操作系统中，进程是拥有资源和独立调度的基本单位。在引入线程的操作系统中， 线程是独立调度的基本单位，进程是资源拥有的基本单位 。在同一进程中，线程的切换不会引起进程切换。在不同进程中进行线程切换,如从一个进程内的线程切换到另一个进程中的线程时，会引起进程切换

线程创建、管理、调度等采用的方式称为线程模型。线程模型一般分为以下三种：

三大线程模型最大差异就在于用户级线程与内核调度实体KSE（KSE，Kernel Scheduling Entity）之间的对应关系。 KSE是Kernel Scheduling Entity的缩写，其是可被操作系统内核调度器调度的对象实体，是操作系统内核的最小调度单元，可以简单理解为内核级线程 。

用户级线程即协程 ，由应用程序创建与管理，协程必须与内核级线程绑定之后才能执行。 线程由 CPU 调度是抢占式的，协程由用户态调度是协作式的，一个协程让出 CPU 后，才执行下一个协程 。

用户级线程(ULT)与内核级线程(KLT)比较：

内核级线程模型中用户线程与内核线程是一对一关系（1 : 1） 。 线程的创建、销毁、切换工作都是有内核完成的 。应用程序不参与线程的管理工作，只能调用内核级线程编程接口(应用程序创建一个新线程或撤销一个已有线程时，都会进行一个系统调用）。每个用户线程都会被绑定到一个内核线程。用户线程在其生命期内都会绑定到该内核线程。一旦用户线程终止，两个线程都将离开系统。

操作系统调度器管理、调度并分派这些线程。运行时库为每个用户级线程请求一个内核级线程。操作系统的内存管理和调度子系统必须要考虑到数量巨大的用户级线程。操作系统为每个线程创建上下文。进程的每个线程在资源可用时都可以被指派到处理器内核。

内核级线程模型有如下优点：

用户线程模型中的用户线程与内核线程KSE是多对一关系（N : 1） 。 线程的创建、销毁以及线程之间的协调、同步等工作都是在用户态完成 ，具体来说就是由应用程序的线程库来完成。 内核对这些是无感知的，内核此时的调度都是基于进程的 。线程的并发处理从宏观来看，任意时刻每个进程只能够有一个线程在运行，且只有一个处理器内核会被分配给该进程。

从上图中可以看出来：库调度器从进程的多个线程中选择一个线程，然后该线程和该进程允许的一个内核线程关联起来。内核线程将被操作系统调度器指派到处理器内核。用户级线程是一种”多对一”的线程映射

用户级线程有如下优点：

两级线程模型中用户线程与内核线程是一对一关系（N : M） 。两级线程模型充分吸收上面两种模型的优点，尽量规避缺点。其线程创建在用户空间中完成，线程的调度和同步也在应用程序中进行。一个应用程序中的多个用户级线程被绑定到一些（小于或等于用户级线程的数目）内核级线程上。

Golang在底层实现了混合型线程模型 。M即系统线程，由系统调用产生，一个M关联一个KSE，即两级线程模型中的系统线程。G为Groutine，即两级线程模型的的应用及线程。M与G的关系是N:M。

G-M-P分别代表：

GMP调度流程大致如下：

上面生命周期流程说明：

G 的数量：

理论上没有数量上限限制的。查看当前G的数量可以使用 runtime. NumGoroutine()

P 的数量：

由启动时环境变量 $GOMAXPROCS 或者是由 runtime.GOMAXPROCS() 决定。这意味着在程序执行的任意时刻都只有 $GOMAXPROCS 个 goroutine 在同时运行。

M 的数量:

go 语言本身的限制：go 程序启动时，会设置 M 的最大数量，默认 10000. 但是内核很难支持这么多的线程数，所以这个限制可以忽略。 runtime/debug 中的 SetMaxThreads 函数，设置 M 的最大数量 一个 M 阻塞了，会创建新的 M。M 与 P 的数量没有绝对关系，一个 M 阻塞，P 就会去创建或者切换另一个 M，所以，即使 P 的默认数量是 1，也有可能会创建很多个 M 出来。

从上图我们可以看出来：

GMP模型的阻塞可能发生在下面几种情况：

当goroutine因为channel操作或者network I/O而阻塞时（实际上golang已经用netpoller实现了goroutine网络I/O阻塞不会导致M被阻塞，仅阻塞G），对应的G会被放置到某个wait队列(如channel的waitq)，该G的状态由_Gruning变为_Gwaitting，而M会跳过该G尝试获取并执行下一个G，如果此时没有runnable的G供M运行，那么M将解绑P，并进入sleep状态；当阻塞的G被另一端的G2唤醒时（比如channel的可读/写通知），G被标记为runnable，尝试加入G2所在P的runnext，然后再是P的Local队列和Global队列。

当G被阻塞在某个系统调用上时，此时G会阻塞在_Gsyscall状态，M也处于 block on syscall 状态，此时的M可被抢占调度：执行该G的M会与P解绑，而P则尝试与其它idle的M绑定，继续执行其它G。如果没有其它idle的M，但P的Local队列中仍然有G需要执行，则创建一个新的M；当系统调用完成后，G会重新尝试获取一个idle的P进入它的Local队列恢复执行，如果没有idle的P，G会被标记为runnable加入到Global队列。

G的内部结构中重要字段如下，完全结构参见

type g struct {
    stack       stack   // g自己的栈
    m            *m      // 隶属于哪个M
    sched        gobuf   // 保存了g的现场，goroutine切换时通过它来恢复
    atomicstatus uint32  // G的运行状态
    goid         int64
    schedlink    guintptr // 下一个g, g链表
    preempt      bool //抢占标记
    lockedm      muintptr // 锁定的M,g中断恢复指定M执行
    gopc          uintptr  // 创建该goroutine的指令地址
    startpc       uintptr  // goroutine 函数的指令地址

G的状态有以下9种，可以参见 schedlink muintptr // 下一个m, m链表 mcache * mcache // 内存分配 lockedg guintptr // 和 G 的lockedm对应 freelink * m // on sched.freem P的内部结构

P的内部结构，完全结构参见

type p struct {
    id          int32
    status      uint32 // P的状态
    link        puintptr // 下一个P, P链表
    m           muintptr // 拥有这个P的M
    mcache      *mcache  
    // P本地runnable状态的G队列，无锁访问
    runqhead uint32
    runqtail uint32
    runq     [256]guintptr
    runnext guintptr // 一个比runq优先级更高的runnable G
    // 状态为dead的G链表，在获取G时会从这里面获取
    gFree struct {
        gList
        n int32
    gcBgMarkWorker       guintptr // (atomic)
    gcw gcWork

P有以下几种状态，参加 nmidle int32 // 空闲M数量 nmidlelocked int32 // 被锁住的M的数量 mnext int64 // 已创建M的数量，以及下一个M ID maxmcount int32 // 允许创建最大的M数量 nmsys int32 // 不计入死锁的M数量 nmfreed int64 // 累计释放M的数量 pidle puintptr // 空闲的P链表 npidle uint32 // 空闲的P数量 runq gQueue // 全局runnable的G队列 runqsize int32 // 全局runnable的G数量 // Global cache of dead G's. gFree struct { lock mutex stack gList // Gs with stacks noStack gList // Gs without stacks n int32 // freem is the list of m's waiting to be freed when their // m.exited is set. Linked through m.freelink. freem * m 观察调度流程 GODEBUG trace方式

GODEBUG 变量可以控制运行时内的调试变量，参数以逗号分隔，格式为：name=val。观察GMP可以使用下面两个参数：

schedtrace：设置 schedtrace=X 参数可以使运行时在每 X 毫秒输出一行调度器的摘要信息到标准 err 输出中。

scheddetail：设置 schedtrace=X 和 scheddetail=1 可以使运行时在每 X 毫秒输出一次详细的多行信息，信息内容主要包括调度程序、处理器、OS 线程 和 Goroutine 的状态。

package main
import (
    "sync"
    "time"
func main() {
	var wg sync.WaitGroup
	for i := 0; i < 2000; i++ {
		wg.Add(1)
		go func() {
			a := 0
			for i := 0; i < 1e6; i++ {
				a += 1
			wg.Done()
        time.Sleep(100 * time.Millisecond)
	wg.Wait()

执行一下命令：

GODEBUG=schedtrace=1000 go run ./test.go

输出内容如下：

SCHED 0ms: gomaxprocs=1 idleprocs=1 threads=4 spinningthreads=0 idlethreads=1 runqueue=0 [0]
SCHED 1001ms: gomaxprocs=1 idleprocs=1 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0]
SCHED 2002ms: gomaxprocs=1 idleprocs=1 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0]
SCHED 3002ms: gomaxprocs=1 idleprocs=1 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0]
SCHED 4003ms: gomaxprocs=1 idleprocs=1 threads=4 spinningthreads=0 idlethreads=2 runqueue=0 [0]

输出内容解释说明：

func main() {
	// 创建trace文件
	f, err := os.Create("trace.out")
	if err != nil {
		panic(err)
	defer f.Close()
	// 启动trace goroutine
	err = trace.Start(f)
	if err != nil {
		panic(err)
	defer trace.Stop()
	// main
	fmt.Println("Hello trace")

执行下面命令产生trace文件trace.out：

go run test.go

执行下面命令，打开浏览器，打开控制台查看。

go tool trace trace.out

G-M-P高效的保证策略有：