在go语言的并发编程中，goroutine是轻量级的执行单元，其创建和调度通常被认为是高效的。然而，在某些特定场景下，尤其是在多核处理器环境中创建大量“空闲”goroutine时，我们可能会观察到一个反直觉的现象：其性能反而不如在单核模式下运行。这并非go语言或多核处理器的固有缺陷，而是go调度器在不同运行模式下处理goroutine生命周期的机制差异所致。
Go语言通过其用户态调度器（GPM模型）来管理Goroutine的执行。其中：
runtime.GOMAXPROCS(n)函数设置了同时执行Go代码的操作系统线程（M）的最大数量，也即P的数量。当n大于1时，Go调度器会尝试将Goroutine分布到多个P上，从而利用多核并行执行。
当我们将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都立即进入<-die的等待状态。关键在于，主Goroutine在创建这些子Goroutine的过程中，并没有发生阻塞、系统调用或主动让出CPU（如runtime.Gosched()）。这意味着Go调度器没有机会将CPU从主Goroutine切换到这些新创建的子Goroutine。
立即学习“go语言免费学习笔记（深入）”；
在这种情况下，新创建的Goroutine虽然被分配了内存和调度器结构，但它们从未真正被调度到M上执行。对于Go调度器而言，这仅仅是内部数据结构的创建和维护（即“内部记账”）。由于没有实际的执行、上下文切换（无论是Go层面的还是OS层面的），整个过程非常高效和迅速。一旦close(die)被调用，这些等待的Goroutine会立即退出，它们的资源也很快会被垃圾回收。
当GOMAXPROCS设置为大于1的值（例如runtime.NumCPU()）时，Go调度器会尝试将Goroutine分布到多个P上，每个P绑定一个操作系统线程M。这种模式下，创建大量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函数中的<-die是一个阻塞操作，它使Goroutine在通道关闭前一直处于等待状态。由于主Goroutine在创建这些子Goroutine期间没有阻塞，也没有主动让出CPU，因此在单核模式下，这些子Goroutine几乎没有被调度执行的机会。然而，在多核模式下，Go调度器会积极地尝试将这些新创建的Goroutine分配到不同的P上，这增加了它们被实际调度和执行（即使只是进入等待状态）的机会，从而引入了上述的额外开销。
根本原因在于Go调度器在不同GOMAXPROCS设置下的行为模式以及操作系统线程调度介入的程度。
Go语言在多核环境下创建大量空闲Goroutine时，性能可能不如单核环境，这并非Go调度器效率低下，而是其在多核模式下为实现并发执行所付出的必要开销。单核模式下，在主Goroutine不让出CPU的特定情境中，新创建的空闲Goroutine可能从未真正执行，仅涉及高效的内部记账。而多核模式则引入了更复杂的Go调度器管理、潜在的操作系统级上下文切换以及Goroutine实际执行的开销。理解这些底层机制有助于我们更合理地设计和优化Go并发程序，避免在不适用的场景下对性能产生误判。
以上就是深度解析：Go语言Goroutine在多核环境下的创建开销与性能差异的详细内容，更多请关注php中文网其它相关文章！
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
732
收藏
