Goroutine与操作系统线程概述
Go语言的并发模型基于轻量级的“goroutine”。Goroutine并非操作系统线程，而是由Go运行时（runtime）管理的绿色线程。Go运行时负责将大量的goroutine多路复用到少量底层操作系统（OS）线程上执行。这种机制使得Go程序能够高效地处理大量并发任务，而无需承担传统线程模型中上下文切换和资源消耗的巨大开销。
当一个goroutine因为等待I/O或执行其他阻塞操作而暂停时，Go调度器能够将该goroutine从当前OS线程上移除，并调度另一个可运行的goroutine到该线程上执行，从而最大限度地利用OS线程的计算能力。
GOMAXPROCS的作用
GOMAXPROCS是一个环境变量或通过runtime.GOMAXPROCS()函数设置的参数，它决定了Go运行时调度器可以同时执行Go代码的最大操作系统线程数。简单来说，GOMAXPROCS控制了Go程序在任意时刻能够并行运行的Go代码（CPU密集型任务）的数量。
例如，如果GOMAXPROCS设置为4，那么Go运行时将尝试使用最多4个OS线程来执行可运行的goroutine。这意味着，对于CPU密集型任务，即使有成千上万个goroutine，也只有最多4个goroutine能够真正地并行计算。
立即学习“go语言免费学习笔记（深入）”；
package main
import (
"fmt"
"runtime"
"time"
)
func main() {
// 获取并打印当前的GOMAXPROCS值
fmt.Printf("Initial GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))
// 设置GOMAXPROCS为1
runtime.GOMAXPROCS(1)
fmt.Printf("New GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))
// 启动多个goroutine执行CPU密集型任务
for i := 0; i < 10; i++ {
go func(id int) {
sum := 0
for j := 0; j < 1e7; j++ { // 模拟CPU密集型计算
sum += j
}
fmt.Printf("Goroutine %d finished calculation. Sum: %d\n", id, sum)
}(i)
}
// 等待goroutines完成
time.Sleep(2 * time.Second)
fmt.Println("All goroutines launched.")
}在上述代码中，尽管启动了10个goroutine，但如果GOMAXPROCS设置为1，它们将会在一个OS线程上进行并发调度执行，而不是并行执行。
阻塞操作对线程使用的影响
理解GOMAXPROCS的限制非常重要，但更关键的是要区分不同类型的阻塞操作对OS线程使用的影响。并不是所有的阻塞都会导致额外的OS线程被创建。
1. 不会导致额外线程消耗的阻塞操作
当goroutine执行以下类型的阻塞操作时，Go运行时能够智能地处理，不会导致该goroutine持续占用一个OS线程，也不会因此创建新的OS线程来维持GOMAXPROCS所设定的并行度：
- Channel操作：
- 网络操作： Go标准库中的网络I/O（如net.Dial、conn.Read、conn.Write）通常是非阻塞的，并通过网络轮询器（netpoller）实现，当网络操作阻塞时，goroutine会被挂起，OS线程可以被其他goroutine使用。
- 时间等待： time.Sleep() 或 time.After() 等定时器操作。
- sync 包中的原语： 如sync.Mutex、sync.WaitGroup、sync.Cond等。当goroutine等待这些同步原语时，它会被挂起，但不会独占OS线程。
在这些情况下，Go调度器会将阻塞的goroutine从当前OS线程上“取下”，然后将该OS线程分配给其他可运行的goroutine。当阻塞操作完成后，该goroutine会重新变为可运行状态，等待调度器将其重新分配到某个OS线程上。
package main
import (
"fmt"
"runtime"
"sync"
"time"
)
func main() {
runtime.GOMAXPROCS(1) // 强制只使用一个OS线程执行Go代码
fmt.Printf("Current GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))
var wg sync.WaitGroup
for i := 0; i < 5; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
fmt.Printf("Goroutine %d: Starting (on OS thread %d)\n", id, runtime.NumGoroutine()) // NumGoroutine is not thread ID
// 模拟一个channel阻塞操作
ch := make(chan struct{})
go func() {
time.Sleep(50 * time.Millisecond) // 模拟异步操作
close(ch)
}()
<-ch // Goroutine在此阻塞，但不会占用OS线程
fmt.Printf("Goroutine %d: Finished channel wait\n", id)
// 模拟一个sleep操作
time.Sleep(50 * time.Millisecond) // Goroutine在此阻塞，但不会占用OS线程
fmt.Printf("Goroutine %d: Finished sleep\n", id)
}(i)
}
wg.Wait()
fmt.Println("All goroutines finished.")
}尽管GOMAXPROCS设置为1，并且有多个goroutine在
2. 会导致额外线程消耗的阻塞操作
当goroutine执行以下类型的阻塞操作时，Go运行时无法将OS线程从该goroutine中解耦，因为这些操作直接导致底层的OS线程进入阻塞状态。为了维持GOMAXPROCS所设定的并行度（即确保有足够多的OS线程来执行可运行的Go代码），Go运行时会创建新的OS线程来弥补被阻塞的线程：
-
阻塞式系统调用（Syscalls）： 当goroutine直接调用操作系统提供的阻塞式API时，例如：
- 读取阻塞设备文件（如/dev/ttyxx或串口）。
- 通过os.Exec启动外部进程并等待其完成（cmd.Wait()）。
- 某些文件I/O操作在特定操作系统或模式下可能是阻塞的。
- 调用C语言代码（CGO）并阻塞： 当Go代码通过CGO调用C语言函数，并且该C函数内部执行了阻塞操作（如sleep()、阻塞式I/O、或等待外部资源），那么Go运行时也无法控制这个阻塞，对应的OS线程将被C代码占用。
在这种情况下，即使GOMAXPROCS设置为1，如果有一个goroutine执行了阻塞式系统调用，Go运行时会发现一个OS线程被“卡住”了，为了不影响其他可运行goroutine的执行，它会启动一个新的OS线程来继续调度其他goroutine，直到阻塞的系统调用完成。
package main
import (
"fmt"
"io/ioutil"
"os"
"runtime"
"sync"
"time"
)
// #include // For sleep
// void c_sleep(int seconds) {
// sleep(seconds);
// }
import "C"
func main() {
runtime.GOMAXPROCS(1) // 强制只使用一个OS线程执行Go代码
fmt.Printf("Current GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))
var wg sync.WaitGroup
wg.Add(2)
// Goroutine 1: 模拟阻塞式系统调用 (读取/dev/random)
go func() {
defer wg.Done()
fmt.Println("Goroutine 1: Starting blocking syscall (reading /dev/random)...")
// 注意: /dev/random在某些系统上可能会阻塞，直到有足够的熵
// 在Windows上，可以尝试其他阻塞文件I/O，如等待管道输入
file, err := os.Open("/dev/random") // 这是一个可能阻塞的系统调用
if err != nil {
fmt.Printf("Goroutine 1: Error opening /dev/random: %v\n", err)
return
}
defer file.Close()
buffer := make([]byte, 1)
_, err = file.Read(buffer) // 此处可能导致OS线程阻塞
if err != nil {
fmt.Printf("Goroutine 1: Error reading /dev/random: %v\n", err)
return
}
fmt.Println("Goroutine 1: Finished blocking syscall.")
}()
// Goroutine 2: 模拟CGO阻塞调用
go func() {
defer wg.Done()
fmt.Println("Goroutine 2: Starting blocking CGO call...")
C.c_sleep(1) // 调用C函数，该函数会阻塞其所在的OS线程
fmt.Println("Goroutine 2: Finished blocking CGO call.")
}()
// 观察OS线程数量的变化
go func() {
for i := 0; i < 5; i++ {
time.Sleep(200 * time.Millisecond)
// NumCPU不是线程数，NumGoroutine是goroutine数。
// 无法直接在Go代码中获取当前OS线程数，但可以通过系统工具观察。
// 期望在阻塞期间，OS线程数会增加。
fmt.Printf("Current Go routines: %d\n", runtime.NumGoroutine())
}
}()
wg.Wait()
fmt.Println("All blocking goroutines finished.")
time.Sleep(1 * time.Second) // 留一些时间让运行时清理
} 在上述示例中，当Goroutine 1执行file.Read(buffer)或Goroutine 2执行C.c_sleep(1)时，它们所在的OS线程会直接阻塞。由于GOMAXPROCS设置为1，Go运行时为了保证仍有一个OS线程用于执行其他可能的Go代码，会额外启动新的OS线程。通过系统监控工具（如Linux的top -H或ps -T，macOS的htop或Activity Monitor），可以观察到Go进程的线程数在这些阻塞操作发生时会增加。
总结与注意事项
- Goroutine数量不等于OS线程数量： 创建大量goroutine本身并不会直接导致创建等量的OS线程。goroutine被高效地多路复用到少量OS线程上。
- GOMAXPROCS控制并行度： 它设定了Go运行时同时执行Go代码（非阻塞、计算密集型）的最大OS线程数。
- 阻塞行为是关键： 只有当goroutine执行阻塞式系统调用或阻塞式CGO调用时，才会迫使Go运行时创建额外的OS线程，以确保GOMAXPROCS所设定的并行度能够被维持。
- Go运行时优化： 对于Go内部的阻塞操作（如channel、网络I/O、sync原语、time.Sleep），Go运行时能够智能地将goroutine从OS线程上解耦，避免额外的线程创建。
理解这些机制对于编写高效、可伸缩的Go程序至关重要。在设计高并发系统时，应尽量避免在goroutine中直接执行长时间的阻塞式系统调用或CGO调用，或者通过异步化、非阻塞I/O等方式来处理，以避免不必要的OS线程创建和上下文切换开销。如果确实需要执行这类阻塞操作，应预见到Go运行时可能会为此创建额外线程，并据此评估系统的资源消耗。
