在go语言的并发编程中，goroutine是轻量级的执行单元，其创建和调度通常被认为是高效的。然而，在某些特定场景下，尤其是在多核处理器环境中创建大量“空闲”goroutine时，我们可能会观察到一个反直觉的现象：其性能反而不如在单核模式下运行。这并非go语言或多核处理器的固有缺陷，而是go调度器在不同运行模式下处理goroutine生命周期的机制差异所致。
Go调度器与GOMAXPROCS
Go语言通过其用户态调度器（GPM模型）来管理Goroutine的执行。其中：
- G (Goroutine)：Go程序中的并发执行单元。
- M (Machine)：一个操作系统线程，负责执行Go代码。
- P (Processor)：一个逻辑处理器，代表一个M可以执行Go代码的上下文。P的数量由runtime.GOMAXPROCS()控制，默认值是CPU核心数。
runtime.GOMAXPROCS(n)函数设置了同时执行Go代码的操作系统线程（M）的最大数量，也即P的数量。当n大于1时，Go调度器会尝试将Goroutine分布到多个P上，从而利用多核并行执行。
单核环境下的Goroutine创建效率 (GOMAXPROCS(1))
当我们将GOMAXPROCS设置为1时，Go调度器只有一个P可用。这意味着所有的Goroutine都将由一个操作系统线程（M）来执行。在本文讨论的特定场景中，例如以下示例代码：
package main
import (
"fmt"
"runtime"
"time"
)
func waitAround(die chan bool) {
<-die // Goroutine在此等待，不执行任何计算或I/O
}
func main() {
var startMemory runtime.MemStats
runtime.ReadMemStats(&startMemory)
start := time.Now()
// cpus := runtime.NumCPU()
runtime.GOMAXPROCS(1) // 强制单核运行
die := make(chan bool)
count := 100000
for i := 0; i < count; i++ {
go waitAround(die)
}
elapsed := time.Since(start)
var endMemory runtime.MemStats
runtime.ReadMemStats(&endMemory)
fmt.Printf("Started %d goroutines\n%d CPUs\n%f seconds\n",
count, 1, elapsed.Seconds())
fmt.Printf("Memory before %d\nmemory after %d\n", startMemory.Alloc,
endMemory.Alloc)
fmt.Printf("%d goroutines running\n", runtime.NumGoroutine())
fmt.Printf("%d bytes per goroutine\n", (endMemory.Alloc-startMemory.Alloc)/uint64(runtime.NumGoroutine()))
close(die)
}在上述代码中，主Goroutine连续创建了100,000个Goroutine，每个Goroutine都立即进入
立即学习“go语言免费学习笔记（深入）”；
在这种情况下，新创建的Goroutine虽然被分配了内存和调度器结构，但它们从未真正被调度到M上执行。对于Go调度器而言，这仅仅是内部数据结构的创建和维护（即“内部记账”）。由于没有实际的执行、上下文切换（无论是Go层面的还是OS层面的），整个过程非常高效和迅速。一旦close(die)被调用，这些等待的Goroutine会立即退出，它们的资源也很快会被垃圾回收。
多核环境下的额外开销 (GOMAXPROCS(N > 1))
当GOMAXPROCS设置为大于1的值（例如runtime.NumCPU()）时，Go调度器会尝试将Goroutine分布到多个P上，每个P绑定一个操作系统线程M。这种模式下，创建大量Goroutine会引入额外的开销：
- 调度器复杂性增加： Go调度器需要管理多个P，决定哪个Goroutine分配给哪个P，以及何时在P之间迁移Goroutine。这本身就比单P模式涉及更多的逻辑判断和同步开销。
- 操作系统级上下文切换： 当有多个P时，Go调度器会启动多个操作系统线程M。操作系统会根据其自身的调度策略在这些M之间进行上下文切换。操作系统级的上下文切换比Go语言用户态的Goroutine切换要重量级得多，因为它涉及到保存和恢复CPU寄存器、内存映射等，开销显著增加。
- Goroutine实际执行的可能性： 在多P环境下，即使Goroutine只是等待一个通道，它们也有更大的机会被Go调度器调度到某个M上并开始执行。即使只是执行到
- 缓存一致性开销： 多个M在不同CPU核心上运行时，可能涉及到共享内存数据的缓存同步问题，虽然对于本例中的空闲Goroutine影响较小，但也是多核环境下的潜在开销来源。
因此，在多核环境下，创建相同的100,000个空闲Goroutine，由于涉及更复杂的Go调度逻辑、潜在的操作系统级上下文切换以及Goroutine实际执行的开销，整体时间会显著增加。
示例代码分析
让我们再次审视提供的Go代码：
package main
import (
"fmt"
"runtime"
"time"
)
func waitAround(die chan bool) {
<- die // Goroutine在此等待
}
func main() {
var startMemory runtime.MemStats
runtime.ReadMemStats(&startMemory)
start := time.Now()
cpus := runtime.NumCPU()
runtime.GOMAXPROCS(cpus) // 设置为多核运行
die := make(chan bool)
count := 100000
for i := 0; i < count; i++ {
go waitAround(die) // 创建大量Goroutine
}
elapsed := time.Since(start)
var endMemory runtime.MemStats
runtime.ReadMemStats(&endMemory)
fmt.Printf("Started %d goroutines\n%d CPUs\n%f seconds\n",
count, cpus, elapsed.Seconds())
fmt.Printf("Memory before %d\nmemory after %d\n", startMemory.Alloc,
endMemory.Alloc)
fmt.Printf("%d goroutines running\n", runtime.NumGoroutine())
fmt.Printf("%d bytes per goroutine\n", (endMemory.Alloc-startMemory.Alloc)/uint64(runtime.NumGoroutine()))
close(die)
}这段代码通过runtime.GOMAXPROCS(cpus)将Go调度器配置为使用所有可用的CPU核心。waitAround函数中的
性能差异的深层原因
根本原因在于Go调度器在不同GOMAXPROCS设置下的行为模式以及操作系统线程调度介入的程度。
- 单核模式（GOMAXPROCS(1)）：在主Goroutine不主动让出CPU的情况下，新创建的空闲Goroutine实际上只是在Go调度器的内部队列中注册，并分配了必要的栈空间和数据结构。它们并未真正获得CPU执行权，因此避免了任何实际的调度开销和操作系统上下文切换。这是一种非常高效的“记账”过程。
- 多核模式（GOMAXPROCS(N > 1)）：Go调度器会努力将Goroutine分布到多个M上。这种分布必然会增加调度器自身的复杂性，并引入操作系统在不同M之间进行上下文切换的开销。即使Goroutine只是执行到阻塞点，这个过程也比单核模式下“从未执行”要消耗更多资源。
注意事项与实践建议
- 场景特殊性： 这种“多核慢于单核”的现象是针对大量创建空闲Goroutine，且主Goroutine不发生阻塞或主动让出CPU的特定场景。对于执行实际计算或I/O操作的Goroutine，多核并行处理通常会带来显著的性能提升。
- Go调度器演进： Go语言的调度器一直在演进，例如Go 1.14引入了异步抢占，这使得长时间运行的Goroutine更容易被抢占。但这并不会根本改变上述核心机制：在主Goroutine不让出CPU的极端情况下，单核仍可能因为“不调度”而显得更快。
- 性能分析工具： 当遇到性能问题时，应使用pprof、strace（Linux下）等工具进行深入分析。例如，strace可以显示程序进行的系统调用，通过对比GOMAXPROCS(1)和GOMAXPROCS(cpus)下的strace输出，可以直观地看到多核模式下可能涉及更多的系统调用（如与线程调度相关的）。
- 避免过度优化： 通常情况下，我们不应手动设置GOMAXPROCS，而是让其保持默认值（CPU核心数），以充分利用多核处理器的并行能力。只有在经过详细性能分析后，确认是调度器配置导致的问题，才考虑调整。
总结
Go语言在多核环境下创建大量空闲Goroutine时，性能可能不如单核环境，这并非Go调度器效率低下，而是其在多核模式下为实现并发执行所付出的必要开销。单核模式下，在主Goroutine不让出CPU的特定情境中，新创建的空闲Goroutine可能从未真正执行，仅涉及高效的内部记账。而多核模式则引入了更复杂的Go调度器管理、潜在的操作系统级上下文切换以及Goroutine实际执行的开销。理解这些底层机制有助于我们更合理地设计和优化Go并发程序，避免在不适用的场景下对性能产生误判。
