Go处理CPU密集任务需设GOMAXPROCS为逻辑核数并按核数分块计算，避免小粒度goroutine泛滥引发调度开销与缓存失效。
Go语言在处理CPU密集型任务时，单纯依赖多协程（goroutine）并不能自动提升性能——因为goroutine是调度在OS线程上的，而默认情况下Go运行时只使用一个OS线程（受GOMAXPROCS控制）。要真正压满多核CPU，必须显式调整并发粒度和系统资源绑定。
理解GOMAXPROCS的作用与合理设置
GOMAXPROCS决定了Go运行时可同时执行用户级Go代码的操作系统线程数。它不是协程数量上限，而是“并行执行”的最大P（Processor）数量。默认值通常是机器逻辑CPU核心数，但某些场景下需手动调整：
- 若任务纯CPU计算、无I/O阻塞，建议设为
runtime.NumCPU()，确保充分利用所有核心 - 若混合了较多同步I/O或锁竞争，盲目设高可能增加调度开销，反而降低吞吐
- 可通过
runtime.GOMAXPROCS(n)在程序启动时设置，一般只需设一次
避免“伪并发”：CPU任务别误用channel+goroutine做简单分发
常见误区是把一个大计算任务切分成1000个goroutine扔进channel，以为能并发加速——结果可能更慢。原因在于：
- goroutine创建/调度本身有开销，小粒度任务中占比过高
- 若未限制并发数，大量goroutine争抢P，引发频繁上下文切换
- CPU缓存局部性被破坏，数据在不同核心间反复迁移
✅ 正确做法：按CPU核心数分块（如8核就分8份），每份由一个goroutine独立计算，用sync.WaitGroup等待结束。
立即学习“go语言免费学习笔记（深入）”；
示例：并行计算数组平方和（真实CPU密集）
下面是一个典型优化写法：
func parallelSumSquares(data []int) int64 {
n := runtime.NumCPU()
runtime.GOMAXPROCS(n) // 显式启用全部核心
chunkSize := (len(data) + n - 1) / n
var wg sync.WaitGroup
var total int64
var mu sync.Mutex
for i := 0; i < n; i++ {
wg.Add(1)
start := i * chunkSize
end := min(start+chunkSize, len(data))
go func(s, e int) {
defer wg.Done()
var sum int64
for j := s; j < e; j++ {
sum += int64(data[j] * data[j])
}
mu.Lock()
total += sum
mu.Unlock()
}(start, end)
}
wg.Wait()
return total}
注意：这里用mu.Lock()保护共享变量，但若追求极致性能，可改用每个goroutine返回局部结果，主goroutine最后累加（避免锁竞争）。
进阶技巧：绑定核心（Linux下可选）
对延迟敏感或需要确定性调度的场景，可用golang.org/x/sys/unix调用sched_setaffinity将goroutine绑定到特定CPU核心（需配合runtime.LockOSThread()）。但普通服务通常不需要，反而降低调度灵活性。
基本上就这些——核心就两点：让GOMAXPROCS匹配物理核心数，再把计算任务按核心数等分、各自独立跑满。不复杂但容易忽略。
