【译文】原文地址
本文是基于Go 1.13版本
创建一个操作系统线程或从一个线程切换到另一个线程，对程序来说在内存和性能方面是代价很大的。Go为了充分利用cpu核的优势，在一开始就考虑了并发性。

M, P, G组合

为了解决性能问题，Go有自己的调度器来分配goroutine到线程上去。该调度器定义了三个主要概念，就如代码中所表示的：
G-指的是goroutine
M-工作线程，或者机器
P-处理器，执行代码需要的资源。M必须有相应的P才能运行代码。
如下是M, P, G模型图：

M, P, G模型图

每个goroutine（G）运行在一个OS线程上，这个线程会被分配到一个逻辑CPU（P）。通过一个例子来看下Go如何管理它们的：

package main

import "sync"

func main() {
    var wg sync.WaitGroup
    wg.Add(2)
    go func() {
        println(`hello`)
        wg.Done()
    }()
    go func() {
        println(`world`)
        wg.Done()
    }()
    wg.Wait()
}

Go首先将根据机器的逻辑cpu个数来创建不同的P，并存放在一个空闲的P列表中：

P初始化

然后，新的一个goroutine或多个goroutine将唤醒P来更好的分配工作。这个P将创建一个与操作系统线程相关的M:

OS Thread的创建

M, P空闲队列

在程序的启动过程中，Go已经创建了一些OS线程和相关的M。在以上例子中，第一个输出hello的goroutine将使用main goroutine，而第二个goroutine将从空闲列表中获取一个M和P:

从空闲列表获取M和P

系统调用

Go优化系统调用的方法是通过在运行时对其进行包装，无论系统调用是否阻塞。这个包装器将自动将P和线程M分离，并允许其他线程在其上运行。让我们举一个读取文件的例子：

package main

import (
    "os"
)

func main() {
    buf := make([]byte, 0, 2)

    fd, _ := os.Open("main.go")
    fd.Read(buf)
    fd.Close()

    println(string(buf)) // 42
}

下面是文件打开的工作流程：

系统调用线程交出P

P0进入空闲队列，可供其他线程使用。一旦系统调用退出，Go将应用如下满足条件的规则：

• 尝试获取对应的P，本例中的p0，并继续执行。
• 尝试从空闲列表中获取一个新的P，恢复执行。
• 将正在执行的goroutine放入全局队列，并将对于的M放回空闲队列。
  然而，Go也可以处理资源尚未就绪的情况，比如http调用这种非阻塞I/O情况。在这种情况下，第一个系统调用（遵循前面的共工作流程）因为资源未就绪将调用不成功，迫使Go使用网络轮询并使goroutine驻留。

func main() {
   http.Get(`https://httpstat.us/200`)
}

一旦第一个系统调用完成并显示资源未就绪，对应的goroutine就会驻留，直到网络轮询通知资源就绪。在这种情况下，线程M将不会被阻塞：

网络轮询等待资源就绪

当Go调度器寻找工作时，对应的goroutine将再次运行。然后调度器将询问网络轮询器，是否有等待就绪的gorotine需要执行。

操作系统线程约束

当使用系统调用时，Go不限制被阻塞的操作系统线程数量，如下所述：
GOMAXPROCS变量限制了能够同时执行用户态Go代码的操作系统线程数量。但并没有对Go代码中处于阻塞状态下系统调用的线程数量有限制。这些系统调用线程数量不会受影响。
以下就是这种情况的一个例子：

package main

import (
    "fmt"
    "net/http"
    "sync"
)

func main() {
        var wg sync.WaitGroup

        for i := 0;i < 100 ;i++  {
            wg.Add(1)

            go func(i int) {
                http.Get(`https://www.baidu.com`)
                fmt.Println(i)
                wg.Done()
            }(i)
        }

        wg.Wait()
    }

如下是跟踪工具查看到的线程个数：

image.png

因为Go优化了线程的使用，当goroutine被阻塞时线程会被复用，这就解释了为什么这个线程数和循环数量不一致。