> For the complete documentation index, see [llms.txt](https://deepingo.run-linux.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://deepingo.run-linux.com/conc.md).

# Go 并发机理

> Don’t communicate by sharing memory; share memory by communicating.
>
> 不要通过共享数据来通讯，恰恰相反，要以通讯的方式共享数据。

通道（也就是 channel）类型的值，可以被用来以通讯的方式共享数据。更具体地说，它一般被用来在不同的 goroutine 之间传递数据。

goroutine 代表着并发编程模型中的用户级线程。操作系统本身提供了进程和线程，这两种并发执行程序的工具。

## 进程与线程

**进程**，描述的就是程序的执行过程，是运行着的程序的代表。换句话说，一个进程其实就是某个程序运行时的一个产物。如果说静静地躺在那里的代码就是程序的话，那么奔跑着的、正在发挥着既有功能的代码就可以被称为进程。线程总是在进程之内的，它可以被视为**进程中运行着的控制流（或者说代码执行的流程）。**

**一个进程至少会包含一个线程**。如果一个进程只包含了一个线程，那么它里面的所有代码都只会被串行地执行。**每个进程的第一个线程都会随着该进程的启动而被创建，它们可以被称为其所属进程的主线程。**如果一个进程中包含了多个线程，那么**其中的代码就可以被并发地执行**。除了**进程的第一个线程之外，其他的线程都是由进程中已存在的线程创建出来的。**

**主线程之外的其他线程都只能由代码显式地创建和销毁。**这需要我们在编写程序的时候进行手动控制，操作系统以及进程本身并不会帮我们下达这样的指令，它们只会忠实地执行我们的指令。

Go 语言的运行时（runtime）系统会帮助我们自动地创建和销毁系统级的线程。这里的系统级线程指的就是我们刚刚说过的操作系统提供的线程。

对应的用户级线程指的是架设在系统级线程之上的，**由用户（或者说我们编写的程序）完全控制的代码执行流程**。**用户级线程的创建、销毁、调度、状态变更以及其中的代码和数据都完全需要我们的程序自己去实现和处理。**

这带来了很多优势，比如，因为它们的创建和销毁并不用通过操作系统去做，所以速度会很快，又比如，由于不用等着操作系统去调度它们的运行，所以往往会很容易控制并且可以很灵活。

劣势也依旧存在，最明显也最重要的一个劣势就是复杂。如果我们只使用了系统级线程，那么我们只要指明需要新线程执行的代码片段，并且下达创建或销毁线程的指令就好了，其他的一切具体实现都会由操作系统代劳。但是，如果使用用户级线程，我们就不得不既是指令下达者，又是指令执行者。我们必须全权负责与用户级线程有关的所有具体实现。操作系统不但不会帮忙，还会要求我们的具体实现必须与它正确地对接，否则用户级线程就无法被并发地，甚至正确地运行。毕竟我们编写的所有代码最终都需要通过操作系统才能在计算机上执行。

**Go 语言不但有着独特的并发编程模型，以及用户级线程 goroutine，还拥有强大的用于调度 goroutine、对接系统级线程的调度器。**

这个调度器是 Go 语言运行时系统的重要组成部分，它主要负责统筹调配 Go 并发编程模型中的三个主要元素，即：**G（goroutine 的缩写）、P（processor 的缩写）和 M（machine 的缩写）**。

其中的 **M 指代的就是系统级线程**。而 **P 指的是一种可以承载若干个 G**，且能够使这些 **G 适时地与 M 进行对接，并得到真正运行的中介。**

从宏观上说，**G 和 M 由于 P 的存在可以呈现出多对多的关系**。**当一个正在与某个 M 对接并运行着的 G，需要因某个事件（比如等待 I/O 或锁的解除）而暂停运行的时候，调度器总会及时地发现，并把这个 G 与那个 M 分离开，以释放计算资源供那些等待运行的 G 使用。**

而**当一个 G 需要恢复运行的时候，调度器又会尽快地为它寻找空闲的计算资源（包括 M）并安排运行。**另外，**当 M 不够用时，调度器会帮我们向操作系统申请新的系统级线程，而当某个 M 已无用时，调度器又会负责把它及时地销毁掉。**

正因为调度器帮助我们做了很多事，所以我们的 Go 程序才总是能高效地利用操作系统和计算机资源。程序中的所有 goroutine 也都会被充分地调度，其中的代码也都会被并发地运行，即使这样的 goroutine 有数以十万计，也仍然可以如此。

![9ea14f68ffbcde373ddb61e186695d7d](https://static001.geekbang.org/resource/image/9e/7d/9ea14f68ffbcde373ddb61e186695d7d.png)

## 主 Goroutine

```go
package main

import "fmt"

func main() {
  for i := 0; i < 10; i++ {
    go func() {
      fmt.Println(i)
    }()
  }
}
```

> 该程序不会有任何内容被打印出来。

与一个进程总会有一个主线程类似，每一个独立的 Go 程序在运行时也总会有一个主 goroutine。这个主 goroutine 会在 Go 程序的运行准备工作完成后被自动地启用，并不需要我们做任何手动的操作。

每条 go 语句一般都会携带一个函数调用，这个被调用的函数常常被称为 go 函数。而主 goroutine 的 go 函数就是那个作为程序入口的 main 函数。

一定要注意，go 函数真正被执行的时间，总会与其所属的 go 语句被执行的时间不同。当程序执行到一条 go 语句的时候，Go 语言的运行时系统，会先试图从某个存放空闲的 G 的队列中获取一个 G（也就是 goroutine），它只有在找不到空闲 G 的情况下才会去创建一个新的 G。

我们会说“启用”一个 goroutine，而不说“创建”一个 goroutine 的原因。已存在的 goroutine 总是会被优先复用。

创建 G 的成本也是非常低的。创建一个 G 并不会像新建一个进程或者一个系统级线程那样，必须通过操作系统的系统调用来完成，在 Go 语言的运行时系统内部就可以完全做到了，更何况一个 G 仅相当于为需要并发执行代码片段服务的上下文环境而已。

拿到了一个空闲的 G 之后，Go 语言运行时系统会用这个 G 去包装当前的那个go函数（或者说该函数中的那些代码），然后再把这个 G 追加到某个存放可运行的 G 的队列中。队列中的 G 总是会按照先入先出的顺序，很快地由运行时系统内部的调度器安排运行。虽然这会很快，但是由于上面所说的那些准备工作还是不可避免的，所以**耗时还是存在的**。

**Go 函数的执行时间**总是会明显**滞后于**它所属的 **go 语句的执行时间**。当然了，这里所说的“明显滞后”是对于计算机的 CPU 时钟和 Go 程序来说的。我们在大多数时候都不会有明显的感觉。

记住，**只要 go 语句本身执行完毕，Go 程序完全不会等待go函数的执行，它会立刻去执行后边的语句。这就是所谓的异步并发地执行。**

**一旦主 goroutine 中的代码（也就是main函数中的那些代码）执行完毕，当前的 Go 程序就会结束运行。**

**当for语句的最后一个迭代运行的时候，其中的那条go语句即是最后一条语句。所以，在执行完这条go语句之后，主 goroutine 中的代码也就执行完了，Go 程序会立即结束运行。**

```go
package main
import (
    "fmt"
    "time"
)
func main() {
    for i := 0; i < 10; i++ {
        go func(i int ) {
            fmt.Println(i)
        }(i)
    }
    time.Sleep(100000)
}
```

Go 语言才能保证每个 goroutine 都可以拿到一个唯一的整数。其原因与go函数的执行时机有关。

在go语句被执行时，我们传给go函数的参数i会先被求值，如此就得到了当次迭代的序号。之后，无论go函数会在什么时候执行，这个参数值都不会变。也就是说，go函数中调用的fmt.Println函数打印的一定会是那个当次迭代的序号。

我们在着手改造for语句中的go函数。

```go
for i := uint32(0); i < 10; i++ {
  go func(i uint32) {
    fn := func() {
      fmt.Println(i)
    }
    trigger(i, fn)
  }(i)
}
```

trigger函数接受两个参数，一个是uint32类型的参数i, 另一个是func()类型的参数fn。你应该记得，func() 代表的是既无参数声明也无结果声明的函数类型。

```go
var count uint32
trigger := func(i uint32, fn func()) {
  for {
    if n := atomic.LoadUint32(&count); n == i {
      fn()
      atomic.AddUint32(&count, 1)
      break
    }
    time.Sleep(time.Nanosecond)
  }
}
```

trigger 函数会不断地获取一个名叫 count的变量的值，并判断该值是否与参数 i 的值相同。如果相同，那么就立即调用 fn 代表的函数，然后把 count 变量的值加 1，最后显式地退出当前的循环。否则，我们就先让当前的 goroutine “睡眠” 一个纳秒再进入下一个迭代。

注意，我操作变量 count 的时候使用的都是原子操作。这是由于 trigger 函数会被多个 goroutine 并发地调用，所以它用到的非本地变量 count ，就被多个用户级线程共用了。因此，对它的操作就产生了竞态条件（race condition），破坏了程序的并发安全性。所以，我们总是应该对这样的操作加以保护，在sync/atomic包中声明了很多用于原子操作的函数。

由于我选用的**原子操作函数对被操作的数值的类型有约束**，所以我才对count以及相关的变量和参数的类型进行了统一的变更（由int变为了uint32）。

纵观 count 变量、trigger函数以及改造后的for语句和go函数，我要做的是，让 count 变量成为一个信号，它的值总是下一个可以调用打印函数的 go 函数的序号。

这个序号其实就是启用 goroutine 时，那个当次迭代的序号。也正因为如此，**go 函数实际的执行顺序才会与 go 语句的执行顺序完全一致**。此外，这里的 trigger 函数实现了一种自旋（spinning）。除非发现条件已满足，否则它会不断地进行检查。

因为我依然想让主 goroutine 最后一个运行完毕，所以还需要加一行代码。不过既然有了 trigger函数，我就没有再使用通道。

```go
trigger(10, func(){})
```

调用 trigger 函数完全可以达到相同的效果。由于当所有我手动启用的 goroutine 都运行完毕之后，count的值一定会是10，所以我就把10作为了第一个参数值。又由于我并不想打印这个10，所以我把一个什么都不做的函数作为了第二个参数值。

通过上述的改造，我使得异步发起的go函数得到了同步地（或者说按照既定顺序地）执行。