本文深入探讨了Go语言中，当快速创建大量空闲Goroutine时，多核（GOMAXPROCS > 1）环境相较于单核（GOMAXPROCS = 1）环境可能出现性能下降的现象。我们将通过代码示例分析其背后的Go调度器机制，包括内部记账、操作系统级上下文切换、以及多P/M模型带来的协调开销，揭示这种反直觉行为的根源，并提供相应的理解与注意事项。
1. 现象观察与示例代码
在go语言中，我们通常期望利用多核cpu来提升并发程序的性能。然而，在某些特定场景下，例如快速创建大量不执行实际计算的空闲goroutine时，将go运行时配置为使用多个cpu核心（gomaxprocs > 1）反而可能导致程序执行时间增加，甚至比单核（gomaxprocs = 1）配置更慢。
考虑以下Go程序，它创建了十万个Goroutine，每个Goroutine立即阻塞在一个通道上，等待主Goroutine关闭通道以终止。
package mainimport ( "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运行时内部的数据结构分配和链表操作，其效率非常高。
大师兄智慧家政
58到家打造的AI智能营销工具
99 查看详情 
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只是阻塞，其被调度、执行 <-die 操作（这可能涉及对通道的内存操作和等待队列的修改），然后进入阻塞状态，这一系列过程都比单核下纯粹的内部记账要复杂和耗时。缓存一致性问题：当多个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并发模型的内部工作原理，并在必要时进行精细调优。在实践中，我们应始终基于实际工作负载进行性能测试和分析，而不是仅仅依赖于直觉。
以上就是Go Goroutine创建效率探究：多核环境下的调度开销分析的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1139524.html
微信扫一扫 
支付宝扫一扫 
