Go语言从设计之初就把并发作为一等公民，但写出能跑的程序和写出能榨干机器所有CPU核心的程序完全是两回事。很多服务在压测时发现某个核跑到百分之百，其余核心却在围观，本质是对Go运行时的调度模型和资源分配理解不够。要让程序高效利用全部CPU核心，需要从运行时参数、任务拆分、同步开销三个层面系统优化。
理解GOMAXPROCS与多核并行
Go运行时使用GMP模型管理并发：G代表goroutine，M是操作系统线程，P是逻辑处理器。P的数量直接决定了多少个M能同时执行Go代码，而这个数量由runtime.GOMAXPROCS控制。在Go 1.5之后，默认值已经是机器的逻辑CPU数，但容器中若限制了CPU配额，老版本可能读错，需要显式设置。
可以通过一行代码确认并锁定并行度：
package main
import (
"fmt"
"runtime"
)
func main() {
// 显式设置使用所有可用逻辑核心
n := runtime.GOMAXPROCS(0)
fmt.Println("当前P的数量:", n)
}
上面的runtime.GOMAXPROCS(0)返回当前值而不修改它。若程序依赖外部CPU限制（如K8s的requests），建议用runtime.NumCPU()结合环境变量计算后显式传入，避免运行时误判导致部分核心长期空闲。
任务分片避免伪并行
即便P的数量正确，如果把一个巨型循环放在单个goroutine里，其他核心依然无事可做。正确的做法是将数据分片，启动与核心数相当的worker，把计算均摊。下面示例用扇出模式处理切片：
package main
import (
"fmt"
"runtime"
"sync"
)
func process(data []int, workers int) []int {
// 每个worker处理的块大小
chunk := (len(data) + workers - 1) / workers
result := make([]int, len(data))
var wg sync.WaitGroup
for i := 0; i < workers; i++ {
start := i * chunk
if start >= len(data) {
break
}
end := start + chunk
if end > len(data) {
end = len(data)
}
wg.Add(1)
go func(s, e int) {
defer wg.Done()
for idx := s; idx < e; idx++ {
// 模拟CPU密集型计算
result[idx] = data[idx] * data[idx]
}
}(start, end)
}
wg.Wait()
return result
}
func main() {
runtime.GOMAXPROCS(runtime.NumCPU())
data := make([]int, 1000000)
for i := range data {
data[i] = i
}
out := process(data, runtime.NumCPU())
fmt.Println(out[0], out[len(out)-1])
}
这种分片方式让每个核心都拿到连续内存块，减少缓存行跳跃。如果任务本身是IO密集型，worker数可以大于核心数，但CPU密集型时worker数等于核心数往往最优，过多反而增加调度和上下文切换成本。
需要注意，切片和map在并发写时要加锁或使用sync.Map。上面的例子每个goroutine写各自不重叠的result区间，因此无需互斥，这是降低同步开销的关键设计。
减少锁竞争与同步阻塞
多核程序性能崩塌的常见原因是一把大锁让所有P轮流排队。用atomic包做计数器、用channel做所有权转移，都比mutex更轻。下面对比两种累加方式：
| 方式 | 适用场景 | 多核表现 |
|---|---|---|
| sync.Mutex保护共享变量 | 复杂结构修改 | 高竞争时退化成串行 |
| sync/atomic原子操作 | 简单计数、标志位 | 接近线性扩展 |
| 分片计数后汇总 | 高频写入统计 | 各核独立，无冲突 |
分片计数思路是给每个P一个本地计数器，最后求和，类似前面的任务分片。这样写操作完全不跨核同步，是实测中扩展最好的模式。
用pprof验证核心利用率
优化不能靠猜。引入net/http/pprof后，用go tool pprof采集CPU profile，配合top命令看各函数是否分布在多个核心。若发现系统线程数远多于P，或syscall占用高，说明调度被阻塞。
package main
import (
"net/http"
_ "net/http/pprof"
)
func main() {
go func() {
// 暴露调试端口，生产可绑内网
http.ListenAndServe("127.0.0.1:6060", nil)
}()
// 业务逻辑
select {}
}
通过访问127.0.0.1:6060/debug/pprof/拿到数据，能直观看到是否所有核心都在干活。若某个函数占满单核而其他核心空闲，基本就是漏了并发改造。
把GOMAXPROCS设对、任务拆匀、锁降到最低，再用profile收尾验证，Go程序就能把出厂的CPU核心真正变成吞吐量。多核不是自动生效的魔法，而是写代码时每一次分片和每一次避锁的累积结果。
Go并发GOMAXPROCSgoroutine调度修改时间：2026-08-05 00:21:28