gopl-zh.github.com/ch9/ch9-08.md

57 lines
7.7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

## 9.8. Goroutines和线程
在上一章中我们说goroutine和操作系统的线程区别可以先忽略。尽管两者的区别实际上只是一个量的区别但量变会引起质变的道理同样适用于goroutine和线程。现在正是我们来区分开两者的最佳时机。
### 9.8.1. 动态栈
每一个OS线程都有一个固定大小的内存块一般会是2MB来做栈这个栈会用来存储当前正在被调用或挂起指在调用其它函数时的函数的内部变量。这个固定大小的栈同时很大又很小。因为2MB的栈对于一个小小的goroutine来说是很大的内存浪费比如对于我们用到的一个只是用来WaitGroup之后关闭channel的goroutine来说。而对于go程序来说同时创建成百上千个goroutine是非常普遍的如果每一个goroutine都需要这么大的栈的话那这么多的goroutine就不太可能了。除去大小的问题之外固定大小的栈对于更复杂或者更深层次的递归函数调用来说显然是不够的。修改固定的大小可以提升空间的利用率允许创建更多的线程并且可以允许更深的递归调用不过这两者是没法同时兼备的。
相反一个goroutine会以一个很小的栈开始其生命周期一般只需要2KB。一个goroutine的栈和操作系统线程一样会保存其活跃或挂起的函数调用的本地变量但是和OS线程不太一样的是一个goroutine的栈大小并不是固定的栈的大小会根据需要动态地伸缩。而goroutine的栈的最大值有1GB比传统的固定大小的线程栈要大得多尽管一般情况下大多goroutine都不需要这么大的栈。
**练习 9.4:** 创建一个流水线程序支持用channel连接任意数量的goroutine在跑爆内存之前可以创建多少流水线阶段一个变量通过整个流水线需要用多久这个练习题翻译不是很确定
### 9.8.2. Goroutine调度
OS线程会被操作系统内核调度。每几毫秒一个硬件计时器会中断处理器这会调用一个叫作scheduler的内核函数。这个函数会挂起当前执行的线程并将它的寄存器内容保存到内存中检查线程列表并决定下一次哪个线程可以被运行并从内存中恢复该线程的寄存器信息然后恢复执行该线程的现场并开始执行线程。因为操作系统线程是被内核所调度所以从一个线程向另一个“移动”需要完整的上下文切换也就是说保存一个用户线程的状态到内存恢复另一个线程的到寄存器然后更新调度器的数据结构。这几步操作很慢因为其局部性很差需要几次内存访问并且会增加运行的cpu周期。
Go的运行时包含了其自己的调度器这个调度器使用了一些技术手段比如m:n调度因为其会在n个操作系统线程上多工调度m个goroutine。Go调度器的工作和内核的调度是相似的但是这个调度器只关注单独的Go程序中的goroutine译注按程序独立
和操作系统的线程调度不同的是Go调度器并不是用一个硬件定时器而是被Go语言“建筑”本身进行调度的。例如当一个goroutine调用了time.Sleep或者被channel调用或者mutex操作阻塞时调度器会使其进入休眠并开始执行另一个goroutine直到时机到了再去唤醒第一个goroutine。因为这种调度方式不需要进入内核的上下文所以重新调度一个goroutine比调度一个线程代价要低得多。
**练习 9.5:** 写一个有两个goroutine的程序两个goroutine会向两个无buffer channel反复地发送ping-pong消息。这样的程序每秒可以支持多少次通信
### 9.8.3. GOMAXPROCS
Go的调度器使用了一个叫做GOMAXPROCS的变量来决定会有多少个操作系统的线程同时执行Go的代码。其默认的值是运行机器上的CPU的核心数所以在一个有8个核心的机器上时调度器一次会在8个OS线程上去调度GO代码。GOMAXPROCS是前面说的m:n调度中的n。在休眠中的或者在通信中被阻塞的goroutine是不需要一个对应的线程来做调度的。在I/O中或系统调用中或调用非Go语言函数时是需要一个对应的操作系统线程的但是GOMAXPROCS并不需要将这几种情况计算在内。
你可以用GOMAXPROCS的环境变量来显式地控制这个参数或者也可以在运行时用runtime.GOMAXPROCS函数来修改它。我们在下面的小程序中会看到GOMAXPROCS的效果这个程序会无限打印0和1。
```go
for {
go fmt.Print(0)
fmt.Print(1)
}
$ GOMAXPROCS=1 go run hacker-cliché.go
111111111111111111110000000000000000000011111...
$ GOMAXPROCS=2 go run hacker-cliché.go
010101010101010101011001100101011010010100110...
```
在第一次执行时最多同时只能有一个goroutine被执行。初始情况下只有main goroutine被执行所以会打印很多1。过了一段时间后GO调度器会将其置为休眠并唤醒另一个goroutine这时候就开始打印很多0了在打印的时候goroutine是被调度到操作系统线程上的。在第二次执行时我们使用了两个操作系统线程所以两个goroutine可以一起被执行以同样的频率交替打印0和1。我们必须强调的是goroutine的调度是受很多因子影响的而runtime也是在不断地发展演进的所以这里的你实际得到的结果可能会因为版本的不同而与我们运行的结果有所不同。
**练习9.6:** 测试一下计算密集型的并发程序练习8.5那样的会被GOMAXPROCS怎样影响到。在你的电脑上最佳的值是多少你的电脑CPU有多少个核心
### 9.8.4. Goroutine没有ID号
在大多数支持多线程的操作系统和程序语言中当前的线程都有一个独特的身份id并且这个身份信息可以以一个普通值的形式被很容易地获取到典型的可以是一个integer或者指针值。这种情况下我们做一个抽象化的thread-local storage线程本地存储多线程编程中不希望其它线程访问的内容就很容易只需要以线程的id作为key的一个map就可以解决问题每一个线程以其id就能从中获取到值且和其它线程互不冲突。
goroutine没有可以被程序员获取到的身份id的概念。这一点是设计上故意而为之由于thread-local storage总是会被滥用。比如说一个web server是用一种支持tls的语言实现的而非常普遍的是很多函数会去寻找HTTP请求的信息这代表它们就是去其存储层这个存储层有可能是tls查找的。这就像是那些过分依赖全局变量的程序一样会导致一种非健康的“距离外行为”在这种行为下一个函数的行为可能并不仅由自己的参数所决定而是由其所运行在的线程所决定。因此如果线程本身的身份会改变——比如一些worker线程之类的——那么函数的行为就会变得神秘莫测。
Go鼓励更为简单的模式这种模式下参数译注外部显式参数和内部显式参数。tls 中的内容算是"外部"隐式参数)对函数的影响都是显式的。这样不仅使程序变得更易读,而且会让我们自由地向一些给定的函数分配子任务时不用担心其身份信息影响行为。
你现在应该已经明白了写一个Go程序所需要的所有语言特性信息。在后面两章节中我们会回顾一些之前的实例和工具支持我们写出更大规模的程序如何将一个工程组织成一系列的包如何获取构建测试性能测试剖析写文档并且将这些包分享出去。