1. 现象观察与示例代码
在go语言中，我们通常期望利用多核cpu来提升并发程序的性能。然而，在某些特定场景下，例如快速创建大量不执行实际计算的空闲goroutine时，将go运行时配置为使用多个cpu核心（gomaxprocs > 1）反而可能导致程序执行时间增加，甚至比单核（gomaxprocs = 1）配置更慢。
考虑以下Go程序，它创建了十万个Goroutine，每个Goroutine立即阻塞在一个通道上，等待主Goroutine关闭通道以终止。
package main
import (
"fmt"
"runtime"
"time"
)
// waitAround 函数接收一个 channel，并在此 channel 上阻塞，直到它被关闭。
func waitAround(die chan bool) {
<-die
}
func main() {
var startMemory runtime.MemStats
runtime.ReadMemStats(&startMemory) // 记录初始内存使用情况
start := time.Now()
cpus := runtime.NumCPU() // 获取系统CPU核心数
// 设置 Go 运行时可使用的最大 CPU 核心数
// 尝试将此行改为 runtime.GOMAXPROCS(1) 进行对比
runtime.GOMAXPROCS(cpus) // 通常设置为系统核心数，以利用多核
die := make(chan bool) // 创建一个用于控制 Goroutine 终止的 channel
count := 100000 // 要创建的 Goroutine 数量
// 循环创建大量 Goroutine
for i := 0; i < count; i++ {
go waitAround(die)
}
elapsed := time.Since(start) // 记录 Goroutine 创建所花费的时间
var endMemory runtime.MemStats
runtime.ReadMemStats(&endMemory) // 记录结束时内存使用情况
fmt.Printf("启动了 %d 个 Goroutine\n%d 个 CPU 核心\n耗时 %f 秒\n",
count, cpus, elapsed.Seconds())
fmt.Printf("启动前内存分配 %d 字节\n启动后内存分配 %d 字节\n", startMemory.Alloc,
endMemory.Alloc)
fmt.Printf("当前运行中的 Goroutine 数量 %d\n", runtime.NumGoroutine())
// 计算每个 Goroutine 的大致内存开销
fmt.Printf("每个 Goroutine 大约占用 %d 字节\n", (endMemory.Alloc-startMemory.Alloc)/uint64(runtime.NumGoroutine()))
close(die) // 关闭 channel，释放所有阻塞的 Goroutine
}当在多核系统上运行上述代码时，如果 runtime.GOMAXPROCS 设置为系统核心数（例如 runtime.GOMAXPROCS(cpus)），程序可能会比设置为 runtime.GOMAXPROCS(1) 时执行得更慢。例如，在某些环境下，多核配置可能耗时0.5秒，而单核配置仅耗时0.15秒。这种反直觉的性能表现，促使我们深入探究Go调度器在不同核心配置下的行为差异。
2. Go调度器机制解析
Go语言的调度器负责将Goroutine映射到操作系统线程上执行。其核心模型是M-P-G模型：
- G (Goroutine)：Go语言中的并发执行单元。
- P (Processor)：一个逻辑处理器，代表一个执行Goroutine的上下文，它持有一个Goroutine队列。GOMAXPROCS 的值决定了可用的P的数量。
- M (Machine/OS Thread)：一个操作系统线程，负责执行P上的Goroutine。
2.1 单核（GOMAXPROCS = 1）下的行为
当 runtime.GOMAXPROCS(1) 被设置时，Go运行时将只使用一个P和一个M。在这种配置下，Goroutine的创建和调度开销显著降低，主要原因如下：
- 内部记账，无实际调度切换： 在我们的示例中，主Goroutine快速地创建了十万个 waitAround Goroutine。这些新创建的Goroutine立即阻塞在 die 通道上。由于只有一个P，并且主Goroutine一直在忙于创建新的Goroutine，它不会主动让出CPU。这意味着，在Go的早期版本中，这些新创建的、阻塞的Goroutine甚至可能从未被调度到M上执行。它们仅仅是作为数据结构被分配到内存中，并被添加到P的本地运行队列或全局运行队列中。
- 避免操作系统级上下文切换： 由于只有一个M，Go调度器无需协调多个操作系统线程之间的工作。所有的Goroutine操作（创建、入队、标记阻塞等）都发生在同一个M的上下文内，避免了昂贵的操作系统级上下文切换和同步原语。
- 无抢占开销： 在某些Go版本和特定场景下，如果Goroutine不执行系统调用或不主动让出，它可能不会被抢占。在单P/M模型下，主Goroutine的持续运行进一步减少了调度器介入进行抢占的必要性。
因此，在单核模式下，创建这些空闲Goroutine主要表现为Go运行时内部的数据结构分配和链表操作，其效率非常高。
2.2 多核（GOMAXPROCS > 1）下的行为
当 runtime.GOMAXPROCS 设置为大于1的值时，Go运行时会创建多个P，并可能使用多个M来并行执行Goroutine。这引入了额外的复杂性和开销：
- 多P/M协调开销： Go调度器现在需要管理多个P，并将Goroutine分发到这些P上。当一个Goroutine被创建时，调度器需要决定将其放置到哪个P的本地运行队列，或者全局运行队列中。这个过程涉及锁竞争、原子操作以及内存同步，以确保不同P之间的数据一致性，这本身就是一种开销。
- 操作系统级上下文切换： 每个P通常会绑定到一个M上。当多个M同时运行时，它们可能会争夺CPU资源。操作系统会介入进行线程调度，导致昂贵的操作系统级上下文切换。即使Goroutine是空闲的，M也可能在尝试获取可运行的Goroutine时被操作系统调度。
- Goroutine实际执行的可能性增加： 在多P/M模型下，新创建的Goroutine更有可能在主Goroutine完成所有创建操作之前被调度到某个M上执行。即使 waitAround Goroutine只是阻塞，其被调度、执行
- 缓存一致性问题： 当多个M在不同的CPU核心上运行时，它们会操作共享内存（例如Goroutine的数据结构、通道等）。这可能导致CPU缓存的频繁失效和同步，进一步降低性能。
3. 注意事项与总结
这种“多核反而更慢”的现象并非Go语言的普遍缺陷，而是在特定场景下，Goroutine调度器在协调并发资源时所产生的固有开销。
- 场景特定性：这种性能下降主要发生在 Goroutine 被快速创建，但几乎不执行任何计算，而是立即进入阻塞状态的场景。它揭示的是Go调度器在 管理和协调 大量并发单元时的开销，而非执行 实际并发计算 的开销。
- 实际工作负载：对于执行实际计算的 Goroutine，GOMAXPROCS 设置为系统核心数通常能显著提升性能。因为此时计算的并行化收益远大于调度开销。
- Go版本演进：Go调度器在不断优化。例如，Go 1.14及更高版本引入了非协作式抢占，这可能改变Goroutine在单P/M模型下的行为，使得Goroutine即使不主动让出也可能被抢占。然而，多P/M带来的协调开销仍然是存在的。
- 诊断工具：当遇到类似的性能问题时，可以使用Go的内置pprof工具进行CPU和内存分析，以找出热点。此外，像 strace 这样的系统调用跟踪工具，可以帮助我们观察程序在不同 GOMAXPROCS 配置下与操作系统的交互差异，从而深入理解其底层行为。
结论：在Go语言中，GOMAXPROCS 的默认值（通常是 runtime.NumCPU()）对于大多数CPU密集型或I/O密集型应用来说是最佳选择。然而，理解调度器在极端场景下的行为，如本例所示的空闲Goroutine快速创建，有助于我们更深入地掌握Go并发模型的内部工作原理，并在必要时进行精细调优。在实践中，我们应始终基于实际工作负载进行性能测试和分析，而不是仅仅依赖于直觉。
