本文深入探讨Go语言中goroutine与操作系统线程的交互机制。尽管goroutine被多路复用到少量OS线程上，但Go运行时通过GOMAXPROCS控制并发执行的Go代码所使用的线程数。然而，当goroutine执行阻塞式系统调用或C语言调用时，即使GOMAXPROCS设置为1，也可能导致额外OS线程的创建。文章详细区分了不会和会额外消耗线程的阻塞操作类型，并提供了相应的解释。
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 mainimport ( "fmt" "runtime" "time")func main() { // 获取并打印当前的GOMAXPROCS值 fmt.Printf("Initial GOMAXPROCS: %dn", runtime.GOMAXPROCS(0)) // 设置GOMAXPROCS为1 runtime.GOMAXPROCS(1) fmt.Printf("New GOMAXPROCS: %dn", 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: %dn", 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 mainimport ( "fmt" "runtime" "sync" "time")func main() { runtime.GOMAXPROCS(1) // 强制只使用一个OS线程执行Go代码 fmt.Printf("Current GOMAXPROCS: %dn", 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 waitn", id) // 模拟一个sleep操作 time.Sleep(50 * time.Millisecond) // Goroutine在此阻塞，但不会占用OS线程 fmt.Printf("Goroutine %d: Finished sleepn", 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 mainimport ( "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: %dn", 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: %vn", 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: %vn", 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: %dn", 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运行时可能会为此创建额外线程，并据此评估系统的资源消耗。
以上就是深入理解Go语言中Goroutine与操作系统线程的关联及线程创建策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1390203.html
微信扫一扫 
支付宝扫一扫 
