本文探讨了Go语言在多核环境下创建大量空闲Goroutine时，性能反而可能低于单核环境的现象。核心原因在于多核调度引入了更复杂的Go调度器开销和潜在的操作系统级上下文切换，而单核模式下，当主Goroutine不发生阻塞或主动让出CPU时，空闲Goroutine甚至可能从未真正执行，仅涉及高效的内部记账，从而显得更快。
在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 mainimport ( "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都立即进入<-die的等待状态。关键在于，主Goroutine在创建这些子Goroutine的过程中，并没有发生阻塞、系统调用或主动让出CPU（如runtime.Gosched()）。这意味着Go调度器没有机会将CPU从主Goroutine切换到这些新创建的子Goroutine。
立即学习“go语言免费学习笔记（深入）”；
在这种情况下，新创建的Goroutine虽然被分配了内存和调度器结构，但它们从未真正被调度到M上执行。对于Go调度器而言，这仅仅是内部数据结构的创建和维护（即“内部记账”）。由于没有实际的执行、上下文切换（无论是Go层面的还是OS层面的），整个过程非常高效和迅速。一旦close(die)被调用，这些等待的Goroutine会立即退出，它们的资源也很快会被垃圾回收。
多核环境下的额外开销 (GOMAXPROCS(N > 1))
当GOMAXPROCS设置为大于1的值（例如runtime.NumCPU()）时，Go调度器会尝试将Goroutine分布到多个P上，每个P绑定一个操作系统线程M。这种模式下，创建大量Goroutine会引入额外的开销：
网易人工智能
网易数帆多媒体智能生产力平台
206 查看详情 
调度器复杂性增加： Go调度器需要管理多个P，决定哪个Goroutine分配给哪个P，以及何时在P之间迁移Goroutine。这本身就比单P模式涉及更多的逻辑判断和同步开销。操作系统级上下文切换： 当有多个P时，Go调度器会启动多个操作系统线程M。操作系统会根据其自身的调度策略在这些M之间进行上下文切换。操作系统级的上下文切换比Go语言用户态的Goroutine切换要重量级得多，因为它涉及到保存和恢复CPU寄存器、内存映射等，开销显著增加。Goroutine实际执行的可能性： 在多P环境下，即使Goroutine只是等待一个通道，它们也有更大的机会被Go调度器调度到某个M上并开始执行。即使只是执行到<-die这一行代码并进入等待状态，也包含了实际的CPU指令执行和调度器交互，这比单P模式下“从未执行”的情况要消耗更多资源。缓存一致性开销： 多个M在不同CPU核心上运行时，可能涉及到共享内存数据的缓存同步问题，虽然对于本例中的空闲Goroutine影响较小，但也是多核环境下的潜在开销来源。
因此，在多核环境下，创建相同的100,000个空闲Goroutine，由于涉及更复杂的Go调度逻辑、潜在的操作系统级上下文切换以及Goroutine实际执行的开销，整体时间会显著增加。
示例代码分析
让我们再次审视提供的Go代码：
package mainimport ( "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函数中的<-die是一个阻塞操作，它使Goroutine在通道关闭前一直处于等待状态。由于主Goroutine在创建这些子Goroutine期间没有阻塞，也没有主动让出CPU，因此在单核模式下，这些子Goroutine几乎没有被调度执行的机会。然而，在多核模式下，Go调度器会积极地尝试将这些新创建的Goroutine分配到不同的P上，这增加了它们被实际调度和执行（即使只是进入等待状态）的机会，从而引入了上述的额外开销。
性能差异的深层原因
根本原因在于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并发程序，避免在不适用的场景下对性能产生误判。
以上就是深度解析：Go语言Goroutine在多核环境下的创建开销与性能差异的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1139388.html
微信扫一扫 
支付宝扫一扫 
